Measuring Hypervisor Footprints

There have been several interesting posts in the blogosphere about virtualization security and how to measure it. Specifically, the discussions are really about the size of the hypervisor footprint or about the size of patches. But hypervisor footprints from a security perspective are neither of these. The concern when dealing with hypervisor security is about Risk, not about the size of the hypervisor or the size of a patch it is purely about the Risks associated with the hypervisor in terms if confidentiality, availability, and integrity.  Vendors who claim that security is proportional to the size (in GBs) of the hypervisor footprint are spreading FUD.
So let us look at  hypervisors and ecosystems with the idea of the risks involved and how the security of  the virtual environment affects confidentiality, availability, and integrity. Does size impact these elements of security? Perhaps, in general there is the concept that more code implies the chance for more software security bugs, but when applied to patches, this really depends on what has changed within the code more than the size of the patch. I will explain how this impacts virtualization a little later in this post.
Availability
Availability is risk that your service will be interrupted either through  a security attack or other means. The risk is often mitigated by addressing availability issues. These mitigation steps could include applying security measures, clustering technologies, or in terms of virtualization whether your virtualization host has similar clustering technologies built into it or you rely upon clustering at the VM level. The  urrent virtualization technologies rely on clusters of virtualization hosts tied together through some form of remote storage (FC SAN, iSCSI, or NFS). These technologies are Dynamic Resource Scheduling, High Availability, and Fault Tolerance. Without these underlying technologies, availability issues must be resolved within the virtual machines. So when you look at availability within virtualization you need to look at what level availability lives.  All virtualization products have availability within the virtual machines but the other technologies require remote storage technologies (hardware cost), more features (licensing costs), or the latest versions of software (new code).
Confidentiality
Confidentiality is the risk that the data within your virtual environment will be made available to those who do not have rights to see or access the data. The common mitigation is to encrypt the data such that only those with the appropriate 2 factor authentication can view or access such data. When we discuss this in terms of virtualization we are looking at the security around authentication within all layers of the virtual environment. Since data can move from virtualization host to virtualization host fairly easily and regularly, is the the data at any time at rest? Are we not redefining the definitions for at rest verses in motion? Currently the virtual environment has access controls to the virtualization hosts management but leaves VM access controls to the virtual machine and networking involved. In addition, data in motion (live migration) may or may not be encrypted. If it is encrypted is uses SSL with all its weaknesses. Virtual environment management access controls are difficult to lock-down as there are quite a few ways to access the virtualization host (Through webpages, Management Servers, Direct access to the virtualization host, etc.) It is very possible that you will end up with split-brain authentication and authorization. This can be alleviated by using third party software (licensing costs).
Data in motion can be encrypted for Fibre Channel SAN using Brocades encryption fibre switch but there is not much for other storage protocols (hardware costs).
Confidentiality is generally where I would place the debate between the footprint of the hypervisors. Why? Because the management tools available to a hypervisor really dictate the attack footprint of the hypervisor and not the physical size of the hypervisor. ESXi vs ESX is always one large debate with VMware saying ESXi has a smaller footprint. The physical size is not as important as the network footprint the hypervisors have. The network footprint is dictated by all those varied ways to authenticate and authorize a user. From this perspective, the footprints are nearly if not exactly identical. The only major difference is that ESXi does not have SSH enabled by default and most people end up enabling it. Windows Server 2008 vs Windows Server Core 2008 has a similar issue, however Windows Server Core 2008 actually has a much smaller network footprint than Windows Server 2008, but if we just look at Virtualization Management the footprint is the same once more.
Lastly, Confidentiality encompasses virtual and physical firewall, VMsafe appliances, and other third party tools related to firewalls.
Integrity
Integrity of the virtual environment is tied in some ways to the software being run, and in others to the integrity of the data within the environment. How do you know something has not changed when it should not have changed? Integrity is the one aspect of virtualization security that is the hardest to determine as you need to increase auditing within the environment to know when every bit of data within the environment has changed. Some organizations are satisfied with tracking configuration changes. Others require more thorough change tracking.  There are many solutions for this for data within a VM, but there are few solutions that apply to the virtual environment itself and most come from third parties (licensing costs).
One of the most important aspects of Integrity is patching of systems. However, it is not the size of the patchfile that really matters here, but what actually changed within the patch file. Why not the size? Because each virtualization host is patched differently and you need to account for those differences in some manner. VMware ESX, Windows Server 2008 Server Core, and Citrix Xen Server are patched in the more traditional manner of the single package within the environment is changed. However, when VMware ESXi is patched the entire environment is rewritten, even if it is only a few bytes of code changed. Given this, it just does not make sense to compare the size of the patches as a means of comparing the integrity of the hypervisor and related management tools.
Conclusion
How do we correlate these issues between different hypevisors to measure their security? Its not by size, but by capability and secure functionality within the virtual environment. This is done today by using security assessment guidelines from the vendors, CISecurity, and DISA. As well as from the Common Criteria from the international community.
For each company using virtualization products it is about assessing the Risk to the environment. If you have the proper compensating controls then the risk will be mitigated. It is also about knowing what Risks exist within your environment. For that the guides previously listed and virtualization security books will assist you.