VMware vSphere Security Guidance, just the Beginning

On the most recent Virtualization Security Podcast, the panel was joined by VMware’s Charu Chaubal to discuss the latest draft of the VMware vSphere hardening guide. Of note during the conversation was the new layout and scope of the guide which is now split into the following sections:

• Virtual Machine Hardening
• ESX/ESXi Hardening
• Service Console Hardening
• Virtual Center Hardening

Near the end of the podcast we discussed whether or not the scope of a single virtualization host was too limiting and should not the scope be the cluster of virtualization hosts? In essence, there is hardly ever just one host but generally multiples to enable full redundancy. The guide does not cover this case, but the core, critical components of the vSphere product.
The focus of your security policy and procedures needs to be on the cluster and environment as the whole. The guidance is just one component of this expanded focus.
Other guidance with the scope of the cluster may be forthcoming from VMware and others, but for now the best resources are the guidance from VMware and the book VMware vSphere(TM) and Virtual Infrastructure Security: Securing the Virtual Environment and if you are using the Cisco Nexus 1000v, the guidance from Cisco. Everyone seems to be working on some form of Guidance for vSphere including CISecurity, DISA (who are waiting on VMware to finish), Catbird, etc.
One question not asked during the podcast was:

How different is ESX v4 from ESX v3 with respect to hardening guidance?

The answer is that they are not all that different. There are new technologies of course, such as Fault Tolerance and the Virtual Distributed Switch. In addition, the service console is a newer version of RHEL, which requires slightly different hardening. There are also changes to include all the new APIs, which impact VM hardening and network layout more than anything else.
Early on in the podcast, we discussed the possibility of VM Escapes and if there was any we could do to alleviate those, a compensating control. One suggestion made by another panelist was to not install VMware Tools as the paravirtualized are under constant attack. The response from VMware is to just keep up-to-date with Security Alerts and to continue to use VMware Tools and the paravirtualized drivers.
The most important aspect of the guidance is to properly segment all virtualization management networks behind a firewall. Event to the extent of securing this network from standard production networks by use of that firewall. The other major take away, is that this guidance is just the beginning, you need a well formulated security policy that uses this guidance in conjunction with compliance requirements. This is just one building block to the entire virtualization security stack as outlined in the updated End-to-End Virtualization Security Whitepaper.