I recently spoke at the InfoSec World 2010 Summit on Virtualization and Cloud Security and also attended the main conference sitting in on many Virtualization discussions. Perhaps it was the crowd, which was roughly 30-40% auditors. Perhaps it was the timing as SourceBoston was also going on, as well as CloudExpo in NY. But I was surprised to find that people are still ‘just starting’ to think about Virtualization Security. Since I think about this subject nearly every day, this was disappointing to me at best. I found ideas around virtualization security ranging from:

Virtualization Security is not part of an architecture/design, what do I bolt on?

My Physical Security will work

Virtual Environments NEED More security than physical environments

There are no new threats, so why have something more

Security is a hindrance

You can have a secure environment that does not limit functionality and is not hindrances. Security as a hindrance is generally the view from Virtualization Administrators who have had wide open systems and now need to be secured due to the security team finally being involved, a break in, or the results of an audit (internal or external). With Virtualization things can happen without any checks and balances nor with the knowledge of who actually performed the actions. Security is trying to maintain some level of Compliance with a security policy and regulatory requirements. This generally includes auditing who did what, when, where, how, and why.

Auditing is a requirement and any Virtualization Administrator will realize that auditing will also greatly help with problem determination within simple and complex environments. As we move to more and more automation, auditing will become a major issue.

The two elements that will greatly assist in problem determination and security are the following:

Have a Remote Log Server for all your virtualization host log files separate from the log files for your VMs (or the same but with really good log analysis tools).

Segment your Virtualization Administrative Network from all other Administrative and production networks.

The first is required for most regulatory compliance, but will definitely aid in problem determination.

The second is the easiest solution to many of the known virtualization security attacks. These attacks target the wide open virtualization management network which will allow attackers to garner simple things such as virtual disks, passwords, and other accesses. The attacks are actually very well understood SSL and other MiTM attacks that can be used to in effect gain administrative access to virtualization hosts.

During one of the Summit presentations, Tim Pierson, performed a little ‘google hacking’ to find on the Internet over 200 VMware ESX and ESXi systems, within the US only, which have their service consoles directly assessable. This implies that anyone who wants could use the SchmooCon attack to grab disk images without anyone the wiser. This is a serious threat to the security of your Virtual Environment!

Virtualization Administrators should work with security and network teams to implement minimally the two elements mentioned, remote logging and separate management networks, in order to better secure their environments. These are the two biggest hurdles as they are perceived as changing the way administration is performed. There is barely any change, Virtualization Administrators may at most need to use some form of remote desktop protocol to access a system within the protected network in order to perform all your virtualizaiton administrative tasks. This should be the common access method anyways for most servers.

Segregating the Virtualization Management network will also have the added benefit of providing an ‘on-site’ target for VPN and other remote access technologies. Security can be beneficial. Implement the low hanging fruit: The security team will be happy, and you will gain some definite functionality for remote access and problem determination along the way.