Pet peeve of just about every CISO in existance:  the so-called “audit requirements”.  What they really mean to say is “It’s on the checklist, so it has to be true, just do what I say”.

Without traceability to the actual requirement, items on a checklist are just that: items on a checklist.

Anyway, on to the lulz:

• Auditors and LULZ
• IKANHAZFIZMA Tackles the Consensus Audit Guidelines
• LOLCATS Take on MS08-67
• Continuous Monitoring with LOLCATS
• The Authorizing Official and the Lolcat

Ever feel lost and lonely when staring at the business end of an ST&E?  Confounded and confused considering Configuration controls?  Perplexed and Puzzled at Planning procedures?  Anxious or amazed at Audit and Accountability assessments?  Annoyed at aimless alliteration?

NIST has heard your muttered curses and answered them!  (Except the annoying alliteration, which is my fault.)

Now available are the Assessment Cases for Special Publication 800-53A.  The Assessment Cases offer supplemental guidance on assessing security controls found in the recently released SP 800-53A Guide for Assessing the Security Controls in Federal Information Systems (PDF Warning).  These documents are in their Initial Public Draft so be sure to give them a look and provide some feedback.

The Assessment Cases contain consensus recommendations from the Assessment Cases Project on specific actions to perform when assessing security controls.  These specific actions are intended to complement the assessment procedures documented in NIST SP 800-53A.   Yes, you heard that right, Specific Actions.  Less time spent pondering how to “Examine: … other relevant documents or records”.

The Assessment Cases Project is an inter-agency workgroup headed by DoJ with members including NIST, DoE, DoT and ODNI-CIO.  Many thanks for the hard work of this workgroup’s membership.  You may not be able to hear it but I am applauding on this side of the keyboard.  And a big thanks to Patrick O’Reilly for pointing me to this wonderful resource.

• How to Not Let FISMA Become a Paperwork Exercise
• SP 800-53A Now Finally Final
• An Open Letter to NIST About SP 800-30
• Special Publication 800-53 Revision 3 Workshop
• The Guerilla CISO Rants: Don’t Write a System Security Plan

Post summary: We’re not ready yet culturally.

What spurred this blog post into being is this announcement from ServerVault and Apptis about a Federal Computing Cloud.  I think it’s a pretty ballsy move, and I’ll be watching to see if it works out.

Disclaimer being that at one time I managed security for something similar in a managed services world, only it was built by account with everything being a one-off.  And yeah, we didn’t start our organization the right way, so we had a ton of legacy concepts that we could never shake off, more than anything else about our commercial background and ways of doing things.

Current Theory on Cloud Computing photo by cote.

The way you make money in the managed services world is on standardization and economy-of-scale.  To us mere mortals, it means the following:

• Standardized OS builds
• Shared services where it makes sense
• Shared services as the option of choice
• Split your people’s time between clients
• Up-charge for non-standard configurations
• Refuse one-off configurations on a case-by-case basis

The last 2 were our downfall.  Always eager to please our clients, our senior leadership would agree to whatever one-offs that they felt were necessary for client relationship purposes but without regard to the increased costs and inefficiency when it came time to implement.

Now for those of you out in the non-Government world, let me bring you to the conundrum of the managed services world:  shared services only works in limited amounts.  Yes, you can manage your infrastructure better than the Government does, but they’ll still not like most of it because culturally, they expect a custom-built solution that they own.  Yes, it’s as simple as managing the client’s expectations of ownership v/s their cost savings, and I don’t think we’re over that hurdle yet.

And this is the reason: when it comes to security and cloud computing, the problem is that you’re only as technically literate as your auditors are.  If they don’t understand what the solution is and what the controls are around it, you do not have a viable solution for the public sector.

A “long time ago” (9000 years at least), I created the 2 golden rules for shared infrastructure:

• One customer cannot see another customer.
• One customer cannot affect another customer’s level of service.

And the side-rules for shared infrastructure in the public sector:

• We have a huge set of common controls that you get the documentation to.  It will have my name on it, but you don’t have to spend the money to get it done.
• It’s to my benefit to provide you with transparency in how my cloud operates because otherwise, my solution is invalidated by the auditors.
• Come to us to design a solution, it’s cheaper for you that way.  I know how to do it effectively and more cheaply because it’s my business to know the economics of my cloud.
• You have to give up control in some ways in order to get cost savings.
• There is a line beyond which you cannot change or view because of the 2 golden rules.  The only exception is that I tell you how it’s made, but you can’t see any of the data that goes into my infrastructure.
• If I let you audit my infrastructure, you’ll want to make changes, which can’t happen because of the 2 golden rules.
• I’ll be very careful where I put your data because if your mission data spills into my infrastructure, I put myself at extreme risk.

So, are ServerVault and Apptis able to win in their cloud computing venture?  Honestly, I don’t know.  I do think that when somebody finally figures out how to do cloud computing with the Federal Government, it will pay off nicely.

I think Apptis might be spreading themselves fairly thin at this point, rumor has it they were having some problems last year.  I think ServerVault is in their comfort space and didn’t have to do too much for this service offering.

I can’t help but think that there’s something missing in all of this, and that something is a partnering with the a sponsoring agency on a Line of Business.  FEA comes to mind.

• NIST Cloud Conference Recap
• Reinventing FedRAMP
• Categories of Security Controls in Outsourcing
• Database Activity Monitoring for the Government
• Security Assessments as Fraud, Waste, and Abuse

Let’s face it, compliance in IT security is a myth.  Compliance in IT security with legacy systems is like a chupacabbra riding a white unicorn chasing a leprechaun while waving Excalibur.  And the auditors just shake their head and wonder why you can’t just comply.

Anyway, on to the LOLCATZ (note that I’m getting all creative-stylie with haikus this week, must be something in the beer last night):

• Government Akountability Office
• Auditors and LULZ
• Continuous Monitoring with LOLCATS
• Audit Requirements come to LOLCATS
• Exhaustive Security Testing is Bad For You

Hot on the heels of Security Assessments as Fraud, Waste, and Abuse comes this heartwarming lolcat.

• The Authorizing Official and the Lolcat
• Look Out, Sir Bruce, IKANHAZFIZMA is Coming for You
• Snowmageddon Meets the IKANHAZFIZMA Lolcats
• Happy New Year
• IKANHAZFIZMA Finds Caution Tape

I’m going to put on my Government Security Heretic Hat for awhile here, bear me out.  By my estimate, half of the security assessments received by the Government have some kind of fraud, waste, and abuse.

What makes me say this is the amount of redundancy in some testing that I’ve seen without any value added.

The way to avoid this redundancy is the concept of common/shared controls.  The whole idea is that you take whatever security controls you have across the board and put them into one bucket.  You test that bucket once and then whenever something  shares controls with that bucket, you look at the shared control bucket and make sure that the assessment is still relevant and accurate.

So, what makes a security assessment not fraud, waste, and abuse?  It’s a good assessment if it does the following:

• Does not repeat a previous assessment.
• Discovers previously-undiscovered vulnerabilities, weaknesses, or findings.
• Has findings that get fed into a risk management plan (accepted, avoided, transferred, etc–think POA&M).
• Is not exhaustive when it doesn’t need to be.
• Provides value to the project team, system owner, and Authorizing Official to make key decisions.

Now the problem is that the typical auditor has a hard time stopping–they have an ethical obligation to investigate anything that their “professional skepticism” tells them is out of place, just like cops have an ethical obligation to investigate anything that they think is a crime.

The Solution?  Don’t use auditors! The public accounting model that we adopted for information security does not scale the way that we need it to for ST&E, and we need to understand this in order to fix security in the Government.

What we need to be doing is Security Test and Evaluation which is focused on risk, not on compliance using a checklist of control objectives.  Usually if you know enough to say “Wow, your patch management process is whacked, you’re at a high risk!” then that’s enough to stop testing patch management controls.  This is one of the beefs I have with 800-53A in the hands of less-than-clueful people:  they will test until exhaustion.

There isn’t a whole lot of difference between ST&E and an audit, just the purpose.  Audits are by nature confrontational because you’re trying to prove that fraud, waste, and abuse hasn’t occured.  ST&E is helping the project team find things that they haven’t thought of before and eventually get the large problems funded and fixed.

The Little Frauds Harrigan & Hart’s Songs & Sketches Photo by Boston Public Library

• How to Not Let FISMA Become a Paperwork Exercise
• Cloud Computing and the Government
• Some Thoughts on POA&M Abuse
• 20 Critical Security Controls: Control-by-Control
• An Open Letter to NIST About SP 800-30