Securing Virtual Environments
March 2011 E-newsletter
Securing Virtual Environments
A virtualized environment offers increased security and reliability for data centers. For one thing, isolating each application in its own virtual machine (VM) helps prevent application crashes or malicious code from bringing down the entire system.
However, that doesn't mean virtualized environments are completely free of security vulnerabilities. There are several items IT professionals need to watch out for in the virtualized data center to maintain security and stability.
Tip 1: Keep everything patched and current.
Patching your systems and supplying them with the latest updates is fundamental to any kind of computer security.
But don't just patch your applications and their guest VMs. Make sure that the hypervisor and any host instances of the operating system are patched and current as well. Any instance of an operating system or application in your virtual environment represents a potential security threat.
One aspect of virtualization that is a major source of potential problems is the multiplicity of VM images, both active and inactive, that a virtualized data center is likely to have. Most organizations start out with a few highly standardized "golden" images that can be quickly loaded to a server and launched.
However, there are often several versions of each image, all customized for specific purposes. Some of these are actively deployed, while others are likely to sit on CDs waiting for the next time they are needed. Regardless of their status, all of the virtual images must be properly patched and managed. Because it's not uncommon to end up with a hundred or more variations of the golden images, this can be a serious problem.
Consider investing in a patch management system that will let you simultaneously update all instances of the operating system, and preferably your applications as well. A product such as VMware's vCenter Update Manager will cut the workload and help prevent misconfigured patches.
Tip 2: Limit users' ability to create virtual machines.
The ability to set up VMs and virtual servers should be strictly limited to those who absolutely need to do it. Failure to restrict this can open all sorts of security holes and aggravate virtual server sprawl.
Typically, only people with administrative privileges should be allowed to create VMs. Furthermore, there should be an approval and tracking process for all VM creation.
Tip 3: Eliminate all unneeded virtual machines.
Even when they're not running, VMs represent a security vulnerability. Eliminate unneeded VMs as soon as possible.
It's also important to develop a tracking and inventory process for your virtual machines. This should include enough information on each instance to let administrators quickly determine when the VM was created, who uses it and what it is used for, as well as a specific date when the machine will be no longer be needed. Setting a date is particularly important for development machines that aren't running standard production applications.
It's also important to minimize the attack surface on your VMs. That means removing or blocking access to any software or services not needed for the specific application you are running on that particular VM.
Tip 4: Lock down your communications.
Like any other networked system, virtual machines are subject to having communications with their desktops, notebooks and other network components intercepted. This can allow hackers to do anything from simply reading messages to extract information such as passwords and Social Security numbers to subverting the system with a man-in-the-middle attack.
60%
The percentage of virtualized servers installed through 2012 that will be less secure than the physical servers they replaced
Source: Gartner
Secure communications between virtual hosts, desktops or management infrastructure by using tools such as Secure Sockets Layer or IPSec.
Tip 5: Use data link controls to create mirror ports on the virtual switch.
One of the weaknesses of virtualization security is the lack of visibility into inter-VM traffic. VMs on the same virtual server can communicate without the data being exposed to anybody, including the network manager. This is a security problem because it prevents administrators from knowing what their VMs are saying to each other.
That's not to say that virtualized environments are totally exposed. For example, inter-VM communication and other activity within the virtual server can be seen using data link (Layer 2) controls. However, these have to be explicitly set up for this purpose.
Because effective monitoring and logging are important parts of effective security, you need to monitor activity between VMs. Mirror ports, which copy packets from one port to a network monitoring connection on another port, let you monitor communications between virtual machines.