Remembering Accreditation

Posted March 20th, 2008 by

Accreditation is the forgotten and abused poor relation to certification.

Part of the magic that makes C&A happen is this:  you have certification which is a verification that all the minimum security controls are in place, and then you have accreditation which is a formal acceptance of risk by a senior manager/executive.  You know what?  The more I think about this idea, the more I come to see the beautiful simplicity in it as a design for IT security governance.  You really are looking at two totally complete concepts:  compliance and risk management.

So far, we’ve been phenomenal at doing the certification part.  That’s easy, it’s driven by a catalog of controls and checklists.  Hey, it’s compliance after all–so easy an accountantcaveman could do it. =)

The problem we’re having is in accreditation.   Bear with me here while I illustrate the process of how accreditation works in the real world.

After certification, a list of deficiencies is turned into a Plan of Action and Milestones–basically an IOU list of how much it will cost to fix the deficiency and when you can have it done by.

Then the completed C&A package is submitted to the Authorizing Official.  It consists of the following things:

  • Security Plan
  • Security Testing Results
  • Plan of Actions and Milestones

The accreditor looks at the C&A package and gives the system one of the following:

  • Denial to Operate
  • Approval to Operate
  • Interim Approval to Operate (ie, limited approval)

And that’s how life goes.

There’s a critical flaw here, one that you need to understand:  what we’re giving the Authorizing Official is, more often than not, the risks associated with compliance validation testing.  In other words, audit risks that might or might not directly translate into compromised systems or serious incidents.

More often than not, the accreditation decision is based on these criteria:

  • Do I trust the system owner and ISSO?
  • Has my assessment staff done an adequate job at finding all the risks I’m exposed to?
  • What is the extent of my political exposure?
  • How much do I need this system to be up and operational right now?
  • Is there something I need fixed right now but the other parts I’m OK with?

For the most part, this is risk management, but from a different angle.  We’ve unintentionally derailed what we’re trying to do with accreditation.  It’s not about total risk, it’s about audit risk.  Instead of IT security risk management, it becomes career risk management.

And the key to fix this is to get good, valid, thorough risk assessments in parallel with compliance assessments.   That requires smart people.

Smart CISOs out there in Government understand this “flaw” in the process.  The successful ones come from technical security testing backgrounds and know how to get good, valid, comprehensive risk assessments out of their staff and contractors, and that, dear readers is the primary difference between agencies that succeed and those who do not.

NIST is coming partly to the rescue here.  They’re working on an Accreditor’s Handbook that is designed to teach Authorizing Officials how to evaluate what it is they’re being given.  That’s a start.

However, as an industry, we need more people who can do security and risk assessments.  This is very crucial to us as a whole because your assessment is only as good as the people you hire to do it.  If we don’t have a long-term plan to grow people into this role, we will continually fail, and it takes at least 3-5 years to grow somebody into the role with the skills to do a good assessment, coming from a system administrator background.  In other words, you need to have the recruiting machinery of a college basketball program in order to bring in the talent that you need to meet the demand.

And this is why I have a significant case of heartburn when it comes to Alan Paller.  What SANS teaches perfectly compliments the policy, standards, regulations, and complicance side of the field.  And the SANS approach–highly-tactical and very technologically-focused–is very much needed.  Let me say that again:  we need a SANS to train the huge volume of people in order to have valid, thorough risk assessments.

There is a huge opportunity to say “you guys take care of the policy and procedures side (*cough* the CISSP side), we can give you the technical knowledge (the G.*C side) to augment your staff’s capabilities.  But for some reason, Alan sees FISMA, NIST, and C&A as a competitor and tries to undermine them whenever he can.

Instead of working with, he works against.  All the smart people in DC know this.



Similar Posts:

Posted in FISMA, NIST, Rants, Risk Management, What Doesn't Work, What Works | No Comments »

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.


Visitor Geolocationing Widget: