Defense in Depth: Encryption within the Virtual Environment

The 5/31 Virtualization Security Podcast we spoke to High Cloud Security about encryption as a defense in depth, and where to place encryption within the virtual environment. This lead to an intriguing discussion about what is actually missing from current virtual environments when it comes to encryption. We can encrypt within each VM and we can encrypt within the networking fabric, as well as within the drives themselves, but currently that leaves several vulnerabilities and unencrypted locations that can be used as attack points. While we concentrated on vSphere, what we are discussing applies equally to all hypervisors.
As we can see from the following diagram, High Cloud Security solves the encryption problem by placing agents within the VMs and providing an encrypting data store for data at rest encryption. The keys for both are managed by the High Cloud key management solution where you, as the data owner, own the keys.

The key here is that it is important that the data owner own’s the keys, and this is part of the High Cloud Solution. You can use your own CA as necessary. But there are still weaknesses.

• Encryption at the Storage Layer (encrypting switch fabric, self-encrypting harddrives, or encrypting storage appliances) with Encryption at Rest is crucial, but once the data is read out of the storage layer it is usually unencrypted and therefore available to anyone above the storage stack.
• Encryption “In-Guest” is also am important tool, but the encryption keys need to live in the VM and if they are in the VM, they can be read from the VMs memory by a virtualization administrator (or a really good electronic copy) and used to decrypt the virtual disk.

These two methods also have the weakness that anyone in the guest can still read the data. A solution to that is to place encryption at another layer, within the application.

• Encryption in the Application has the same weakness as Encryption “In Guest” but with one benefit, if the VM is compromised, there is a chance that the data may not be compromised (unless the compromise gains administrative access).

So what is the best solution?

• Encryption in the Hypervisor? This is a good approach as the encryption can happen below the VM but above the virtualization administrator so that data is encrypted all the way across the switch fabric to the storage device. HyperV-3 may provide this capability, but it depends at which layer the encyrption takes place. They are talking about using BitLocker which may be too low-level to prevent the virtualization administrator from seeing the data.
• Encrypted Memory? This is another approach which would allow ‘in guest’ and ‘in application’ encryption to be safer within the virtual environment, as anytime memory is dumped, the memory would be encrypted and during runtime only a single page of memory is unencrypted. This also implies keys should most likely span multiple pages.
• Encrypted CPUS? This is one other approach, but the instructions and memory being written to the CPUs may need to be unencrypted and encrypted at the hardware layer.

Either way you try to solve this problem there are shortcomings, yet, we all can agree encryption of data at rest is crucial, but where we encrypt that data will depend on risk analysis of the data. Personally, I like to encrypt as high up the stack as possible, where do you like to put your encryption?