Cyber eye: Security is in the process, not the product
- By William Jackson
- Mar 02, 2005
Intelligence agencies traditionally operate in high-risk environments, but despite that fact, according to former National Security Agency employee-turned-consultant Ira Winkler, they experience few information losses.
The reason, he says, is that 'in intelligence, security is embedded on Day One.'
Winkler, now president of the Internet Security Advisors Group, gave a briefing before the February opening of the annual RSA Security Conference in San Francisco on what security professionals can learn from the intelligence profession.
He made three observations that IT security managers can apply to their work:
- 'Requirements are the key' to establishing effective security. What you do depends on what you need to get done.
- 'Vulnerabilities should be your biggest worry.' There will always be threats, but even the most sophisticated threat can exploit only those vulnerabilities that exist in your systems.
- 'The risks you accept should be a conscious choice.' Determine what risks are acceptable to you and prioritize your spending accordingly, rather than spending until the budget is gone and accepting whatever risk is left over.
Of course, most spymasters have an advantage over IT security officers. It is easier to bake security into a program from Day One when you are present at the birth of the program. Most IT security administrators find on their first day on the job that, rather than designing and implementing meaningful security programs, they are usually bailing as fast as they can to keep the network above water.
Believe it or not, federal regulations might actually help. The goal of the Federal Information Security Management Act is to make information security a rational part of the management process, embedding it in the mission and making it risk- and requirements-based. This essentially is what Winkler advocates.
IT administrators have complained, with reason, that FISMA is a paper chase that diverts scarce resources from the critical job of fixing what is already broken and keeping systems up and running. But the problem is not so much with FISMA's requirements as with the resources allocated to meet them.
Despite the difficulties, government IT shops have been soldiering on for three years now, apparently making progress in security compliance. But making meaningful progress is difficult when workers are forced to choose between documenting a system and fixing it. If the government is serious about making FISMA the foundation of a rational IT security program, it must provide resources to enable compliance while the critical job of keeping systems patched and running continues.
But it will take more than resources to improve security. Retrofitting effective security to an IT system is seldom an easy job, and FISMA compliance, even if achieved, is unlikely to change that. The key to making FISMA effective will be a change in culture once baselines and accreditations are complete. It is hard to shift IT to a proactive, requirements-based stance, in which security is incorporated as an enabler, when you've spent your career reacting to crises and being seen by end users as a roadblock.
If these things can be done'making FISMA compliance a serious mission and incorporating secure processes in day-to-day administration of systems'IT security will be two very big steps closer to reality. William Jackson is a GCN senior writer. Contact him at firstname.lastname@example.org.