While mobile and smartphone security is the hot topic of the moment among virtualisation security gurus, plenty of other virtualisation security topics demand IT's attention right now. At the recent RSA Security Conference in San Francisco, the interest in virtualisation security ran high - with good reason. Different IT departments are at different points on their virtualisation journeys and some are still thinking about security in the old physical world terms, analysts say.
"There's still a lot of questions about how to approach security on virtualised servers," says Phil Hochmuth, program manager for security products at IDC.
By 2012 half of all the workloads run in corporate data centres will run on virtualised platforms - whether virtual servers or cloud platforms. By 2015, 40 percent of the security software that controls inside corporate data centres will be fully virtualised, according to a report by Gartner from November 2010.
Basic security tools such as intrusion protection don't work well with virtual machines (VM) because they're harder to define by geography, IP or MAC address. It's hard for external software to see or filter communications between VMs on a single physical server, notes Neil MacDonald, vice-president 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 virtualisation security questions to consider when making plans for your environment:
1. Is a slow server a safe server?
Just as with physical servers, adding security software adds to the workload, eats resources and lowers performance. Virtualised 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 as 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?
Virtualising 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 organisations 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 centre, 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 neighbours 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 neighbours 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 Virtualisation Software group.
When apps run on VMs 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 Wi-Fi connection to an unsecured laptop.
VMs should be able to enforce the same level of security policy on one another and on public or private clouds. It should apply 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 scrutinising 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 recognise and respond to VMs or hypervisors, Chen says.
Malware can not only spread to VMs 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 virtualisation software has torn them down to let them share quarters, data or workloads, Hochmuth adds.
NIST's View of the Basics
Just like physical servers, virtual servers have to be patched, configured and maintained according to organisational 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 virtualisation security issued yesterday by the US National Institute of Standards and Technology (NIST).
A summary of its guidelines:
1. Secure the hypervisor just as you would an operating system: it functions like an OS and is 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 ensure the guidelines are being followed.
3. Extend patch and vulnerability management processes to cover VMs as well as physical machines.