Dan Mintz | A recovering CIO’s view of the new security initiatives

As debate continues over the value the Consensus Audit Guidelines have for securing government systems, I’d like to put my chief information officer’s hat back on for a moment and explain how I see the comparison between the CAG and the current security advice from the National Institute of Standards and Technology (NIST) in its Special Publication 800-53.

For those who came in after the beginning of the play and do not have the program notes, it is useful to understand that there are a number of arguments going on that relate to cybersecurity in the federal government.

These include disagreements over the value of the primary scorecard used to measure cybersecurity – the Federal Information Security Management Act -- and how useful NIST guidelines are in enhancing cybersecurity in government agencies. There is an additional argument over whether the current focus on implementing security controls ends up paying too much attention to preventing attacks at best, and merely filling out checklists at worst, and not enough on whether it actually improves security results.

Recently, a public/private group of individuals who have been active in cybersecurity put together a prioritized subset to focus on -- the 20 most important controls to deal with first, under the title of Consensus Audit Guidelines. To me, through the eyes of a CIO, the CAG approach has three values.

First, when dealing with security, it is important to establish that it is not just possible, but necessary, to establish priorities. If the FISMA checklist tied to the NIST guidelines calls for 200 controls to be implemented, but the resources are only available to do a partial implementation initially, there is a tendency to just try and check off as many as possible without deciding which are most important to do first.

Second, part of the CAG effort was to focus on those controls that could at least be partially automated and thus more effectively integrated into future security activities. The result is to strengthen the security infrastructure.

Third, a significant number of the CAG controls deal with increasing situational awareness, which I believe should be the primary focus of any security approach. If you don’t know what is going on, the likelihood of accomplishing very much is small.

When I was at the Transportation Department, I found the NIST guidelines, which have been revised in the recently released draft SP 800-53, useful and thorough. From everything I understand, they have gone a long way toward providing a broad framework, where there was little consistency before their development.

However, their thoroughness paradoxically has also become one of the challenges in using them, as has their associated measuring tool, the FISMA rating system. The necessity for NIST to cover all possibilities has, over time, led to a focus on completing checklists. I found the associated FISMA ratings, as a result, much more a measure of how well we met the criteria, but not necessarily how much more secure we made our computer systems.

The end result was that the focus of security is much more tactical and focused on compliance. It becomes what I used to refer to as whack-a-mole security, never actually making systemic changes that improved the overall security status.

Although I do not feel that the 20 CAG controls are a replacement for the NIST guidelines, I believe that using the CAG as an initial set of controls is a good thing. For example, when we implemented the Federal Desktop Core Configuration, developed by the Air Force and Microsoft under the leadership of the Office of Management and Budget, it did not deal with every issue associated with desktop configuration issues. However, it helped solve a significant percentage of problems and was a useful step to concentrate on, to allow later focus on other more specialized issues.

I have a few additional thoughts regarding cybersecurity that I hope the current cyber-review being undertaken for the president takes into account.

First, we should keep in mind that the reason we have a security emphasis is not because we need to have security, but because we are trying to allow some kind of programmatic activity to be successful. This means that we need to focus on what we are trying to protect and how to allow the programs to function even while we are building walls and moats to protect our programmatic castles. If there is a conflict between security and programmatic requirements, the programmatic needs should take priority.

Second, our continuing over-classification of security issues, security about security, often means that we end up merely keeping information from the good guys. It is not unusual to attend restricted, highly classified security briefings where the content is long since in the public record.

As a final note, almost all of these approaches take a relatively static approach to controls and processes that is increasingly not an accurate representation of architectural reality. We haven’t precisely defined all of the implications of service-oriented architecture, thought through the implications of software-as-a-service, or agreed on almost anything associated with cloud computing, the buzzword du jure.

However, one clear result of these trends is that what we define as a system is undergoing rapid, radical transformation. Ultimately this will strengthen the argument that our focus needs to continue to move toward situational awareness and results, not controls and protection.