The Cloud Advocate: IaaS a Shared Responsibility

The Cloud Advocate: IaaS a Shared Responsibility

Dean OcampoJune 14, 2011, 03:42 pm

Panic. Bedlam. Lawlessness. Anarchy. For some reason the cloud conjures visions of chaos for organizations moving to the cloud. And I guess in retrospect it’s really no surprise given the sea change that the cloud model represents to our industry. To add to the confusion is a schizophrenic cry of “everything in the cloud is different” and “everything in the cloud is the same” from different corners of the industry. In truth they are both right. There is a tremendous amount of what you do in the cloud is identical to what you did in the traditional data center. It’s not like Newtonian physics went out the window or “Q” somehow reversed the constants of the universe. Life goes on as it did before, but just a little different.

The easiest way to look at this is to think of the cloud from an OSI model perspective. And for simplicity’s sake lets’ focus on IaaS (Infrastructure as a Service). Your cloud provider is going to own everything at and below the hypervisor, shimmed in just below your OS. You own everything above. So when we look at the world, this is what I would expect (BTW, I will be discussing these same issues on an upcoming webcast with Amazon AWS):

Things in the Cloud that are the same:

Your IaaS provider is on the hook for physical security and the proper vetting and training of employees. They own the switch fabric and are responsible for the proper segmentation and VLANing. They also own, to some degree, the network isolation around you as a customer within their IaaS environment. Yes, you will have your own firewalling and topology to work with, but they are responsible for separating you from the other “tenants” in the multi-tenant architecture. I would expect them to deploy good firewalls with proper configuration. I expect them to take care of DNS integrity and proper routing. Other than that, IaaS is pretty much the playground for your organization.
On the flip side, as a customer, you would still be responsible for patch management. Yes, even if the IaaS provider gave you the instance, you are still on the hook for patch and configuration management. You’re still responsible for host integrity and anti-malware. You’re responsible for configuration control, proper training and vetting of employees who work with these systems, and building a solid security and change management process around it. You are responsible for application code on top of it, adhering to secure coding principles and practices, and even conducting regular security reviews and possible pen testing. Nothing really new here.

What is new is the demarcation. And this is where I think a few simple (OK, not so simple I guess given the amount of angst out there) to ensure a clean hand-off of the demarcation and acknowledge that the cloud model is slightly different. So in the end there are two essential questions an organization must ask themselves: A) Can my IaaS provider ensure that they are providing the level of due care that I expect in the part of the OSI stack that they own- i.e. everything at and below the hypervisor and B) Do I have controls in place to assume that the part of the stack that I own has the same ownership, isolation, and integrity controls that I had when *I* owned the infrastructure. Those simple questions drive what *is* different about the cloud. And this is what I would expect:

Things that you do to account for the things that are different:

Your cloud provider needs to attest to and document the controls that they have in place at the hypervisor and below. Typically this is done in a SAS 70 for controls, ISO 27001 for process, and other assurances they would provide you at service purchase. In some cases this could be spelled out in the contractual process- although that is an entire article onto itself. And you should have the audit controls in place to ensure this is a continuous process. Even better when your cloud provider has their infrastructure PCI certified- I’m winking at you Amazon AWS :)
You need to ensure that the instances and data placed on top of the hypervisor are secured. In theory, if we lived in a perfect world your existing data protection practice and risk management process would naturally take care of this. <I’ll pause for a moment to let you stop laughing> Yes, the ugly truth is this is where customers run into problems. I don’t want to make light of the problem, but I really think this entire issue is because of one single assumption- if we owned the physical infrastructure around the server we could live with a weak data protection strategy*. And that’s it. For most of us, since we locked down the servers, trained our employees, firewalled the crap out of networks, and could laser-watch our servers we could make a fair assumption that we had a reasonable data protection strategy. Heck, PCI even codified it when they backed off on the data at rest encryption requirements by allowing compensating controls. And BTW, the compensating controls are base on you guessed it, physical ownership and server isolation. So at the end of the day, there is going to be little choice but to use encryption as a fundamental way to re-exert ownership of the stack above the hypervisor. And it solves separation of duties issues. Oh, and resolved lawful order issues. Oh, and the auditors like it. Oh, and there are solutions that do this. Isn’t life grand when we do things right? I love it when a plan comes together.

And the happy ending

In reality there is no need to panic, just be realistic what is in the purview of your domain, demand visibility in accountability in what is not, and re-exert control over what you own in IaaS. With this in place we’ll all end up on the other side of the cloud revolution basking on the beach… until the next disruptive technology comes into being. –Dean

*BTW, how’s that assumption working for you given the data breaches and APT attacks that are ripping through the globe?