It must be summer. There have been several weeks of back-to-back security conferences, symposia and seminars. After 25 years in the security business, and speaking or attending at dozens and dozens of these gatherings, I am confident I could easily describe all the sessions and their content simply by looking at the speaker biographies. In fact, I am posting this column from one such venue — this one dedicated to cybersecurity for federal and state government entities. The sessions are awash with the expected “educational” product sessions by technology vendors hoping to peddle their wares to attendees. About half the conference was dedicated to government presenters eager to describe their latest efforts toiling in the foggy bowels of federal and state information technology agencies.
In every government IT security conference, several sessions will undoubtedly be dedicated to hectoring the technologists with the latest federal standards and policies for protecting critical information resources. This conference is no exception. Several speakers got up to talk about new legislation, old legislation, polices, directives, guidelines, forms, requirements, suggestions and outlines promulgated by the government to tell the security people how to do their job. Some are useful, but most are not.
The most notorious and impactful of the big federal regulations is the Federal Information Security Management Act of 2002 (FISMA). Sure enough, several sessions were dedicated to this onerous reporting requirement alone. Speakers cheerily provided advice for complying with this government mandate, and for ensuring your agency could boost the scores that the Government Accounting Office ultimately reports based on internal organizational assessments.
I am not going to write about the pros and cons of the legislation, nor of the cottage industry that inevitably grows up around any such burdensome requirement — that’s what everyone here is doing in these sessions. I’d like to explore a more basic issue about why we end up with these less-than-ideal directives.
Planning and implementing security management of an enterprise system is an eminently difficult task. Logical practitioners would seek guidance from professionals, academicians and government for their efforts; however, when we ask our governing bodies for detailed guidance, they are usually more than happy to jump in and provide it in the form of new laws and regulations. My mother always warned me to be careful about what I wished, because that wish may actually come true. To quote Penn Jillette, “When someone says there ought to be law, there really ought not be a law.”
When groups of people urge government or other ruling bodies to take on their security requirements, they may also be unconsciously attempting to offload some of their own responsibilities for protecting valuable assets under their control. It is also common for some practitioners to feel if they meet the government mandates, then they have successfully accomplished their security mission. However, we all know security isn’t a state, a grade on a report, or any single point-in-time — it is a continuous journey. These guidelines may be helpful, but they must be taken in the proper context.
The first rule of security is always to ensure you are protecting yourself (or your organization) first and foremost. You may have all the proper professional certifications, and meet all the federal, state and organizational requirements, and still not have a sound security program. The rule about protecting yourself (or your organization) is about accepting responsibility for continually evaluating risks and seeking out the most effective ways to deal with them.