This is a multi-post series.  You are at post 1.  Read post 2 here.  Read Post 3 here.

This post begins with me.  For the past hour or so I’ve been working on a control-by-control objective analysis of SANS 20 Critical Security Controls.  This is a blog post I’ve had sitting “in the hopper” for 9 months or so.  And to be honest, I see some good things in the 20 CSC literature.  I think that, from a holistic perspective, the 20 CSC is an attempt at creating a prioritization of this huge list of stuff that I have to do as an information security officer–something that’s really needed.  I go into 20 CSC with a very open mind.

Then I start reading the individual controls.  I’m a big believer in Bottom-Line-Up-Front, so let me get my opinion out there now: 20 Critical Security Controls is crap.  I’m sorry John G and Eric C.  Not only is 20 CSC bad from a perspective of controls, metrics, and auditing tests, but if it’s implemented across the Government, it will be the downfall of security programs.  I really believe this.

Now on to the rationale….

Opportunity Costs. I can’t get that phrase out of my head.  And I’m not talking money just yet–I’m talking time.  See, I’m an IT security guy working for a contractor supporting a Government agency–just like 75% of the people out there.  I have a whole bunch of things to do–both in the NIST guidelines and organizational policy.  If you add anything else to the stack without taking anything away,  all you’ve done is to dilute my efforts.  And that’s why I can’t support 20 CSC–they’re an unofficial standard that does not achieve its stated primary goal of reducing the amount of work that I have to do.  I know they wanted to create a parallel standard focusing on technical controls but you have to have one official standard because if it’s not official, I don’t have to do it and it’s not really a standard anymore, it’s it?

Scoping Problems. We really have 2 tiers inside of an agency that we need to look at: the Enterprise and the various components that depend on the Enterprise.  Let’s call them… general support systems and major applications.  Now the problem here is that when you make a catalog of controls, some controls are more applicable to one tier than the other.  With 20 CSC, you run the classic blunder of trying to reinvent the wheel for every small system that comes along.

Threat Capabilities != Controls. And this is maybe the secret why compliance doesn’t work like we think it will.  In a nice theoretical world, it’s a threat-vulnerability-countermeasure coupling and the catalog of controls accounts for all likely threats and vulnerabilities.  Well, it doesn’t work that way:  it’s not a 1-to-1 ratio.  Typical security management frameworks start from a regulatory perspective and work their way down to technical details while what we really want to do is to build controls based on the countermeasures that we need.  So yeah, 20 CSC has the right idea here, the problem is that it’s a set of controls created by people who don’t believe in controls–the authors have the threat and vulnerability piece down and some of the countermeasures but they don’t understand how to translate that into controls to give to implementers and their auditors.  The 20 CSC guys are smart, don’t get me wrong, but I can’t help but get the feeling that they don’t understand how the “rest of the world” is getting their job done out there in the Enterprise.

The Mapping is Weak. There is a traceability matrix in the 20 CSC to map each control back to NIST controls.  It’s really bad, mostly because the context of 800-53 controls doesn’t extend into 20 CSC.  I have serious heartburn with how this is presented inside the agencies because we’re not really doing audits using the 20 CSC, we’re using the mapping of NIST controls with a weird subtext and it’s a “voluntary assessment” not an audit.

Guidelines?!?!?! This is basic stuff.  If it’s something you audit against, it *HAS* to be a standard.  Guidelines are recommendations and can add in more technique and education.  Standards are like hard requirements, they only work if they’re narrowly-scoped, achievable, and testable.  This isn’t specific to 20 CSC, the NIST Risk Management Framework (intended to be a set of guidelines also) suffers from this problem, too.  However, if your intent is to design a technical security and auditing standard, you need to write it like a standard.  While I’m up on a soapbox, for the love of $Diety, quit calling security controls “requirements”.

Auditor Limitations. Let’s face it, how do I get an auditor to add an unmanaged device to the network and know if we’ve detected it or not.  This is a classic mistake in the controls world:  assuming that we have enough people with the correct skillsets who can conduct intrusive technical tests without the collusion of my IT staff.

And the real reason why I dislike the 20 Critical Security Controls:

Introduction of “Audit Requirements”. One of the chief criticisms of the NIST Risk Management Framework is that the controls are not specific enough.  20 CSC falls into this trap of nonspecificity (Controls 7, 8, 9, and 15, I’m talking to you) and is not official guidance–a combination that means that my auditor has just added requirements to my workload simply because of how they interpret the control.  This is very dangerous and why I believe 20 CSC will be the end of IT security as we know it.

In future posts (I had to break this into multiple segments):

• Control-by-control analysis
• What 20 CSC got right (Hey, some of it is good, just not for the reasons that it’s supposed to be good)

SA-2 “Guideline” photo by cliff1066™.

• 20 Critical Security Controls: What They Did Right and What They Did Wrong
• 20 Critical Security Controls: Control-by-Control
• Workin’ for the ‘Counters: an Analysis of my Love-Hate Relationship with the CPAs
• Your Security “Requirements” are Teh Suxxorz
• How to Not Let FISMA Become a Paperwork Exercise

A little bit on the oddball side this week (versus every week, maybe not so oddball), but we’re offering up some lolcats and a QR Code.  Not only is this fun but it’s useful if you’re a forgetful person like our ikanhazfizma lolcats.

If none of this makes sense to you, go check out my barcode post and presentation from earlier this week for info and how to get your very own QR reader.

• Redundant Lolcats
• Lolcats, Capital Hill, and a Haiku
• IKANHAZFIZMA and Transparency
• Lolcats Coming to you from the Cloud
• Lolcats Protect the End Users

Dear Project Team

Effective immediately and due to recent events , you are forbidden to utter the following phrases:

Direct Connection. In our world, nothing connects directly.  I have many pieces of expensive kit between your webserver and the users out on the Internet.  They don’t connect directly at all, but when you use this phrase, we have to give the SOC Manager an adrenaline shot to get his heart restarted.  It’s a series of tubes with some valves in the way, get it?

What are Oracle CPUs. Look, one more time with this:  these are the quarterly patches that Oracle puts out.  No idea why they call them Critical Patch Updates except maybe because they’ve been reading their own “unbreakable” literature a bit too much.  I don’t care if you call them “Late to Supper” as long as you keep me happy by testing them in the lab as soon as they’re released.

System. Let’s just suffice it to say that in my world, a “System” is something different than what you call it.  Think 2 layers abstracted and larger than your idea.

Security Waiver. Please don’t ask the security staff directly about waivers.  They’ll only send you on a huge journey to circumnavigate a huge amount of paperwork.

Remote Access. Yep, we have it.  But look, you guys are database and applications geeks, leave the drawings to me because you keep drawing the Internet users inside of our network.

Missing. OK, so we have 200 laptops that we don’t know right now where they’re at.  But if we use the word “missing”, then I have to spin up the laptop SWAT team from US-CERT.  Henceforth and forever more throughout the world of IT, I am the person who can declare something as “missing”.  In the mean time, feel free to use the phrase “unaccounted for”.

Wireless, Bluetooth, WiFi. You need to know where I’m coming from on this one.  Whenever we have project meetings, there’s an auditor dialed into the phone call, just waiting for us to say any of these words.  Then they wake and pounce on us.  Mayhem ensues.

Financial Data. Yes, I understand you think of it as financial data but to me, your spreadsheet is a non-authoritative, non-source analytical tool for numbers that just happen to be derived from authoritative financial system sources.  When you claim that it’s financial data, you just made a ton of work in integrity controls that is just plain ludicrous.

Tons of Custom Code. When you talk to the user community, talk up your epic slaying of code dragons and the myriad pitfalls of doing so.  But when you talk to the security team, custom code implies that we need to do a ton of code review. The official phrase is “automation scripts to assist the users with their workflow” or “glue code to string together existing applications”.

Offshore Developers. I can barely get the security team to allow me to have developers at all, much less developers at a contractor site.  Yes, they might be people who happen to live not in the US who get paid to write code.  But when you talk to the auditor, we have a word for this stuff: COTS software.

Love you guys.  No, really, quit laughing.

–The BSOFH

• Everything I know about security, I learned from Ghostbusters…
• The BSOFH On Dorky, Auditor-Friendly Policies
• Some Thoughts on POA&M Abuse
• Beware the Cyber-Katrina!
• Your Security “Requirements” are Teh Suxxorz

Ah yes, the BSOFH is deep down inside every security manager doing all the things that we wish we could.  And so today we present a BSOFH in lolcat form.

For more BSOFH, check out posts here on guerilla-ciso and on layer8.

• The Authorizing Official and the Lolcat
• CIO Council Guidelines on Social Media Meet IKANHAZFIZMA
• Lolcats Coming to you from the Cloud
• LOLCATS Take on POA&Ms
• Exhaustive Security Testing is Bad For You

Every once in a while an opportunity presents itself to affect some real change in federal information security practice.  Now is such a time.  A slew of new NIST documents are being released between now and April.  These are the core NIST documents that describe how to satisfy FISMA.  They include NIST SPs 800-30 Revision 1, 800-39, 800-37 Revision 1 and 800-53A Revision 1. That’s where you come in.

The documents define what federal government practice will look like in the coming years.  If they are flawed then the practice will be flawed.  To prevent stupidity from leaking in when nobody is looking NIST releases the documents as drafts so everyone gets a chance to eyeball them.  First you eyeball, then you comment.  They look at the comments and they fix the flaws.  Fix the flaws now and you don’t live with them later.

The most important document in draft right now is the NIST Special Publication 800-37 Revision 1.  This document describes the central processes involved in the authorization of information systems that support the federal government.  Notice I didn’t say Certification and Accreditation?  That’s because C&A is deader than a sheep at a wolf convention. Want to know what replaces it?  Pick up a copy of NIST SP 800-37r1 FPD, give it a read and send in your comments.

Better yet, consider joining a formal document review process.  I’m leading a team of hale and hearty volunteers at OWASP in a NIST SP 800-37r1 FPD review and we’d love to have you come join the fun.   We’re on a tight schedule so now is the time to act.

Time is short, the comment period for NIST SP 800-37 Revision 1 FPD ends on December 31st, 2009.

• The Guerilla CISO Rants: Don’t Write a System Security Plan
• Observations on SP 800-37R1
• NIST Cloud Conference Recap
• William Jackson on FISMA: It Works, Maybe
• “Machines Don’t Cause Risk, People Do!”

A small presentation Dan Philpott and I put together for Potomac Forum about getting sane social media policy out of your security staff. I also recommend reading something I put out a couple of months ago about Social Media Threats and Web 2.0.

• DojoCon 2009 Presentation
• The Accreditation Decision and the Authorizing Official
• Massively Scaled Security Solutions for Massively Scaled IT
• Metricon 5 Wrapup
• Certification and Accreditation Seminar, March 30th and 31st