Cloud Security: Want Some Fake Fries With That Vapor Shake?

Wednesday, December 30, 2009

Recently I stumbled upon the Cloud Security Alliance’s “Security Guidance for Critical Areas of Focus in Cloud Computing V2.1” [1] and took a quick step back at this statement: Cloud computing is about gracefully losing control while maintaining accountability even if the operational responsibility falls upon one or more third parties. In being fair and logical about my interpretation of this statement, I tried to break it down into layman’s terms. So here’s my take: Cloud computing will relieve me of my responsibilities temporarily. While I won’t have control over much, I will however be responsible if I don’t ensure that the provider is up to par and is willing to protect my ASSets as well as I would.

Reading on, I took note of the following:  “Amazon’s AWS EC2 infrastructure as a service offering, as an example, includes vendor responsibility for security up to the hypervisor, meaning they can only address security controls such as physical security, environmental security, and virtualization security. The consumer, in turn, is responsible for security controls that relate to the IT system (instance) including the operating system, applications, and data.” For me, that translated to: “We’ll protect our own hardware and hope folks like Joanna Rukowska [JR], Halvar Flake [HF], Dave Aitel [DA] and others keep their 0day just that: 0day.”

Security is a vast project on one’s own infrastructure, let alone trying to implement security models, frameworks and architecture in an environment where, as we’ve read: “…operational responsibility falls upon one or more third parties.” Outside of all the hype and marketing of cloud services, the logic makes little sense. On the one hand, many are driven to cloud services by the lure of lower operating costs. On the other hand, reality paints a different picture in the sense of a compromise – the cost could potentially bankrupt you!

Security professionals across the spectrum are aware that many financial institutions rarely report incidents when they occur. Their logic is: “If our customer’s found out about these incidents, we’d be through!” With statements such as those, it shouldn’t take a rocket scientist to sit back and post the question to themselves: “If my cloud provider was compromised, would they notify me? Would my data be affected? Would I get burned?” It has already been disclosed that a botnet was found lurking on Amazon’s EC2 recently [2], but the potential of a virtualized compromise is so “high tech” that many don’t ponder the notion of that high risk even though the proof is right under their eyes: “Virtualization has been the best thing that has happened to foreign intelligence since Aldrich Ames.” [3]

So, why are so many security professionals missing the point about the cloud being insecure? My conclusion slash guess is that there is far too much money and marketing poured into the cloud from cloud providers to squelch those who dare question “security in the cloud.” Getting back to the document “Security Guidance for Critical Areas of Focus in Cloud Computing V2.1“, I actually had to stop and recite that title aloud a few times, and after reading the document and reading the title, I simply felt cheated and confused.

For starters, not only is the document’s title very long, it seems to be a mash-up of overwhelming cross-referenced information that is so convoluted and mixed-up with so many frameworks, theories and guidelines that I seriously paused and then stared like a deer in headlights – asking myself over and over: huh?. Many of the guidelines mentioned are useless right about now, and I’m not stating this to take credit away from the authors of NIST documents, etc., but facts are facts. Threat landscapes change so fast that by the time something does make its way out of NIST, it’s old hat. Care to take a chance securing your business according to someone else’s baseline? Knowing fully well your needs, goals and objectives will almost always differ? Or are you satisfied when solely playing the CYA (Cover Your Ass) game here?

I believe individuals in organizations like the Cloud Security Alliance are on par with security methods however, those methods, decrees, “theories”, etc., are not a “one size fits all” by any stretch of the imagination. In fact, I look at them as nothing more of “well this is how I’d secure my cloud and you should follow in my footsteps!” documents, well thought out, very well written, yet lacking. Maybe its the engineer slash admin slash architect in me.

In the end, I decided to cave in and play the game by answering the Cloud Security Alliance’s 6 questions. I’ll post my answers and leave the rest of the article at that. You too should answer these questions if you choose to leave your security in the cloud. That’s definitely where it will be – in the cloud.

1. How would we be harmed if the asset became widely public and widely distributed?
Gee, I never thought about this, but I guess if I’m a software developer and my code leaked, I’d be broke in no time.

2. How would we be harmed if an employee of our cloud provider accessed the asset?
Holy wow! I never thought about this one, but I guess if a cloud worker was pissed off [4], my business would be up the creek in a boat with no paddle.

3. How would we be harmed if the process or function were manipulated by an outsider?
Golly. I never thought about this. Do you mean… if say, the provider was DDoS’d [5] and my server and its services failed miserably? I guess that on a “Black Friday” I could lose millions instantly. Millions in one day for trying to save thousands via the cloud

4. How would we be harmed if the process or function failed to provide expected results?
Gee, did they just reword question number three for me?

5. How would we be harmed if the information/data were unexpectedly changed?
Oh, I don’t know… Let’s say a rogue CEO had an admin run timestomp prior to e-Discovery, would the CTO, CSO, CISO take the heat from the prosecutor? I don’t worry about that, because we all know admins don’t do those kinds of things… Sort of like reference 6 below: On the other hand, if an incompetent cloud worker accidently deleted the cloud, I guess I’d be hurt! But that doesn’t happen either [7]… Well, most of the time it doesn’t happen anyway.

6. How would we be harmed if the asset were unavailable for a period of time?
If we can’t depend on one of the foremost leaders in computing to keep their servers up, should we depend on “OMG-This-Is-An-Overmarketed-Cloud-Provider.com”?

[1] http://www.cloudsecurityalliance.org/csaguide.pdf
[2] http://securitywatch.eweek.com/botnets/amazon_ec2_used_as_botnet_command_and_control.html
[3] http://seclists.org/dailydave/2009/q2/52
[4] http://www.internetnews.com/government/article.php/3799976
[5] http://www.theregister.co.uk/2009/12/24/ddos_attack_ultradns_december_09/
[6] http://www.nj.com/news/index.ssf/2009/11/fbi_arrests_two_former_compute.html
[7] http://www.theregister.co.uk/2008/08/28/flexiscale_outage/
[8] http://www.techcrunch.com/2009/09/01/gmail-now-really-down-can-i-get-my-email-back-please/
[JR] http://www.invisiblethings.org/
[HF] http://addxorrol.blogspot.com/
[DA] http://www.eweek.com/c/a/Security/The-15-Most-Influential-People-in-Security-Today/11/

Original Post:http://www.theaeonsolution.com/security/?p=131
Possibly Related Articles:
10311
Cloud Security Enterprise Security
Cloud Security Enterprise Security Virtualization
Post Rating I Like this!
Default-avatar
Andy Slater This article is uber-negative. Just get over it, it's happening! I agree that a Amazon's model has it's frailities, mainly driven by it's need to be "open", high volume with a utility approach. Security aboslutely has to be centric to cloud architecture, there are other ways - so let's hear some positive comments on how we should be building a secure cloud and what sacrificies we have to take to get a happy medium.
1262278674