As of this writing just a few of the regulatory compliance groups are working to encompass Virtualization. However, they are not close to anything publishable yet. What does this mean for companies that must enforce regulatory compliance? What does this mean to an auditor? The big question many are asking, is if the Compliance documents to which they must adhere do not mention virtualization, are they compliant when they virtualize? Currently whether you get down checked or not during an audit depends entirely on the auditor’s interpretation of the current non-specific guidelines. In most case its negative as there is no guidance from the compliance groups with regards to virtualization. There are also virtualization security products out there that try to enforce and report upon current compliance guides with respect to virtualization.
One such product is Catbird vCompliance, and it does a great job with the major assumption that virtualization does not matter so much as following the compliance guidelines as if the virtual machine was a physical machine. This is definitely one approach. Yet could still run afoul the auditor that interprets the guidelines differently.
Currently PCI and FDIC compliance groups are working to solve the question of Virtualization, defining it, as well as applying some guidelines to acceptable use of virtualization. However, I have not heard of any other compliance group working towards this.
However, what do the Compliance groups need to address?
- They need to define Virtualization and its impact within the realm of the specific Regulation
- They need to produce some guidance to auditors who can better audit virtualized hosts who must be compliant
Sounds simple enough, but it is not really all that simple.Some issues are:
There exist several different hypervisors (ESX, Hyper-V, Xen, KVM, VMware Server, Virtual Server, etc.), some with more capability than others, Compliance guiadance should be universal across all hypervisors, perhaps with some very specific exceptions documented. Yet, we are mixing in our hypervisor list two types of hypervisors, Type 1 (bare metal ala ESX, Hyper-V, Xen) and Type 2 (VMware Server, Virtual Server). Should these be treated differently? Perhaps, Type 2 hypervisors depend on the security and hence the compliance of the underlying host operating system, while Type 1 hypervisors do not, they depend just on the hypervisor itself.
There also exists, in general, super-administrators, those who are virtualization administrators, who can literally see anything they want within the virtualization host, including network traffic, virtual machine memory contents, virtual machine disk file contents, and storage traffic. Given this level of access, how do we address the concern about compensating controls to reduce the capability of the super-administrator from ever being able to see compliant data to which they have no right to see, yet still can as a matter of doing their jobs.
Compliance groups must also consider how the data is backed up and how it gets to its final storage device. In the past, only the necessary data was required to be backed up for disaster recovery methods, yet with virtualization it is possible to backup a single file (virtual machine disk) that encapsulates the compliant data, not many files. With this convenience, there is yet a new device involved in the backup, a backup proxy that can connect to the same storage as the compliant VMs. The Administrator of the backup proxy can then see the raw disk data if they so desired. What compensating controls and guidance will be given for this possible access to data. Other tools backup directly from the virtualization host and not the storage device using encryption methods to transfer the data to a backup server where it can sit either in a raw format, or encrypted format. Once more we now have compliant data on a backup server where it could possibly be seen by an Administrator. Yet, I would assume the use of a backup server is well understood by the compliance groups, a backup proxy on the other hand is something specific to virtualization at this time.
With virtualization, you also have compliant virtual machines that could be constantly in motion, moving from host to host, datastore to datastore, network to network, and virtual switch to virtual switch. Is it possible that once the motion occurs, you are no longer compliant? This will largely depend on how the definitions of virtualization used by the compliance groups. There also needs to be a method to enforce where a VM can live within the virtual host, which networks, virtual switches, etc.
What happens if the scale of virtualization (lets say 40000 VMs on 512 blades) is such that new methods to apply compliance need to be used, such as using tools like VMsafe or the Xen Introspection API? These tools work by allowing each VM its own firewall, is this enough to allow compliance if the rules are set appropriately? Will there be guidance on how to set such rules? Or will the guidance not include this, which could increase the cost of being compliant as perhaps more hardware and software would be necessary?
The last issue I see is how can you be compliant within the Cloud. Cloud are agile, moving data around between different locations that could be in different geo-political borders. Is there a way to protect the company requiring such agility let at the same time requiring that regulatory compliance be followed.
As you can see, there are some very complex problems to solve when dealing with virtualization and the agility of the cloud. How compliance groups will address these is still to be seen.
Yet, several companies has already started to address compliance within the virtualization space:
HyTrust with its tagging mechanism that matches tags between compliant VMs and networks, virtual switches, hosts, and other components of the virtualization host. However HyTrust does this by acting as an access control between the management tools and the hosts. It does not enforce these changes if this layer of access control is bypassed, which can still happen.
Catbird with its vCompliance product demonstrated at VMworld. vCompliance tracks virtual machines against current compliance guidance. It can also enforce compliance by quarantining VMs that appear on the wrong virtualization host or network, there by enforcing compliance. vCompliance also offers a very nice view of where you are compliant, where you are not, and therefore what still needs to be done. Such a gap analysis tied to enforcement of compliance guidance and policy sets, this tool apart from HyTrust.
These are a start, and as soon as Compliance groups catch up with Virtualization I see these tools becoming even more beneficial. Perhaps both are needed within your environment. One to control placement, one to enforce.
But even with these tools, until the Compliance groups catch up with Virtualization, auditors may still down check based on their interpretation of the current non-virtualized guidance available. Once the compliance guidelines are updated, hopefully this will no longer be the case. Hopefully such guidance will come out shortly, but I would not hold my breath!