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

So now that His Esteemed Highness Eric Schmidt has declared privacy dead, our IKANHAZFIZMA team of LOLCATS wants to know if they can resume their usual collection of cellular traffic.

References:
Gawker: Google CEO: Secrets Are for Filthy People

Schneier Blog: My Reaction to Eric Schmidt

Download Squad: Only naughty people should be afraid of Google, says CEO Eric Schmidt

The Register: Google chief: Only miscreants worry about net privacy

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

It’s a basic project management skill: determining project assumptions and then what is inside your scope.  And so when the folks at NIST created their risk management framework, they made several assumptions that the rest of us practitioners have to deal with.

A quick list of assumptions:

• You are working at the enterprise level or the project level.
• You don’t own custom code.
• You’re not governed by any laws other than FISMA and the Privacy Act.
• You’re using Microsoft and Cisco products.
• Your system is networked.
• You have some kind of Internet access.

Looking back through the list, it’s basically a description of the “typical” IT Enterprise built from COTS components.  And I think this is a good thing because it fits about 80% of the IT systems out there.  For these systems, the focus is on secure configurations and buying security products.

Assumption, Minnesota photo by afiler.

Now for why you need to understand this list:  it’s because if you’re not operating under the exact same set of assumptions as the catalog of controls, you have to adjust the catalog of controls to fit what it is you’re trying to accomplish.

And this, dear readers, is my theory on why compliance as a security management model does not work–there simply are enough variations in implementation that wherever you draw the line for a standard, you’re bound to either include too much and make everybody into an exception to the catalog of controls or you are going to include not enough and it becomes a watered-down standard.

And now, the secret for surviving in a catalog-of-controls culture:  you have to tailor the controls for any of the following activities:

• Building security requirements
• Building test procedures
• Assessing risk and performing risk management

Plainly stated, controls are not one-size-fits-all.  Neither are test cases.

But guess what: SP 800-53 has a huge section about assumptions and selecting controls in section 3.3.  It lists the following considerations for scoping controls:

• Common Controls:  What did you inherit from the infrastructure and the enterprise and how much do you need to augment?
• Security Objectives:  What is it that you’re actually trying to accomplish?
• System Component Allocation:  Does a particular chunk of the system need this control when it’s been satisfied elsewhere?
• Technology-Related:  Are you putting Sharepoint directly on the Internet?  Do you need more protection because of this? (this one’s for Dan Philpott)
• Physical Infrastructure:  You don’t need datacenter environmental controls if your system is a bunch of laptops.
• Policy/Regulatory: Is there a special law about the data in this particular system that typically isn’t in the scope of IT security?
• Operational/Environmental:  Is this something that you’re dropping into an embassy where you assume that layer-1 back to the US has been compromised by the host nation?
• Scalability:  Local passwords only scale up to a certain amount of users.  After that, you need better identity and access management by us
• Public Access: Have you increased the attack surface by letting the public access kiosks with a direct connection into the system?

Sadly, nobody ever reads those parts.  For your sanity, please do.

• 20 Critical Security Controls: Control-by-Control
• 20 Critical Security Controls: What They Did Right and What They Did Wrong
• Observations on SP 800-37R1
• How to Not Let FISMA Become a Paperwork Exercise
• Realistic NSTIC

OK, so it’s been a couple of months of thinking about this thing.  I threw together a rainbow-looking beast that now occupies my spare brain cycles.

Rybolov’s Information Security Management Model

And some peculiarities of the model that I’ve noticed:

Regulation, Compliance, and Governance flows from the top to the bottom.  Technical solutions flow from the bottom to the top.

The Enterprise (Layer 4) gets the squeeze.  But you CISOs out there knew that already, right?  It makes much sense in the typical information security world to focus on layers 3, 4, and 5 because you don’t usually own the top and the bottom of the management stack.

The security game is changing because of legislation at layers 5 and 6.  Think national data breach law.  It seems like the trend lately is to throw legislation at the problems with information security.  The scary part to me is that they’re trying to take concepts that work at layers 3 and 4 and scale them up the model with very mixed results because there isn’t anybody doing studies at what happens above the Enterprise.  Seriously here, we’re making legislation based on analogies.

Typically each layer only knows about the layer above and below it.  This is a serious problem when you have people at layers 5 and 6 trying to create solutions that carry down to layers 1 through 4.

At layers 1 and 2, you have the greatest chance to solve the root causes of security problems.  The big question here is “How do we get the people working at these layers the support that they need?”

• A Layered Model for Massively-Scaled Security Management
• Massively Scaled Security Solutions for Massively Scaled IT
• Professor Rybolov’s Guide to InfoSec and Public Policy Analysis
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 5
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 4