Security concerns cloud virtualisation deployments

Server virtualisation makes it possible to run multiple applications and operating systems on fewer hardware resources, and it lets customers quickly provision new resources based on demand. But the features that enable such flexible computing cause network and security managers to wonder whether a security threat in a virtualised environment could spread to the entire network.

"I am holding off on server virtualisation because I have already been hearing about security issues with the hypervisor," says Craig Bush, network administrator at Exactech in Florida. "One server being breached doesn't take down our entire network, but if it is possible for a hypervisor to do that, I'll just wait until the security angle is more played out before I jump into virtualisation."

Here we address four of the top concerns about securing virtual environments and attempt to discern the hype from reality.

1. Virtual-machine escapes could propagate security problems

IT managers worry that security attacks designed to exploit a hypervisor could infect virtual machines that reside on the same physical host, in what is known as a "virtual-machine escape".

If a virtual machine is able to "escape" the isolated environment in which it resides and interact with the parent hypervisor, industry experts say it's possible an attacker could gain access to the hypervisor, which controls other virtual machines, and avoid security controls designed to protect the virtual machine.

"The Holy Grail of security in the virtual world is to bounce out of the [virtual machine] and take control," says Pete Lindstrom, a senior analyst at Burton Group, in a recent webcast on virtualisation security.

But while there are documented attempts to execute a virtual-machine escape, some point out that a security disaster related to such an event has yet to be proved.

"To my knowledge, there has never been a hack that has allowed a security problem to propagate from one virtual host to another by way of the hypervisor technology," says Steve Ross, a consultant with Catapult Systems, which is helping logistics provider Transplace, based in Texas, deploy and maintain its VMware virtual environments.

"It could happen, and the attacker or breach could hop from [virtual machine] to [virtual machine], but I have yet to see it as a functional exploit out there today," adds Tim Antonowicz, systems engineer at Bowdoin College in Maine.

Antonowicz, who uses VMware ESX to virtualise servers, says he tries to thwart such problems by sequestering virtual machines in resource clusters, depending on the sensitivity level of the applications or data the virtual machine is housing. "You have to segregate machines in that manner to heighten security," he says.

Edward Christensen, director of technical operations at Cars.com in Chicago, is also taking steps to insulate his company's virtual environments.

"The old-school ways of securing an environment involve putting firewalls between the database and application layers, for instance, but when you have a virtualised environment, those lines get crossed," Christensen says. The online automotive company uses VMware to virtualise servers on HP boxes, and Christensen says being able to store virtual environments off the network helps ease security worries. "It's one of the nice things about virtual environments," he says.

2. Virtual machines multiply patching burdens

The threat of virtual-server sprawl — a scenario in which the ease of deploying virtual machines results in more instances than planned — makes staying on top of patches and updates for operating systems critical in a virtual environment.

"Patching becomes more challenging, because these [virtual machines] move around, and they multiply," Burton Group's Lindstrom says. "The ability to validate the patch status on individual machines becomes more important in the virtual world."

IT managers agree patching is critical in virtual environments, but the real difference between virtual- and physical-server patching isn't a security issue, it's about volume.

"We need to keep in mind that our servers that are virtualised require the same patch management and maintenance as physical servers," Catapult's Ross says. Transplace has three virtual environments — two inside the network and one in the DMZ — which include about 150 virtual machines. "The hypervisor adds another layer to focus on in patching, but patching itself is equally critical on physical and virtual machines," Ross says.

For Bowdoin's Antonowicz, staying in front of virtual-server sprawl is a priority now, because the time it takes to patch machines increases when servers multiply beyond his direct control. In the past he routinely patched 40 servers, but now he is responsible for securing more than 80. He hopes one day to find tools to better automate the process.

"Virtual environments can grow too fast without physical constraints," Antonowicz says. "Before we roll out more [virtual machines], I want to look into more automation around patching."

3. Running virtual machines in the DMZ

As a rule, many IT managers avoid putting virtual servers in the DMZ, and other IT managers won't run mission-critical applications on virtual machines in the DMZ or even on those machines protected by corporate firewalls.

According to Burton Group's Lindstrom, however, it can be done when using proper security measures. "You can run virtualisation inside the DMZ as long as the firewall or separating device is physical. And in most cases, as long as you are separating out resources, you are good to go," he says.

Bowdoin's Antonowicz says DMZ or not, he sets up his virtual environments with the mind-set that exploits exist, and he works to limit the access among clusters of virtual resources. "Each cluster has its own set of resources and accesses so you can't get from one to the other and there is no way to jump within each cluster," he explains.

Many IT managers work to segment their virtual servers and keep them within corporate firewalls, but some place virtual machines in the DMZ — but only with noncritical services running on them. According to Scott Engle, director of IT infrastructure at Transplace, everything of value is behind the firewall, and those applications running on virtual machines in the DMZ include such services as DNS.

"We run [virtual machines] in a trusted segment on a trusted host. In our DMZ, we will run physical boxes with a few VMware instances, but we do not bridge the gap between trusted and untrusted networks," Engle says.

4. The newness of hypervisor technology could be an invitation to hackers

Any new operating system is rife with flaws. So, does that mean hackers are champing at the bit to find virtual-operating-system vulnerabilities and launch security attacks?

Industry watchers advise security managers to remain a bit sceptical about virtual operating systems and their potential to introduce more holes and vulnerabilities than they can patch manually.

"Virtualisation is essentially a new operating system, which is something that hasn't been done for a long time, and it enables an intimate interaction between underlying hardware and the environment," says Rich Ptak, founder and principal analyst at Ptak, Noel and Associates. "The potential for messing things up is significant."

The virtual hypervisor may not represent as much of a security threat on its own as people might think, however. Having learned from Microsoft's well-publicised problems patching Windows, companies such as VMware may have worked to limit the potential for security holes in the hypervisor technology.

"VMware has done a good job compared to Microsoft, and the vendor seems to be ahead of that type of issue," says Peter Christy, principal at Internet Research Group. "But a hypervisor is a small piece of code that represents a small and limited surface area, which is easier to make more secure than 80 million lines of code."

Copyright 2019 IDG Communications. ABN 14 001 592 650. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of IDG Communications is prohibited.