Virtualisation offers a lot of advantages but security must already be built in

• Article 25 of 33
• SC Magazine, February 2011
• View the original article online

Page 1 | Page 2 | Page 3 | Page 4 | Page 5 | All 5 Pages

However, Simmonds cautions against too much simplicity in architecting virtual environments. Although the temptation is to virtualise security, such as firewalls, the possibility of misconfiguration, of overlooking virtualised appliances in updates, harder management and bugs all mean that physical appliances should be used where possible. "It is basic security 101. For each component in security controls, there should be a very simple test to prove if something works or not."

Network traffic should also be inspected, just as it would be in a normal environment. The risk with virtualised systems is that a malware infection in one virtual machine can spread more easily to a virtual machine on the same system. Data should also be encrypted between virtual machines - as should the virtual machines in transit between servers, to prevent 'sniffing' of data.

Configuration needs to be correct at the outset. "The number one thing when deploying any kind of technology is to get qualified people to set it up," says Doug Philips, senior product marketing manager at VMware. "Before delving into anything more complex, set it up correctly, rather than just deploying the out-of-the-box configuration."

As well as the initial architecture, maintenance is something to consider. With server and desktop virtualisation, the hypervisor that runs all the virtual machines as well as the operating system - if there is one - on which it runs will need to be patched when updates are available. Although security flaws in hypervisors have been infrequent, the potential for such flaws to be exploited - aka 'hyperjacking' - is there, giving access to all the virtual machines on a server. "It's game over if they control the host OS or hypervisor," says Wood. "One team needs to be looking after the hypervisor, irrespective of virtual machines." In particular, he advises against allowing remote admin of the hypervisor, or at the very least using multi-factor authentication.

"It is a growing concern," says Tim Mather, senior adviser for KPMG's I-4 team. "You need to open up the hypervisor for introspection to see if it has been compromised, but if you do, are you opening it up for attack? Even if you boot from a trusted source, that is great at start-up, but how do you monitor the hypervisor to continue to ensure that it is secure? There is quite a debate in the virtualisation community."

Even if not fully compromised, the possibility also exists for flaws in the hypervisor to allow 'jumping' between VMs: a malware attack on one machine, typically less secure, allows for attacks on others - and potentially the hypervisor itself. Some attacks have used two or more VMs to attack more secure ones. There are products available to stop this kind of jumping, however, such as Check Point's Security Gateway VE, which sits as a gateway layer between VMs, at the hypervisor layer or on the LAN, safeguarding VMs. "It can protect the virtual world from anything you can protect in the real world," says Caroline Ikomi, technical director at Check Point.

Patching should be the same as with any physical production server; however, many organisations focus on the VMs, but not the hypervisors and OS beneath. Nevertheless, hardening of both the hypervisor and the VMs it supports needs to be managed and there are systems such as Dell's Kbox virtual appliance that can help. Although virtualisation enables many VMs to be patched simultaneously, simply through patching the image from which they come, not all VMs may be active at time of patching. Some systems allow for dormant virtual machines to be patched, but others will need them to be activated before they can be patched.

If patching goes awry, backups will become even more important, since so many VMs will depend on the same image. "There needs to be much more upfront planning," says Ting. "You really need to think through how you will restore systems."

Most security tools can continue to do the same jobs as before. However, as Mather points out, others will need to be able to look not just at the server and its activity but inside the VMs to monitor behaviours. Equally, performance can be affected by security tools that work with virtual machines but haven't been configured to work with virtual environments: an anti-malware program updating its definitions on a single virtual desktop is not a problem; 1,000 virtual desktops all getting their updates at once will be.

As a result, some virtual vendors have developed APIs that allow security software on the physical server to access VMs - VMware, for example, has APIs called VMsafe and EPSEC (endpoint security), which it and companies such as McAfee, Sophos and Trend Micro use.

Page 1 | Page 2 | Page 3 | Page 4 | Page 5 | All 5 Pages