ANOTHER VIEW — Commentary

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.

About the Authors

Dan Mintz is chief technical officer of the Civil and Health Services Group at Computer Sciences Corp. (CSC) and former chief information officer of the Transportation Department.

inside gcn

  • Global Precipitation Measurement of Florence

    USDA geotargets the press

Reader Comments

Fri, Mar 27, 2009 Denver

So lets see, we get to add another "standard" to our "compliance cloud" of checklists to undergo. But guess what? The existing ones I have to comply with are not going away - A123/FISCAM, C&A/FISMA, NERC CIP audit worksheets, supplemented by various internal mimimum security baselines such as CIS benchmarks, FDCC settings, etc. What we typically end up doing is all the above to satisfy auditors (one or more teams) while another team concentrates on the real cyber security, sometimes referred to as security by common sense, situational awareness, etc. Is there room for yet another set of controls such as CAG? Sure. But all of the stuff that came before is not going away, and for good reason. We have to do a cross walk thru the various sets of controls anyway. There are no shortcuts here folks.

Fri, Mar 27, 2009 Brad Morrison

Dan, I will comment on your conclusion, "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." I agree with your conclusion and that what we are now in an environment where cyber innovation is outpacing our ability to apply legacy paradigms of "control and protect". More times than not, 'broadly' applied security certification and accreditation efforts diminish an ability to achieve cyber advantages.
We must embrace, not reject, innovations such as open source software, blogs, social networking, cloud computing, software as a service, mashups, and wireless-on-demand as these will afford the governement access to 'game changing' capabilties. Further, as the useful life of data shrinks and time-to-market of analytic capabilities accelerates, controls we once thought useful actually prove ineffective and deny the ability to quickly harness these innovations to achieve advantage. So what do we do? I agree that situational awareness and an ability to dial up or down risk management controls based on this awareness seems to be a plausiblee way forward. The challenge is developing a situational awareness framework and platform that is as adaptive or agile as the underlying cyber innovation it aims to assure. Do you have any insight as to how this could be done in the face of constant adaptations of commercial technologies, cyber innovations and irregular, mutating threats? I would enjoy a continued dialogue with you and others on the subject matter at the following site:

Thu, Mar 26, 2009 John Curran Dulles, VA

Dan - CAG is an excellent checklist, and certainly provides a set of minimum guidelines that if deployed by every IT system owner would improve federal security. It nicely focuses on the steps that should be automated and common in federal IT infrastructure. The challenge, of course, is that not everything can be automated, and there are systems require additional protections (such as review of audit logs, host-based intrusion systems, etc) that aren't cost effective to deploy across the entire system inventory. The advantage of a risk-impact based approach such as FISMA is that additional controls are put in place for systems that need them. Yes, it does require a bit of work to review the potential risks from system disclosure, compromise, or tampering, but that's should be done even for systems meeting the CAG guidelines.

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above

More from 1105 Public Sector Media Group