| Will security metrics solve the issues with FISMA? |
|
Will metrics solve the issues with FISMA? Federal CIO Vivek Kundra is betting metrics will help improve efficiency. (I know government efficiency sound like an oxymoron.) The OMB has reported the 20 out of the 24 federal agencies have significant deficiency or a material weakness in their information security programs. Kundra feels FISMA has is compliance based on not indicator based. Imagine that, the government took a perfectly good framework and turned it into a bureaucratic paper exercise.
Kundra has it right when he said. "We will never achieve our security goals through compliance alone because security threats are fluid and constantly changing." Margaret Graves, acting chief information officer of the Department of Homeland Security, supports FISMA but still echoes Kundra point when he said, "What is also apparent is that simply maintaining a controls framework alone is not enough."
The NIST Certification and Accreditation (C&A) framework developed for FISMA is a risk based process. Well, that is the intent at any rate. The problem with the implementation of NIST standards by government agencies is the tendency to view it as a 'check box' exercise and not an ongoing dynamic risk management process. How do we know this is the problem? Look at the required documentation for C&A. You will find in the forms a risk management document for any given system. It most likely was copied from a previous risk assessment from a different system, before implementation of the system and not updated until the recertification of the system. Not only that, the forms used are cumbersome and confusing. What most end up with for their risk management program is a static risk document that has no direct correlation to the controls in place or the current risk environment.
The problem is not exclusive to the federal government you find organization that use ISO doing the same thing with risk management. Insanity is often defined as doing the same thing over and over expecting a different result. If we continue with our static and isolated risk management process we will not change anything.
One of my favorite examples of this insanity came from a recent discussion concerning control implementation for a system of lab computers that are connected to a network that is not connected to any other network. The network and lab computers are completely isolated from any other network and thus also the Internet. During the C&A phase the system owner determined the baseline controls and started to implement those controls. One of those controls was a firewall. The question I asked staff was "What threat was the firewall meant to protect this isolated system from?" Can you see the disconnect? They were blindly implementing controls without regard to actual risk!
What is the solution for this apparent dilemma and insanity? The risk management process must be directly tied to individual controls in such a way as to be dynamic and useable. This process requires the risk management documentation and control implementation documentation (system security plan for NIST folks) to be linked. This is difficult to do, using the current method most people use, which is a document format. A database is much better suited for this task. You can than have a many to many relationship between your risks and your controls.
Risk management must also be an ongoing process. Risks change daily as threats and threat agents change. It is safe to say that your risk changes daily, if not more often. The disconnect with many current risk management processes is the risk is reevaluated annually or less often. Is it enough to reevaluate your risks only when you have major changes to the system? The question in response is, does risk only change when there is a major change to the system? No. Risks change more often than major changes to the system.
We can have all the metrics in the world. If we don't have a dynamic, realistic, easy to use risk management system the metrics will only indicate we are do not have an efficient information security program. It is the only way we can address security threats that are fluid and constantly changing.
Donald E. Hester
CISSP, CISA, CAP, PSP, MCT, MCITP, MCSE Security, MCSA Security, MCTS, MCDST, Security+, CTT+, MV
Brought to you by Maze & Associates, a leading Northern California Accounting Firm specializing in Municipal & Nonprofit Audit, Tax for individuals and all types of entities, Information System Audits, Security Reviews, as well as PCI Scans and certified training. Maze & Associates is a PCI ASV - Approved Scanning Vendor.
RSS Subscription: http://feeds2.feedburner.com/learnsecurityblog
Disclaimer: The views expressed here are those of the author and do not represent those of Maze & Associates.
|
Subscribe to LearnSecurity Blog using your favorite feed reader by 
Latest News
| Stay up-to-date with Don's LearnSecurity.org Blog. Chucked full with Security information, news, reviews and resources. This blog is available via RSS feed. |