Part 1

Part 2

Takeaways from the 20 CSC and what they do right (hey, it’s not all bad):

You have to prioritize. On a system basis, there are maybe 50-60 800-53 controls (out of a number just shy of 200) that need to be built 100% correctly and working every single time.  The rest (I know, I’m putting on my heretic hat here) can lapse from time to time.  For example, if I don’t have good event monitoring, my incident response team doesn’t have much work because I don’t know if I’m pwned or not.  What 20 CSC does is try to reduce that set of stuff that I should be concerned about into a set of controls that are technical, tactical, and track to classes taught by SANS vulnerability-based .

Common controls are more important than ever. They help you scope the smaller systems.  In fact, roughly half of the 20 CSC apply to the modern Enterprise and should be absorbed there, meaning that for systems not owning infrastructure, we only have 10 or so controls that I have to worry a bunch about, and 10 that I just need to be aware of what’s provided by my CISO.

Give examples. I’ll even go as far as to say this:  it should be a capital offense to release a catalog of controls without a reference implementation for both an Enterprise/GSS and a smaller IT system/Major Application inside of it.  20 CSC stops maybe one step short of that, but it’s pretty close in some controls to what I want if they were structured differently.

Security Management v/s IT Management. IT asset inventory, configuration management, change control:  these are IT management activities that somehow get pushed onto the security team because we are more serious about them than the people who should care.  I think 20 CSC does an OK job of just picking out the pieces that apply to security people instead of the “full meal deal” that ITIL and its ilk bring.

Control Key photo by .faramarz.

Now for what they did wrong:

It’s Still Not a Consensus, Dammit! That is, it’s a couple of smart people making a standard in a vacuum and detached from the folks who will have to live by the work that they do.  Seriously, ask around inside the agencies:  who admits to helping develop 20 CSC aside from “yeah, we looked at it briefly”?  And I’m not talking about the list that SANS claims, that’s stripped from the bios of the handful of people who did work on 20 CSC.  Sadly, this is the quick path to fail, it’s like building an IT system without asking the users what they need to get their job done on a daily basis.  Guys, we should know better than this.

It’s Still Not a Standard. It’s still written as guidance–more anecdote than hard requirements.  This isn’t something I can put into a contract and have my contractors execute without modifying it heavily.  It’s also not official, something I’ve already touched on before, which means that it’s not mandatory.  If you want to make this a standard, you need to turn it into ~50 controls each written as a “contracting shall”.  More to come on this in the future.

It Has Horrible Metrics. And I’m talking really horrible…it’s like the goatse of security metrics (NSFW link, even though it’s wikipedia).  Why?  Because they’re time-based for controls that are not time-based.  Metrics need to be a way to evaluate that the control works, not the indirect effects of the control.  Of course, metrics are just a number, but at the end of whatever assessment, my auditor/IG/GAO/$foo has to come up with some way to rank the work that I’ve done as a security officer.  If 20 CSC is the vehicle for the audit and the metrics are hosed, it doesn’t matter what I can do to provide real security, the perception from my management is that I don’t know what I’m doing.

• 20 Critical Security Controls: Control-by-Control
• Opportunity Costs and the 20 Critical Security Controls
• The Guerilla CISO Rants: Don’t Write a System Security Plan
• Federated Vulnerability Management
• How to Not Let FISMA Become a Paperwork Exercise