Posted April 26th, 2011 by rybolov
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.
Posted in FISMA, NIST, Outsourcing | 2 Comments »
Tags: 800-37 • 800-53 • accreditation • certification • cloud • cloudcomputing • compliance • fisma • government • infosec • management • NIST • risk • security
Posted April 6th, 2011 by rybolov
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.
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.
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?”
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.
Posted in FISMA, NIST, Risk Management, What Works | 5 Comments »
Tags: 800-37 • 800-39 • accreditation • assurance • auditor • C&A • certification • comments • compliance • datacentric • fisma • government • infosec • management • NIST • risk • scalability • security