Secure Multi-Tenant Virtualization – How to get there?

Due to what I stated during GestaltIT’s TechFieldDay, I was invited with Bas Raayman and others to discuss Secure Multi-Tenancy (SMT) in more detail with Chuck Hollis at EMC World. In addition, during one of the Keynotes SMT was renamed from Secure Multi-Tenancy to Simple Multi-Tenancy.  The current Cisco VMware Netapp solution is plainly not secure. During the TechFieldDay at Cisco, Cisco even claimed “we did not think about security” when designing the initial solution. Cisco is worried about Quality of Service, I.E. Bandwidth through out the system to the disk. Furthermore, their definition of ‘Tenant’ was quite a bit different than my own. So we should first start off by defining Tenant.
The Tenant is the Legal Owner of the data that resides within the system.

The term legal has to come into play as in the EU for example, one LARGE company can have different businesses and those businesses are the legal owners of the data not the LARGE company.

We need to further define system as well.
System is the X amount of resources reserved by the Tenant for their use.

Now I purposely wrote reserved. Reserved could mean rented, purchased, but generally there is some form of agreement in place that defines these limits. Limits are very important to SMT, and knowing the upper and lower bounds of those limits will be part of any service level agreement.

The current SMT design from Cisco-VMware-NetApp (CVN) looks to be all about availability of storage IO and ignores Data Integrity and Confidentiality. However, even so, it does not cover the availability of all resources in great depth, pretty much depending on proper HA, DRS, and other Business Continuity functionality.  CVN only looks at storage availability through out the system with their definition of Tenant being those who require different storage QoS.
I see several issues with CVN’s SMT, specifically in the areas of:

• Authorization and Authentication for the Tenant Administrators
• Access restrictions for Tenant Controlled and Tenant Assisted administration models
• Control of what the Cloud Administrators can actually see
• Protection of data in motion from view by other tenants and cloud administrators
• Audit controls and requirements
• Forensics with respect to current acquisition models.

In essence, how can I protect my data from those who are not allowed access to the data. In other words: a trust no one model specifically the cloud administrator(s).
Current state of the art implies a level of auditing and monitoring of  administrator actions, to see if they have touched the data. This is still required going forward, but we need a preventative measure that makes it impossible for the administrator to actually see or ‘change’ the data. Auditing is after the fact, we need prevention as well. Once an administrator can access the virtual environment currently all bets are off and this means the administrators and their accounts make for juicy targets by social engineers and attackers.
The reason for all this, is that as we know from a discussion on the Virtualization Security Podcast on Forensics, that encryption within the VM is suspect, therefore encryption needs to happen outside the VM somewhere in hardware where an attacker or administrator cannot see or tamper with the results.
With SMT and the cloud, security is all about the data.  The data needs to be tamper resistant as a minimal level of functionality through the use of hardware based digital signatures. At a higher level, the data needs to be fully encrypted through the use of some hardware means.
The big issues with this approach is identity and key management. There has always been an issue with key management that has to be solved. But let’s look at identity, is the identity the datum, the user of the data, the container of the data, or a collection of containers of the data? This is the question to be solved by the possible solutions once the hardware and hypervisor can provide integrity and confidentiality from without the VM in a manner not discernible by the administrator.
IN essence, the data from a virtual machine needs to be encrypted/signed in a manner not discernible by the cloud administrator(s) with the keys controlled by the tenant which means that this would be through the hypervisor directly tied to some encryption engine with an out of band mechanism for tenants to provide certificates or keys.
Can this be solved? Yes but it may be a while before everything is ready. The Trusted Platform Module (TPM) and Tusted Execution Technology (TXT) demos at RSA Conference and EMC World present very promising technology, but how TXT will work within the virtual environment is still somewhat nebulous.

TPM integration allows me to ensure that the boot volume of a virtualizaiton host has not changed. With the advent of 3rd party drivers within the virtualization host, this is a step in the proper direction. Out of the conversation at EMC World I have developed a wish list for the future of TPM integration within the virtual environment. Specifically on how Trusted Execution Technology (TXT) can work within the virtual environment.
Enhancements to TPM/TXT I would like to see:

• Cluster wide TPM/TXT – This will enable the the TXT state of a VM to move around the virtual environment with ease. VPLEX should also be considered for stretch clusters.
• Use of TXT to verify the boot volume and configuration file of a VM – This will enable some level of assurance that the boot volume and configuration of the VM has not been modified.
• Use of TPM/TXT to maintain key material for a hardware encryption module – Hardware based encryption will become a must moving forward to ensure integrity and confidentiality all other encryption mechanisms are suspect.
• Some out of band mechanism to load certificates into the TPM/TXT module for use for with encryption. – Security credentials cannot be controlled by the cloud administrators, they must be controlled by the tenants themselves. Some safe mechanism to put tenant certificates and keys for use by the hardware encryption mechanisms must be provided, preferably out of band but not discernible by the cloud administrators.

If the data within the virtual environment hosted within a private or public cloud can be properly encrypted or signed with the maintenance of such encryption or signing mechanisms performed by the tenant, we will have a much more secure cloud and therefore Secure Multi-Tenancy. SMT is all about the data. The cloud administrators should not be able to see or tamper with this data in any way shape or form. If the cloud administrators cannot tamper or see the data then neither can other tenants as its all about privilege levels. If however, you want the cloud provider to assist you in securing this data, that is a tenant choice, but any SMT reference architecture needs to consider fully secured tenancy!
In the cloud, it is all about the Data. Secure the data.