While mobile and smartphone security is the hot topic of the moment among virtualization security gurus, plenty of other virtualization security topics demand IT's attention right now. At the recent RSA Security Conference in San Francisco, the interest in virtualization security ran high - with good reason. Different IT departments are at different points on their virtualization journeys, of course, and some are still thinking about security in the old physical world terms, analysts say.
"There's still a lot of question about how to approach security on virtualized servers," says Phil Hochmuth, program manager for security products at IDC.
By 2012 half of all the workloads run in corporate data centers will run on virtualized platforms -- whether virtual servers or cloud platforms; by 2015, 40 per cent of the security software that controls inside corporate data centers will be fully virtualized, according to a November, 2010 report from Gartner.
Basic security tools such as intrusion protection don't work well with virtual machines because they're harder to define by geography, IP or MAC address, and it's hard for external software to see or filter communications between VMs on a single physical server, notes Neil MacDonald, VP and Gartner Fellow, who co-wrote the report.
With most tools, it's hard for IT to even know how many of the VMs on a particular server even have all their patches up to date, Hochmuth says.
Here are some virtualization security questions to consider when making plans for your environment:
1. Is a slow server is safe server?
Just as in physical servers, adding security software adds to the workload, eats resources and lowers performance. Virtualized servers make more efficient use of their resources than physical servers, but that doesn't mean it's obvious where and how to apply security.
"It sounds pretty basic, but there is a lot of disagreement about whether it's better to have agents inside every virtual machine to secure them, or if that's too much of a drain on resources and that having something that can watch a group of VMs is better," Hochmuth says.
Run an agent on each of the 30 VMs in a quad-processing server and you get overhead equal to running 30 copies of the security software -- because that's what you're doing.
The other major alternative -- running one piece of software on the physical server that can observe all the VMs and their operating systems -- is more elegant in concept, but may not be as secure, or may not be all that efficient either.
Hochmuth recommends "a really pragmatic proof of concept" comparing the impact on performance of several vendors' products. Even if the test tells you nothing about how good the security is, "it will tell you which products bog down the particular workloads you're running more than you find acceptable," he says.
2. Should you even let the VMs talk to each other without encryption?
Virtualizing servers means more than just being able to cram several operating systems into one box; it means creating a network inside that box across which the VMs have to communicate with each other, applications running on other servers, and the Internet, according to Matt Sarrell, executive director of security test/analysis firm Sarrell Group.
Much of the drive toward encryption in virtual environments comes from organizations that need to be able to demonstrate a good chain of custody for data under HIPAA or other privacy regulations, according to Sarrell.
That same encryption can help lock the doors on malware that can infect a hypervisor or OS on which a VM runs in a data center, however, keeping the rest of the VMs safe even if one is compromised.
Encrypting data streaming to and from VMs running in either a public or private cloud can also reinforce the doors between your VMs and the neighbors' in public clouds, Hochmuth says.
"Shared-server public clouds are like living in an apartment building, so your security may depend on how safely your neighbors are acting," he says. "Encrypting your VMs and the data can make that situation a little more secure, but again, at a potential risk of a performance hit."
3. Do you know who or what is asking for data?
Security policies linked to MAC or IP addresses don't work well when the entities in question are virtual, according to Gary Chen, research manager for IDC's Enterprise Virtualization Software group.
When apps run on virtual machines the security has to take into account who wants access, what they want to access, when, where and from what device they want access, according to Gartner's MacDonald.
Only in that context can a security policy remain effective rather than firmly locking down a piece of sensitive data except if a new or untrained employee who has secure access at the office decides to download it across an unencrypted WiFi connection to an unsecured laptop.
Virtual machines should be able to enforce the same level of security policy on one another, and on public or private clouds, applying the company's security requirements according to the context in which data is being requested, not what MAC or IP address sent the request, Hochmuth says.
4. Are you scrutinizing the in-between spaces?
Running virtual servers means running an additional operating system -- VMware's vSphere, Citrix' Xenserver or Microsoft's Windows Server 2008 -- that can be attacked by hackers or malware designed to recognize and respond to VMs or hypervisors, Chen says.
Malware can not only spread to virtual machines through their connections to the Internet, it can spread among them once it's infected a VM inside the firewall, or inside a physical server -- especially if the VMs are set up for fail-over or disaster-recovery support that gives them special access to one another, Chen says. Encrypting data or identity-protecting it can rebuild walls between servers to keep data safe, even after virtualization software has torn them down to let them share quarters, data or workloads, Hochmuth says.
NIST's View of the Basics
Just like physical servers, virtual servers have to be patched, configured and maintained according to organizational rules that define levels of security so sloppiness or inconsistency doesn't open a hole that negates the whole effort, according to a guide to virtualization security issued yesterday by the U.S. National Institute of Standards and Technology (NIST).
A summary of its guidelines:
1. Secure the hypervisor just as you would an operating system; if functions like an OS and it's vulnerable like one. Holes in it make everything running on it vulnerable.
2. Establish consistent guidelines to configure security on virtual and physical machines, and a process to verify the guidelines are being followed.
3. Extend patch and vulnerability management processes to cover VMs as well as physical machines.
Follow everything from CIO.com on Twitter @CIOonline.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.