With as much overengineering that people do for low-criticality systems, I’m surprised nobody’s mentioned this idea yet for high-criticality data:  snipers on the roof.  Now that “the cat’s out of the bag”, I figure this will be in the next 800-53 revision.

• The Authorizing Official and the Lolcat
• IKANHAZFIZMA and Transparency
• A Stable InfoSec Program?
• Agencies CISOs Star in LOLCATS!
• Yet More Security Controls You Won’t See in SP 800-53

The perpetual draft document, SP 800-53A, has been officially released after 3 years.  Check out the announcement from NIST here.

Now the interesting thing to me is that NIST is working with some other players (DNI comes to mind) on reference implementations of 800-53A.  This is big, so big that I can’t add enough hyperbole to it.

Why do they need to do reference implementations?  Well, because by itself, SP 800-53A is dangerous if it’s given to people who “don’t get it”.  By that what I mean is this:

• SP 800-53 needs tailoring to distill into actual requirements.
• SP 800-53A needs a huge amount of tailoring to distill into test cases/procedures that match the tailoring that you did with 800-53.
• Taken at face value, 800-53 and 800-53A become the source of “death by compliance”.
• If you think the auditors could grill you to death with 800-53, 800-53A gives them tons more material.

Now time for a war story: I worked on a project where the contractor was having a hard time building a security program, mostly because they didn’t have the right staff to get the job done.  The government told the contractor to use 800-53A as a starting point, and 6 months of insanity followed with 13 “security engineers” in a conference room cranking out documentation that had no basis in reality.  At the end of it all, the contractor handed the Government a bill for $1M.

Now don’t get me wrong, I like the ideas behind 800-53A, but the first thing you need to know when you start using it is when you shouldn’t use it:

• Don’t run test procedures on every computer you have, use an automated tool and do spot-checks to validate that the automated tool works.
• Use less test procedures on low-criticality systems.
• “This procedure is conducted as part of the hardening validation process.”
• Common controls are even more important because you do not want the repetition of effort.

And whatever you do, don’t let 800-53A turn your risk management into a compliance activity.  It has all the potential to do that.

US Government Doc’s photo by Manchester Library.

• OMB Wants a Direct Report
• An Open Letter to NIST About SP 800-30
• Auditors, Frameworks, and Philosophy
• Security Assessments as Fraud, Waste, and Abuse
• Observations on SP 800-37R1

Article from William Jackson in Government Computer News:  Security policies remain a burden to federal IT managers, but they are producing results.

First off, GCN, come into the modern Web 2.0 era by letting people comment on your articles or at least allow trackbacks.  Having said that, let’s look at some of Mr Jackson’s points:

• NIST Special Publications: They’re good.  They’re free.  The only problem is that they’re burying us in them.  And oh yeah, SP 800-53A is finally final.
• Security and Vendors/Contractors:  It’s much harder than you might think.  If there’s interest, I’ll put out some presentations on it in my “copious amounts of free time”.  In the meantime, check out what I’ve said so far about outsourcing.
• Documentation and Paperwork:  Sadly, this is a fact of life for the Government.  The primary problem is the layers of oversight that the system owner and ISSO have.  When you are as heavily audited as the executive branch is, you tend to avoid risks and overdocument.  My personal theory is that the reason is insistence on compliance instead of risk management.
• Revising FISMA:  I’ve said it time and time again, the law is good and doesn’t need to be changed, the execution is the part that needs work.

• An Open Letter to NIST About SP 800-30
• FISMA Report Card News, Formulas, and 3 Myths
• Ooh, “The Word” is out on S 3474
• How to Not Let FISMA Become a Paperwork Exercise
• A Funny Thing Happened Last Week on Capital Hill

Check out this article by Andy Boots on the Tech Insiders blog.

It brings up an interesting point:  Agencies do not typically have a CSO-level manager.  According to FISMA, each agency has to have a CISO whose primary responsibility is information security.

But typically these CISOs do not have any authority over physical security or personnel security:  in reality, they work for the CIO and only have scope over what the CIO manages:  data centers, networks, servers, desktops, applications, and databases.

Except for one thing:  we’re giving today’s Government CISO a catalog of controls that contain physical and personnel security.  The “party line” that I’ve gotten from NIST is that the CISOs need to work through the CIO to effect change with the areas that are out of their control.  I personally think it’s a bunch of bull and that we’ve given CISOs all of the responsibility and none of the authority that they need to get the job done.  In my world, I call that a “scapegoat”.

To be honest, I think we’re doing a disservice to our CISOs, but the only way to fix it is to either move our existing CISOs out of the CIOs staff and make them true CxOs or write a law creating an agency CSO position just like Clinger-Cohen created the CIO and FISMA created the CISO.

• An Open Letter to NIST About SP 800-30
• Next Up in Security Legislation: S3474
• Opportunity Costs and the 20 Critical Security Controls
• Workin’ for the ‘Counters: an Analysis of my Love-Hate Relationship with the CPAs
• Database Activity Monitoring for the Government

Check out this slideshow and this workshop paper from 2006 on some ideas that NIST and a fairly large advisory panel have put together about certification of C&A service providers.  I’ve heard about this for several years now, and it’s been fairly much on a hiatus since 2006, but it’s starting to get some eartime lately.

The interesting thing to me is the big question of certifying companies v/s individuals.  I think the endgame will involve doing both because you certify companies for methodology and you certify people for skills.

This is the problem with certification and accreditation services as I see it today:

• Security staffing shortage means lower priority:  If you are an agency CISO and have 2 skilled people, where are you going to put them?  Odds are, architecture, engineering, or some other high-payoff activity, meaning that C&A services are candidates for entry-level security staff.
• Centralized v/s project-specific funding:  Some agencies have a “stable” of C&A staff, if it’s done wrong, you end up with standardization and complete compliance but not real risk management.  The opposite of this is where all the C&A activities are done on a per-project basis and huge repetition of effort ensues.  Basic management technique is to blend the 2 approaches.
• Crossover of personnel from “risk-avoidance” cultures:  Taking people from compliance-centric roles such as legal and accounting and putting them into a risk-based culture is a sure recipe for failure, overspending, and frustration.
• Accreditation is somewhat broken:  Not a new concept–teaching business owners about IT security risk is always hard to do, even more so when they have to sign off on the risk.
• C&A services are a commodity market:  I covered this last week.  This is pivotal, remember it for later.
• Misinformation abounds:  Because the NIST Risk Management Framework evolves so rapidly, what’s valid today is not the same that will be valid in 2 years.

So what we’re looking at with this blog post is how would a program to certify the C&A service providers look like.  NIST has 3 viable options:

• Use Existing Certs: Require basic certification levels for role descriptions.  DoD 8570.1M follows this approach.  Individual-level certification would be CAP, CISSP, CG.*, CISA, etc.  The company-level certification would be something like ITIL or CMMI.
• Second-Party Credentialing:  The industry creates a new certification program to satisfy NIST’s need without any input from NIST.  Part of this has already happened with some of the certifications like CAP.
• NIST-Sponsored Certification:  NIST becomes the “owner” of the certification and commissions organizations to test each other.

Now just like DoD 8570.1M, I’m torn on this issue.  On one hand, it means that you’ll get a higher caliber of person performing services because they have to meet some kind of minimum standard.  On the other hand, introducing scarcity means that there will be even less people available to do the job.  But the big problem that I have is that if you introduce higher requirements on commodity services, you’re squeezing the market severely:  costs as a customer go up for basic services, vendors get even less of a margin on services, more charlatans show up because you’ve tipped over into higher-priced boutique services, and mayhem ensues.

Guys, I’m not really a rocket scientist on this, but really after all this effort, it seems to me that the #1 problem that the Government has is a lack of skilled people.  Yes, certifying people is a good thing because it helps weed out the dirtballs with a very rough sieve, but I get the feeling that maybe what we should be doing instead is trying to create more people with the skills we need.  Alas, that’s a future blog post….

However, the last thing that I want to see happen is a meta-game of what’s going on with certifications right now–who certifies those who certify?  I think it’s a vicious cycle of cross-certification that will end up with the entire Government security industry becoming one huge self-licking ice cream cone.  =)

• Now ISC2 Blogs have an Opinion on FISMA
• When the Feds Come Calling
• Splunk Goes After the FISMA Lucre, They’re not Alone
• Comments on SCAP 2008
• “Machines Don’t Cause Risk, People Do!”

Dear NIST People,

I have this semi-random digital scribbling thingie called a blog.  You might have heard of them.  Hey, you might have even at one point heard of mine.  =)

On my blog I let it be known that I am what the rest of the world would call a “NIST Cheerleader”.  I watch your every move.  I comment on your new publications.  I teach your framework every quarter.  From time to time, I criticize, but only because I have a foot in the theory of information security that you live and a foot in the implementation with agencies who know where the theory and models break.

The best thing that you have given us is not the risk management framework, it was SP 800-30, “Risk Management Guide for Information Systems”.  It’s small, to-the-point, and scalable from a single server to an entire IT enterprise.  Sure, the quants hate it, but for the quals and Government, it’s good enough.  I know private-sector organizations that use it.  One of my friends and blog readers/commenters was the guy who taught a group of people how to do risk assessment, then these same people went on to help you write the book.

I heard that you were in the process of revising SP 800-30.  While this is much needed to catch up/modernize, I want to make sure that 800-30 does not follow the “live by the catalog, die by the catalog” path that we seem to be following lately.  In other words, please don’t change risk assessment process to the following:

1. Determine boundary
2. Determine criticality
3. Conduct a gap assessment against a catalog of controls (SP 800-53/800-53A)
4. Attach a priority to mitigation
5. Perform risk avoidance because compliance models are yes/no frameworks
6. Document
7. ???
8. Profit!

At Your Own Risk Photo by  Mykl Roventine.

The reason that I am writing this is to let you know that I have noticed a disturbing trend in how now that we have a catalog of controls, the risk management framework is focusing more and more heavily on the catalog as the vehicle for determine an adequate level of security.  Some of this is good, some of this is not.

Why am I so concerned about this?  Well, inside the Government we have 2 conflicting ideas on information security:  compliance v/s risk management.  While we are fairly decent Government-wide at compliance management, the problem that we have is in risk management because risk management is only as good as the people who perform the risk assessment.  Not that we don’t have competent people, but the unknowns are what will make or break your security program, and the only way that you can known the unknowns is to get multiple assessments aimed at risks outside of the control catalog.

However, if you change the risk assessment process to a “catalog of controls gap analysis” process, then we’ve completely lost risk management in favor of compliance management.  To me, this is a disturbing trend that needs to be stopped.

Thank you for your time

–Rybolov

• Observations on SP 800-37R1
• Workin’ for the ‘Counters: an Analysis of my Love-Hate Relationship with the CPAs
• Reinventing FedRAMP
• It’s a Problem of Scale!
• Now ISC2 Blogs have an Opinion on FISMA