The Patchwork Cloud - Cloud Service Providers, security and incentives

[#1]

Sometimes, a fellow colleague in the industry hits a point so well it's worth repeating and expanding on it.  I'm referring to Dave Shackleford's post title "The Cloud's Low-Rent District".  Dave nails the point perfectly discussing positive incentives for Cloud Service Providers (CSPs) and whether they work - or whether another approach is needed, a more negative approach.  While I'm participating in the Cloud Security Alliance (CSA) and their efforts to create standards - I think I'd be delusional if I believed every provider will jump on the CSA STAR bandwagon and provide fantastic levels of security to their customers.

Let's face it, asking providers to voluntarily disclose the ins and outs of their security posture, and more importantly their deficiencies, is a little bit of a stretch.  Understandably, as far as standards bodies go, the first step you want to take is to give providers a chance to voluntarily step up to the place and attest to their security practices and adherence to pre-defined controls.  The unfortunate fact is, only the top-notch providers will do this because they're already meeting most of the requirements and controls.  A CSP (cloud service provider) who isn't doing well at meeting the security controls and not meeting requirements has two options - simply ignore the voluntary attestation and stay off the STAR registry, or only answer certain parts that they're comfortable with.  This isn't necessarily a good thing or a bad thing... all I'm saying is that a scenario like this makes it impossible to have a level playing field.

On the other side of that coin, the effort to create a standards body which could enforce adherence to pre-defined controls would be monumental and probably not likely to happen except in the government space like with the CJIS security rules enforcement.  Similarly, forcing CSPs to even self-certify against the STAR rules and publish the results is similarly difficult - and logic tells us why.  If I as a provider I'm particularly poor at something I would rather not tell everyone, particularly prospective customers, about that.  This leaves the customer with some problems when they're trying to figure out just where to go for their cloud provider needs.

Dave's proposal, like many others have suggested, is to create a "Wall of Shame" which would not highlight the well-mannered providers, but shame the ones that perform poorly.  This would allow customers to disclose poor service, incidents and breaches, and lax security controls at the providers they buy into.  Of course, today this is against most of the contracts you the customer signs off on, so that makes life a little bit difficult, legally speaking, so what are the alternatives?  Taking this thought further, do we really want to go down the road of shaming to make companies care?  I'm sure that effective but much like negative political campaigns - no one leaves that table without dirt on their hands.

Is there some sort of middle-of-the-road third option here?  I know its impractical (and unconscionable) to ask for a governmental interference here ... but there has to be another option.

Ultimately though, whether we go with the negative or positive reinforcement, it'll be up to the customers to make the choice which to support, and whether it will be effective.  If the customers stand up and refuse to work with providers that haven't joined the CSA STAR registry (as an example) then it will force providers to play along or lose business opportunities.  After all, vendors respond best when money  is on the line, I've learned that from years as a customer.  I think in the end, the customer response, their demand, that vendors provide evidence of effort will ring louder than any wall of shame ever could.

But, as Jeremy Clarkson from my favorite show Top Gear would say, there's a problem.  If customers are going to demand Cloud Service Providers adhere to an attestation or audit standard against a set of controls, it has to be a single set or a single standard.  You can't have 20 different controls "standards" with another 20 different attestation/audit guidelines for them, that simply won't work.  This is the main problem I think we're facing right now, in the industry.  It's not that we don't have standards, it's that no one can agree on a single governing one.  So here's my simple three-step plan for moving Cloud Security forward...

1. Industry agrees on a single unifying set of security controls plus an audit guidelines (or attestation like the CSA STAR registry)
2. Customers demand their CSPs adhere to and show proof of audit against this standard or simply reject the vendor
3. CSPs all are pushed into a common set of security controls and audit guideline

Now ... I wish it were that simple.  All joking aside though, this problem starts and ends with you the customer.  So get on it.  Demand a single standard, and then demand your vendors to get with it.  Then maybe in 5 years we'll get better at cloud security.

There. Everyone wins. I've solved it.

Credit for this little bit goes to Dave for making me think about it, and getting my brain started :)

[#2]

That wall of shame already exists to a degree. A CSP failure potentially falls under three projects run by the Open Security Foundation (OSF), that track different aspects of a failure:

Cloutage - for those CSPs that claim 99.99999 uptime that don't know basic math, or understand that 24 hours of downtime means the 99-five-9 thing is untrue, OR they have to have 100% uptime for several years after.

DatalossDB - for those CSPs that spill their customer data all over the Internet, often due to silly mistakes, SQL Injection 101, or something equally basic.

OSVDB - for those CSPs that rely on COTS or open source software that tends to be riddled with vulnerabilities.

The data sets are not complete, due to a lack of volunteers and donations, but just based on the initial efforts of those projects, they paint a compelling picture of why most organizations have failed, some multiple times, and why we need better metrics and data sets for this type of thing.