You read a lot about cloud security and there are a daily assortment of articles addressing it. It’s for good reason given that security is often quoted as the number one inhibitor for organizations that are considering moving some of their workloads to the cloud. But most of the articles focus on the same basic principles and if you list those out, you’ll quickly notice that many of them align with traditional security concerns and aren’t necessarily specific to cloud deployments.
That is now starting to change. As more organizations and governments move their workloads to the cloud, they are going to demand more advanced next generation security measures that ensure trust at every level within a cloud infrastructure. It will no longer be acceptable for cloud providers and service providers to just focus on their traditional north/south and east/west security measures provided by VLANs, firewalls, etc. A few of the items that will need to be addressed are outlined below.
Establishing Hardware Root of Trust
This is the most fundamental element of providing trust attestation within a cloud environment. Who cares if you are running the most secure hypervisor on the market and are encrypting your data both in flight and at rest if you haven’t established that the hosts within your clusters are free of malicious software? BIOS, rootkit, and firmware attacks will become more common as hackers and the organizations/goverments they represent become even more sophisticated and complex. Try asking your cloud provider how they prevent against a rootkit attack that would compromise their hosts, thereby compromising the hypervisors and the VMs running on them. I know the answer you will get and the story isn’t a good one. Providers need ways to guarantee that the hosts boot in a trusted state before the hypervisors are loaded and then they need to validate that the hypervisors themselves load in known good configurations. These need to happen before any VM is allowed to run or be migrated onto a particular host.
Building Trusted Resource Pools
Once you have figured out how to best establish hardware root of trust for an individual host, it then becomes important to verify all members within a particular resource pool are also trusted. Assume that you have figured out a solution for the problem outlined above. You instantiate your VM on a trusted host. Most likely, you will take advantage of being able to move your VMs around at some point for better resource allocation, maintenance, failures, etc. After all, that is one of the key benefits you gain by going with a cloud deployment. Well if you can’t guarantee that all the hosts within your cluster are trusted as well, you still have a security problem. You don’t want your secure VM running on your trusted hypervisor that is running on a trusted host to move to another host that can’t provide those same levels of attestation. So you need some way to validate that your entire pool of resources are trusted and if you get a host that isn’t in compliance with your policies, that host needs to somehow be flagged so that secure VMs aren’t migrated to it until the gap is addressed.
Geolocation Validation and Verification
This one is important and comes into play most when considering public or hybrid cloud providers. If an organization moves their workload to a public cloud provider, chances are that provider has cloud pods in multiple locations. Most will also reserve the right to move your workloads/VMs to any location they choos within their cloud to support SLAs, maintenance windows, capacity growth/shift, or whatever reason that may come up. As of today, you can migrate a VM from one host to another up to about 1000 miles before you start running into latency and delay issues. There are a lot of things that must be considered to make this happen and I won’t address those here. But for the sake of talking about this issue, just assume you can migrate a VM from one data center to another up to about 1000 miles.
In the US, this might be ok. Let’s say I am a public cloud provider and I have a data center in Orlando, FL and a data center in Nashville, TN. A major hurricane is headed towards Orlando and I am worried that my power grid and backup power facilities might be at risk. I address this concern with my customers and agree that the best course of action is to migrate my entire Orlando workload (VMs, data, etc.) to another cloud pod in my Nashville data center. Assuming my network connections are big and fast, this is possible and I avoid a potential disaster that could impact all of my customers running on that Orlando pod.
Keep in mind that the same scenario could be done without any downtime at all to the application and the customers may not even notice. This happens on a local scale every day within a public cloud provider’s space. VMs are migrated from one host to another within a cluster and within the same data center all the time without any of the customers noticing a glitch.
Now take that scenario to Europe. I’m a provider who has data centers in the UK, Germany, and France. If I start moving VMs around to my various data centers, I’m now crossing country boundaries. Most state run organizations are going to take issue with that and they are going to want guarantees that their data and systems won’t ever cross their borders.
This is where geolocation comes into the mix. If there was a way to identify the location of a host within a cloud infrastructure, then I could write policies around that to ensure my VMs can only move to locations I approve. I could also report on the location of all my VMs at any given time. This could be extremely helpful for compliance and auditing purposes.
Ideal Scenario
Let’s take everything above into account and see how this could play out in the future in collaboration with my current security measures already in place.
Thanks to some technology to be released in the future, I am able to set policies for my hosts running my cloud infrastructure. I can model known good configurations for my BIOS and perform BIOS integrity checks. I can set up sequence checks to ensure all of my boot processes are expected and launch in the proper order each time the host boots. If that checks out, I can allow my hypervisor to launch and then validate that boot process to ensure everything is as expected without any unknown variables. Once that completes, I can attest to the trust of that host and allow VMs to launch.
I can then group all hosts running these security measures into trusted resource pools. I can ensure that a VM can’t be migrated to a host unless that host has been validated and trust status is reported as good. This could even be across data centers so that entire cloud deployments can have validated clusters of hosts.
Further, thanks again to some future technology, my hosts have GPS enabled location identifiers tied directly to the BIOS or processors. I can pull control points for location directly from the hosts and then set policies based on those control points. If I don’t want my systems or data to ever leave the borders of my country, that is now possible.
On top of all this, I can produce compliance reports showing that every VM in my entire cloud environment is running on a trusted host with a known good configuration and also report on VM location at any given time.
Add all of this to the traditional security measures that have been migrated over to the cloud and you really start to get a picture of what end-to-end cloud security can look like.
Stay Tuned, It’s Coming
Everything that is mentioned above is on it’s way. In fact, the project I’m currently working on at EMC is proving that the scenario outlined above is going to be possible in the very near future. I am currently working with Intel and RSA to develop some joint solutions detailing how it can be done and I’m planning to be at Intel’s Developer Forum (IDF) in September to present some demos. You may even get some previews at VMworld in August. This is exciting stuff and will ultimately provide some real value to organizations and governments who want to adopt greater cloud strategies while at the same time providing guarantees that those environments are at least as secure as their traditional infrastructures.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
