Rational Survivability

I’m grumpy, confused and scared.  Classic signs of shock.  I can only describe what I’m feeling by virtue of an analog…

There’s a scene in the movie Jaws where Chief Brody, chumming with fish guts to attract and kill the giant shark from the back of the boat called “The Orca,” meets said fish for the first time.  Terrified by it’s menacing size, he informs [Captain] Quint “You’re gonna need a bigger boat.”

I felt like that today as I read through the recently released draft of the long-anticipated FedRAMP documents.  I saw the menace briefly surface, grin at me, and silently slip back into the deep.  Sadly, channeling Brody, I whispered to myself “…we’re gonna need something much sturdier to land this fish we call cloud.”

I’m not going to make any friends with this blog.

I can barely get my arms around all of the issues I have.  There will be sequels, just like with Jaws, though unlike Roy Schneider, I will continue to be as handsome as ever.

Here’s what I do know…it’s 81 pages long and despite my unhappiness with the content and organization, per Vivek Kundra’s introduction, I can say that it will certainly “encourage robust debate on the best path forward.”  Be careful what you ask for, you might just get it…

What I expected isn’t what was delivered in this document. Perhaps in the back of my mind it’s exactly what I expected, it’s just not what I wanted.

This is clearly a workstream product crafted by committee and watered down in the process.  Unlike the shark in Jaws, it’s missing it’s teeth, but it’s just as frightening because its heft is scary enough.  Even though all I can see is the dorsal fin cresting the water’s surface,  it’s enough to make me run for the shore.

As I read though the draft, I was struck by a wave of overwhelming disappointment.  This reads like nothing more than a document which scrapes together other existing legacy risk assessment, vulnerability management, monitoring and reporting frameworks and loosely defines interactions between various parties to arrive at a certification which I find hard to believe isn’t simply a way for audit companies to make more money and service providers to get rubber-stamped service ATO’s without much in the way of improved security or compliance.

This isn’t bettering security, compliance, governance or being innovative.  It’s not solving problems at a mass scale through automation or using new and better-suited mousetraps to do it.  It’s gluing stuff we already have together in an attempt to make people feel better about a hugely disruptive technical, cultural, economic and organizational shift.  This isn’t Gov2.0 at all.  It’s Gov1.0 with a patch.  It’s certainly not Cloud.

Besides the Center for Internet Security reference, there’s no mention of frameworks, tools, or organizations outside of government at all…that explains the myopic focus of “what we have” versus “what we need.”

The document is organized into three chapters:

Chapter 1: Cloud Computing Security Requirement Baseline
This chapter presents a list of baseline security controls for Low and Moderate
impact Cloud systems. NIST Special Publication 800-53R3 provided the foundation
for the development of these security controls.

Chapter 2: Continuous Monitoring
This chapter describes the process under which authorized cloud computing systems
will be monitored. This section defines continuous monitoring deliverables,
reporting frequency and responsibility for cloud service provider compliance with
FISMA.

Chapter 3: Potential Assessment & Authorization Approach
This chapter describes the proposed operational approach for A&A’s for cloud
computing systems. This reflects upon all aspects of an authorization (including
sponsorship, leveraging, maintenance and continuous monitoring), a joint
authorization process, and roles and responsibilities for Federal agencies and Cloud
Service Providers in accordance with the Risk Management Framework detailed in
NIST Special Publication 800-37R1.

It’s clear that the document was written almost exclusively from the perspective of farming out services to Public cloud providers capable of meeting FIPS 199 Low/Moderate requirements.  It appears to be written in the beginning from the perspective of SaaS services and the scoping and definition of cloud isn’t framed — so it’s really difficult to understand what sort of ‘cloud’ services are in scope.  NIST’s own cloud models aren’t presented.  Beyond Public SaaS services, it’s hard to understand whether Private, Hybrid, and Community clouds — PaaS or IaaS — were considered.

It’s like reading an article in Wired about the Administration’s love affair with Google while the realities of security and compliance are cloudwashed over.

I found the additional requirements and guidance related to the NIST 800-53-aligned control objectives to be hit or miss and some of them utterly laughable (such as SC-7 – Boundary Protection: “Requirement: The service provider and service consumer ensure that federal information (other than unrestricted information) being transmitted from federal government entities to external entities using information systems providing cloud services is inspected by TIC processes.”  Good luck with that.  Sections on backup are equally funny.

The “Continuous Monitoring” section requirements wherein the deliverable frequency and responsibile party is laid out engenders a response from “The Princess Bride:”

You keep using that word (continuous)…I do not think it means what you think it means…

Only 2 of the 14 categories are those which FedRAMP is required to provide (pentesting and IV&V of controls.)  All others are the responsibility of the provider.

Sigh.

There’s also not a clear distinction that in a service deployed on IaaS (as an example) where anything in the workload’s VM fits into this scheme (you know…all the really important stuff like information and applications) and how agency processes intersect with the CSP, FedRAMP and the  JAB.

The very dynamism and agility of cloud are swept under the rug, especially in sections discussing change control.  It’s almost laughable…code changes in some “cloud” SaaS vendors every few hours.  The rigid and obtuse classification of the severity of changes is absolutely ludicrous.

I’m unclear if the folks responsible for some of this document have ever used cloud based services, frankly.

“Is there anything good in the document,” you might ask?  Yes, yes there is. Firstly, it exists and frames the topic for discussion.  We’ll go from there.

However, I’m at a loss as how to deliver useful and meaningful commentary back to this team using the methodology they’ve constructed…there’s just so much wrong here.

I’ll do my best to hook up with folks at the NIST Cloud Workshop tomorrow and try, however if I smell anything remotely like seafood, I’m outa there.

/Hoff

Related articles

• Feds Roll Out Cloud Security Guidelines (informationweek.com)
• Administration Proposes Security Requirements For Cloud Computing (techdailydose.nationaljournal.com)
• New Standards for Governmental Agencies on Cloud Computing Security (blogs.csoonline.com)
• Feds Discover 1,000 More Data Centers (datacenterknowledge.com)
• What’s The Problem With Cloud Security? There’s Too Much Of It… (rationalsurvivability.com)
• Hoff’s 5 Rules Of Cloud Security… (rationalsurvivability.com)