Contrary to what you might hear this week in the trade press, FedRAMP is not fully unveiled although there was some much-awaited progress. There was a memo that came out from the administration (PDF caveat).  Basically what it does is lay down the authority and responsibility for the Program Management Office and set some timelines.  This is good, and we needed it a year and a half ago.

However, people need to stop talking about how FedRAMP has solved all their problems because the entire program isn’t here yet.  Until you have a process document and a catalog of controls to evaluate, you don’t know how the program is going to help or hinder you, so all the press about it is speculation.

• Reinventing FedRAMP
• NIST Cloud Conference Recap
• An Open Letter to NIST About SP 800-30
• The Guerilla CISO Rants: Don’t Write a System Security Plan
• Clouds, FISMA, and the Lawyers

Interesting blog post on Microsoft’s TechNet, but the real gem is the case filing and summary from the DoJ (usual .pdf caveat applies).  Basically the Reader’s Digest Condensed Version is that the Department of Interior awarded a cloud services contract to Microsoft for email.  The award was protested by Google for a wide variety of reasons, you can go read the full thing for all the whinging.

But this is the interesting thing to me even though it’s mostly tangential to the award protest:

• Google has an ATO under SP 800-37 from GSA for its Google Apps Premiere.
• Google represents Google Apps for Government as having an ATO which, even though 99% of the security controls could be the same, is inaccurate as presented.
• DOI rejected Google’s cloud because it had state and local (sidenote: does this include tribes?) tenants which might not have the same level of “security astuteness” as DOI.  Basically what they’re saying here is that if one of the tenants on Google’s cloud doesn’t know how to secure their data, it affects all the tenants.

So this is where I start thinking.  I thunk until my thinker was sore, and these are the conclusions I came to:

• There is no such thing as “FISMA Certification”, there is a risk acceptance process for each cloud tenant.  Cloud providers make assertions of what common controls that they have built across all
• Most people don’t understand what FISMA really means.  This is no shocker.
• For the purposes of this award protest, the security bits do not matter because
• This could all be solved in the wonk way by Google getting an ATO on their entire infrastructure and then no matter what product offerings they add on top of it, they just have to roll it into the “Master ATO”.
• Even if the cloud infrastructure has an ATO, you still have to authorize the implementation on top of it given the types of data and the implementation details of your particular slice of that cloud.

And then there’s the “back story” consisting of the Cobell case and how Interior was disconnected from the Internet several times and for several years.  The Rybolov interpretation is that if Google’s government cloud potentially has tribes as a tenant, it increases the risk (both data security and just plain politically) to Interior beyond what they are willing to accept.

Obligatory Cloud photo by jonicdao.

• Reinventing FedRAMP
• NIST Cloud Conference Recap
• Coming Soon to a Cloud Near You…
• How to Not Let FISMA Become a Paperwork Exercise
• FedRAMP: It’s Here but Not Yet Here

You should have seen Special Publication 800-39 (PDF file, also check out more info on Fismapedia.org) out by now.  Dan Philpott and I just taught a class on understanding the document and how it affects security managers out them doing their job on a daily basis.  While the information is still fresh in my head, I thought I would jot down some notes that might help everybody else.

The Good:

NIST is doing some good stuff here trying to get IT Security and Information Assurance out of the “It’s the CISO’s problem, I have effectively outsourced any responsibility through the org chart” and into more of what DoD calls “mission assurance”.  IE, how do we go from point-in-time vulnerabilities (ie, things that can be scored with CVSS or tested through Security Test and Evaluation) to briefing executives on what the risk is to their organization (Department, Agency, or even business) coming from IT security problems.  It lays out an organization-wide risk management process and a framework (layer cakes within layer cakes) to share information up and down the organizational stack.  This is very good, and getting the mission/business/data/program owners to recognize their responsibilities is an awesome thing.

The Bad:

SP 800-39 is good in philosophy and a general theme of taking ownership of risk by the non-IT “business owners”, when it comes to specifics, it raises more questions than it answers.  For instance, it defines a function known as the Risk Executive.  As practiced today by people who “get stuff done”, the Risk Executive is like a board of the Business Unit owners (possibly as the Authorizing Officials), the CISO, and maybe a Chief Risk Officer or other senior executives.  But without the context and asking around to find out what people are doing to get executive buy-in, the Risk Executive seems fairly non-sequitor.  There are other things like that, but I think the best summary is “Wow, this is great, now how do I take this guidance and execute a plan based on it?”

The Ugly:

I have a pretty simple yardstick for evaluating any kind of standard or guideline: will this be something that my auditor will understand and will it help them help me?  With 800-39, I think that it is written abstractly and that most auditor-folk would have a hard time translating that into something that they could audit for.  This is both a blessing and a curse, and the huge recommendation that I have is that you brief your auditor beforehand on what 800-39 means to them and how you’re going to incorporate the guidance.

• Opportunity Costs and the 20 Critical Security Controls
• 20 Critical Security Controls: What They Did Right and What They Did Wrong
• NIST Cloud Conference Recap
• Ooh, “The Word” is out on S 3474
• Cloud Computing and the Government

Go check it out.  The project management folks have been jokingly grilled over numerous times for being ~2-3 months late.

However, comments are being accepted until December 2nd.  Do yourselves a favor and submit some comments.

• Reinventing FedRAMP
• Old Saint NIST: Ho Ho Hold on, what’s this?
• NIST Cloud Conference Recap
• A Funny Thing Happened Last Week on Capital Hill
• FedRAMP: It’s Here but Not Yet Here

For some reason, “Rebuilding C&A” has been a perennial traffic magnet for me for a year or so now.  Seeing how that particular post was written in 2007, I find this an interesting stat.  Maybe I hit all the SEO terms right.  Or maybe the zeitgeist of the Information Assurance community is how to do it right.  Anyway, if you’re in Government and information security, it might be worthwhile to check out this old nugget of wisdom from yesteryear.

• Some Comments on SP 800-39
• GAO’s 5 Steps to “Fix” FISMA
• Old Saint NIST: Ho Ho Hold on, what’s this?
• “Machines Don’t Cause Risk, People Do!”
• Clouds, FISMA, and the Lawyers

A couple of weeks ago I went to the NIST Cloud Conference for the afternoon security sessions.  You can go grab the slides off the conference site.  Good stuff all around.

Come to think of it, I haven’t blogged about FedRAMP, maybe it’s time to.

FedRAMP is a way to do security authorization (formerly certification and accreditation, get with the times, man) on a cloud then let tenant projects use that authorization.  Hmmm, sounds like…. a General Support System with common controls and Major Applications that inherit those controls.  This isn’t really anything new, just the “bread and butter” security management concepts scoped to a cloud.  Basically what will happen with FedRAMP is that they have 3 standards: DoD, DHS, and GSA (most stringent first) and cloud providers get authorized against that standard.  Then when a project wants to build on that cloud, they can use that authorization for their own authorization package.

All things considered, FedRAMP is an awesome idea.  Now if we can get the holdout agencies to actually acknowledge their internal common controls, I’ll be happy–the background story being that some number of months ago I was told by my certifier that “we don’t recognize common controls so even though you’re just a simple web application you have to justify every control even if it’s provided to you as infrastructure.”  No, still not bitter at all here, but I digress….

And then there are the pieces that I haven’t seen worked out yet:

• Mechanism of Sharing: As a service provider, it’s hard enough to keep one agency happy.  Add in 5 of them and it gets nearly impossible.  This hasn’t really been figured out, but in Rybolov’s small, myopic world, a panel of agencies owning an authorization for a cloud provider means that the cloud never gets authorized.  The way this has been “happening in the wild” is that one agency owns the authorization and all the other agencies get the authorization package from that agency.
• Using FedRAMP is Optional: An agency or project can require their own risk assessment and authorization even though a FedRAMP one is available.  This means that if the agency’s auditors don’t understand the process or the “risk monkeys” (phrase courtesy of My Favorite Govie) decree it, you lose any kind of cost savings and time savings that you would get by participating in FEDRAMP.
• Cloud Providers Rule the Roost: Let’s face it, as much as the Government wants to pretend that the cloud providers are satisfying the Government’s security requirements, we all know that due to the nature of catalogs of controls and solution engineering, the vendor here has the advantage.  Nothing new, it’s been happening that way with outsourcing, only now it’s immediately evident.  Instead of trying to play ostrich and stick our heads in the sand, why don’t we look at the incentives for the cloud providers and see what makes sense for their role in all this.
• Inspector General Involvement: I don’t see this happening, and to be honest, this scares the hell out of me.  Let me just invoke Rybolov’s Law: “My solution is only as good as my auditor’s ability to understand it.”  IE, if the IGs and other auditors don’t understand FedRAMP, you don’t really have a viable solution.

The Big Ramp photo by George E. Norkus.  FedRAMP has much opportunity for cool photos.

• Reinventing FedRAMP
• Cloud Computing and the Government
• FedRAMP: It’s Here but Not Yet Here
• Clouds, FISMA, and the Lawyers
• How to Not Let FISMA Become a Paperwork Exercise