I had a friend forward me today a C&A SOP from a small government agency. Other than taking NIST guidance and repackaging it in some weird morphed way that didn’t make any sense (they added a weird pre-certification phase), they missed the obvious piece: C&A is just a way to get security requirements and risk assessment into the SDLC. About 80% of the people playing the C&A game for the government think that the process goes something like this:

• Build the system
• Write a security plan
• Notify CISO that document is ready to be tested
• Auditor audits the document and makes a “you been bad” report that nitpicks about the grammar being in passive voice or you’re not using the “approved” template
• System is given a certification statement
• Somebody signs off on the accreditation
• We forget about it all until it’s time to update the security plan

OK, if you do it this way, then maybe you do need a SOP.

Then again, maybe you need a new job.

I get “wigged out” when I see SOPs for C&A. A big part of why the government is failing at security and C&A is that they have divorced the 2 activities from the rest of how they do business. You shouldn’t need a SOP for C&A any more than you would need a SOP for breathing–you should have a SDLC SOP or an engineering SOP of which security is a small but important piece.

Mike’s version of how to do C&A:

• We realize we have a need for a system
• We categorize the data and come up with a SWAG on how much it’s worth to protect
• We haggle over what security controls we should build based on our SWAG
• We start writing a security plan that lists the controls we agreed on
• We build the thing
• We do user acceptance testing and security testing concurrently or in series
• We fix problems and do regression testing
• We certify that we have implemented the controls we determined we needed
• Somebody gives the security team a vote of confidence in the form of accreditation

• Rebuilding C&A
• It’s All About Common Controls!
• Security Assessments as Fraud, Waste, and Abuse
• Observations on SP 800-37R1
• Alternative Uses for System Security Plans