Cloud Security Concerns Within The Infrastructure: Open Door Policy?
As I mentioned last week I attended the first in a four-part series on Cloud Computing hosted by WTIA (next meeting at Amazon btw, really looking forward to that).
While none of the presentations at the first meeting involved security, it was ever-present in my mind throughout the evening. This is how my mind works: someone talks about distributing processes across multiple CPUs and I think “New area for MitM attack? Plant one bad instruction and DoS the whole thing, or worse, siphon off all proc data?” One area that stuck with me since that evening was the security within each of the vertical cloud infrastructure levels (top down: App, Platform, Language, Hardware, according to Aaron Kimball) and more specifically how future security threats may impact each of those levels.
For example, what happens when there is an exploit in the Language layer, one that is inherited all the way up the App and spans multiple Apps? And then what happens if the Hardware layer (the IaaS component) is told to spin, down, or delete VMs based on App events? Cloud services are made up of many moving and interdependent components. An exploit in any one piece can be felt across the entire platform, or the Cloud Stack if you will. An exploit in the middle could traverse the cloud stack up one way and then down the other.
So why is this different than the risk against localized data center components today? Two reasons:
- All four cloud stack layers are inter-related and equally shared. A fully fledged cloud system could pull any number of solutions from any layer and plug them together.
- Traditional data center computing is linear and uni-directional: requests come in, wait, responses go out, rinse, repeat. With the cloud data becomes non-linear and multi-directional. Simply stated, there are more ways to get at the payload. It becomes more difficult to exploit an entire system when you only have access through one door. However with the multi-entry architecture of the cloud there are more doors (and windows and crawlspaces and attics). Rather than all beating down one door, attackers can flank the cloud and attack multiple entry points.
It’s these differences that give me pause. More than any other attackable group of technologies (desktop OS, server OS, network, web apps, etc) I believe attacks against any part of the cloud structure represent more of a business threat than a pure security threat. Business are going to come to rely so heavily on the cloud that the cloud will soon host a good portion of their mission critical data (to what level it’s not already today). If there’s a major public exploit against the pieces of the cloud that everyone has access to, well then that’s no good for anyone, or their proprietary data.
And what about ownership and responsibility? What liability will AWS or Azure have if there’s a breach in the App Infrastructure (outside their control) that trickles down to the Hardware level (inside their control)? How can we expect the really large cloud providers such as Amazon and Microsoft to respond? Will we see a new market and need for Incident Responders solely focused on the cloud? Jet Fighters if you will – yes, my goal is to push these Cloud analogies as far as I can, and the sky’s the limit (see, this will be fun!).
These are the ideas I worry about with the cloud. I would love to see more time and focus put on analyzing the risks for both cloud providers and end-user businesses pushing their services into the cloud on shared platforms. Sounds like an excellent job for my first batch of security recruits: Jet Fighters in Training.
February 10th, 2009 at 11:44 am
Alan:
This is exactly the reason I built the Cloud Taxonomy/Ontology model so that one can not only clearly what makes up the components within the SPI model, but also map them to the controls that are needed (it’s in my next preso — and the one I’m giving today.)
As to your question, I have to ask if you’re being serious or tongue-in-cheek when you ask:
“And what about ownership and responsibility? What liability will AWS or Azure have if there’s a breach in the App Infrastructure (outside their control) that trickles down to the Hardware level (inside their control)?”
…have you read the SLA’s and ToS of these providers? If not, you have your answer.
This is not very different than any scenario where a monoculture exists — just look at Microsoft’s OS layer and that ought to tell you exactly what the future looks like in terms of vulnerabilities, exploits and incident response.
Here’s something I wrote back in October of last year titled “Patching the Cloud?” http://rationalsecurity.typepad.com/blog/2008/10/patching-the-cloud.html
Good discussion…
/Hoff
February 10th, 2009 at 12:02 pm
Hoff,
Thanks for the feedback. Oh yeah, I’m serious about the liability and responsibility question. I hear you on how they’re trying to push this off today via ToS’, but we only need to wait until someone snarfs financial or healthcare data from the cloud and we’ll see how the big providers respond (depending on which unlucky one has to deal with this first).
Your Oct post is a good one. I’m enjoying watching these smaller pieces (OS, network, apps) come together in bundled services through the cloud that connect with other bundled services. And for me, that really where the security woes start to come in. As more pieces are added and opened up and taken out of our control, well you know how this story ends: go boom.
-A