Feds having fits over FISMA and cybersecurity

The Federal Information Security Act of 2002 caused concern over cybersecurity in government entities that hadn't shown much of it previously, lighting fires under folks who needed warming. So what's all this talk of burning FISMA down?

FISMA's birth certificate is fairly petite -- the section of the E-Government Act of 2002 that created FISMA weighs in at a readable 16 pages (PDF available here). It outlines a set of mandatory processes for compliance for information systems used by or on behalf of the US federal government.

Security's a good thing; no one's going to argue against it. Even the Info Assurance crowd, which plugs security into a larger worldview incorporating a focus on risk management and a superior understanding of governance, isn't going to claim that security isn't a core value for well-managed systems.

Talk of torching security rules, therefore, may sound a little hasty, especially when the GAO seems to turn up a new case of federal security brainlessness every week or so. Understanding why so many in government want to either rework FISMA or junk it entirely requires knowing what the standard does -- and what it can't get traction on.

It may surprise you to hear that a federal program created lots of paperwork, but that's what FISMA did. By focusing on security reports and the auditing thereof rather than on actual security measures -- compliance, in other words, not performance -- FISMA made it easy for federal CISOs to quantify their work in a way the bureaucracy at large could understand.

Rather than trying to demonstrate that their systems prevented X number of attacks or deflected Y number of intrusions (go ahead, security staffer, prove those negatives!), departments could demonstrate that they'd reached their proper level of FISMA compliance -- or tried, anyway -- and thereby justify their various budgets. Visibility for cybersecurity increased, and Congress emitted a widely publicized "report card" on the various agencies' compliance scores every year.

(Visibility and the proper level matter in the federal ecosystem, as anyone who works that turf can tell you -- too much security required for your project and you'll spend all your time ensuring compliance with every last sentence of the NIST 800-53's most stringent rules. Too little and hey, maybe whatever it is you're doing doesn't need so much funding.)

It was a start, anyway; something is better than nothing. But many observers say it's high time for FISMA to move past its first incarnation and into an era when actual performance is measured and evaluated. In other words, it shouldn't be enough to check the compliance boxes; you have to actually not have your department getting pwned.

The Senate's Homeland Security and Governmental Affairs Committee actually saw and approved an updated FISMA (S.3474, the FISMA Act of 2008) near the end of the session that ended in October. That bill's slated to appear on the next legislative calendar after the turn of the year.

It's a nice albeit non-sweeping update, refocusing CISO efforts on performance and risk management -- strategies we've learned from seven long years of white hats, black hats, open source, and cyberwars. Audits will still be part of the process, and real, independent audits annually, not the current 'evaluations." A certain amount of standardization in controls will help to further improve implementation.

And FISMA 2 has a friend -- the Consensus Audit Guidelines project, an initiative developed by former Air Force CIO John Gilligan and co-developed by a number of the agencies that are affected by FISMA, including DHS, the NSA, and the GAO.

Gilligan has spoken at length on the CAG project and its 20 proposed controls, but he describes the two most significant "missing ingredients" in the current FISMA as a lack of structure for identifying effective attack-deterrent controls, and the ability to continuously measure whether the controls are working. The group's hope is that the two projects can "dovetail" for maximum effectiveness.

The most pressing task of all? Finding the biggest holes and patching them first -- simple and obvious procedure, genuine security payoff.