It’s at the end of September, check it out. Even if you’re not in the vulnerability/patch rat race on a daily basis, it would “behoove” you to go check out what’s new. If you’ve been paying attention to OMB Memo 10-15, you’ll notice that Cyberscope takes some SCAP input.

For some reason, “Rebuilding C&A” has been a perennial traffic magnet for me for a year or so now. Seeing how that particular post was written in 2007, I find this an interesting stat. Maybe I hit all the SEO terms right. Or maybe the zeitgeist of the Information Assurance community is how to do it right. Anyway, if you’re in Government and information security, it might be worthwhile to check out this old nugget of wisdom from yesteryear.

Now I’ve been reasonably impressed with GovInfoSecurity.com and Eric Chabrow’s articles but this one supporting 20 CSC doesn’t make sense to me. On one hand, you don’t have to treat your auditor’s word as gospel but on the other hand if we feed them what to say then suddenly it has merit?

Or is it just that all the security management frameworks suck and auditors remind us of that on a daily basis. =)

However, it seems that there are 3 ways that people approach frameworks:

From the Top–starting at the organization mission and working down the stack through policy, procedures, and then technology. This is the approach taken by holistic frameworks like the NIST Risk Management Framework and ISO 27001/27002. I think that if we start solely from this angle, then we end up with a massive case of analysis paralysis and policy created in a vacuum that is about as effective as it might sound.

From the Bottom–starting with technology, then building procedures and policy where you need to. This is the approach of the 20 Critical Security Controls. When we start with this, we go all crazy buying bling and in 6 months it all implodes because it’s just not sustainable–you have no way to justify additional money or staff to operate the gear.

And Then There’s Reality–what I really need is both approaches at the same time and I need it done a year ago. *sigh*

Fun things happened yesterday. In case you hid under a rock, the Intertubes were rocking yesterday with the thudding of fingera on keyboard as I live-tweeted the Senate Homeland Committee’s hearing on “Protecting Cyberspace as a National Asset: Comprehensive Legislation for the 21st Century”. And oh yeah, there’s a revised version of S.3474 that includes some of the concepts in S.773. Short version is that the cybersecurity bills are going through the sausage factory known as Capitol Hill and the results are starting to look plausible.

Breaking News: US House of Representatives attaches new FISMA rewrite to Defense Authorization Bill. The press hasn’t picked it up yet, but NextGov.Com will have a story in a few minutes. This puts one more nail in the coffin of the Federal CISOs and security contractors who think they can go on ignoring OMB and go on wasting money on out of date report writing contracts.

Alan

Yet another millstone (pun intended) piece of legislation passed on a Friday with… a cheerleader?!?!??? Whoa.

This ruined what was turning out to be a decent Friday afternoon for me…

My beef is this — I guess I really don’t understand what motivates someone who vilifies Federal CISOs and security contractors in the same sentence? Does the writer believe that CISOs are in the pocket of contractors? Even I am not that much of a cynic… Which CISO’s are “ignoring OMB?” All of them except NASA? Are all of our Government CISOs so out of touch that they LIKE throwing scarce IT dollars away on “out of date report writing contracts?” (sic.) (Vlad – Are hyphens too costly?)

I could drop to an ad hominem attack against the writer, but that’s pretty much unnecessary and probably too easy. I’ll leave that to others.

Suffice to say that what is motivating this newsbit appears IMHO to be less about doing things the right way, and more about doing things their way while grabbing all the headlines and talking head interviews they possibly can. (See “self-licking Ice Cream Cone” in my last post)

So now, how do you keep from letting FISMA cripple you or turn into death-by-compliance:

Prioritize. 25% of your controls need to not fail 100% of the time. These are the ones that you test in-depth and more frequently. Honestly, how often does your risk assessment policy get updated v/s your patch management? Believe it or not, this is in SP 800-53R3 if you interpret it in the correct context. More importantly, do not let your auditors dictate your priorities.

Use common controls and shared infrastructure. Explicitly tell your system owners and ISSOs what you are providing as the agency CISO and/or the GSS that they are riding on. As much as I hate meetings, if you own a General Support System (GSS), infrastructure (LAN/WAN, AD Forest, etc), or common controls (agency-wide policy, budget, Security Operations Center, etc), you have a fiduciary, legal, and moral obligation to get together with your constituency (the people who rely on the security you provide) and explain what it is you provide and allow them to tell you what additional support they need.

Share Assessment Results. I’m talking about results from service providers with other agencies and systems. We’re overtesting on the high-level stuff that doesn’t change and not on the detailed stuff that does change. This is the nature of security assessments in that you start at the top and work your way down into the details, only most assessments don’t get down into the details because they’re busy reworking the top-level stuff over and over again. Many years ago as a contractor managing infrastructure that multiple agencies used, it was unbelievably hard to get one agency to allow me to share security documents and assessment results with other agencies. Shared assessment results mean that you can cut through the repetitious nature of what you’re doing and progressively get deeper into the technical, frequently-changing security aspects.

Simplify the Paperwork. Yes, you still need to document what you’re doing, but the days of free-text prose and being graded on grammar and punctuation need to be over. Do the controls section of System Security Plans as a Requirement Traceability Matrix. More important than that, you need to go by-control by-component. If you are hiring contractors and their job is to do copypasta directly from NIST documents and change the pronouns and tenses, you’re doing it wrong. Don’t stand for that in your security policy or anything else that you do.

Automate Wherever Possible. Note that the controls that change frequently and that need to not fail usually fit into this group. It’s one of those “Things that make Rybolov go ‘Hmmmm'”. Technology and automation provide both the problem and the solution. Also see my first point up above.

Fire 50% of Your Security Staff. Yes, I’m serious. Those people you didn’t need anyway, primarily because they’re violating all the points I’ve made so far. More importantly, 25 clueless people can mess things up faster than 5 clueful people can fix them, and that’s a problem for me. Note that this does not apply to @csoandy, his headcount is A-OK.

The incredible thing to me is that this stuff is already there. NIST writes “hooks” into their Special Publications to allow the smart people the room to do all these things.

And now the part where I hop up on my soapbox: reforming FISMA by new legislation will not make any achievements above and beyond what we have today (with the exception of creating a CISO-esque position for the Exective Branch) because of the nature of audit and compliance. In a public policy sense, the more items you have in legislation, the more the audit burden increases and the amount of repetition increases, and the amount of nonsense controls (ie, AntiVirus for Linux servers) increases. Be careful what you ask for, you just might get it.