Ensuring virtual machine security

When preparing a server for production, you usually run the server through a series of processes and procedures that are designed to keep it secure. So how should you proceed when it’s time to secure virtual machines (VMs) as opposed to physical servers? This tip covers a few caveats for virtual machine security. The first set of caveats applies to the host server environment, and the second applies to the VMs themselves.

Protecting host servers
A virtual machine environment always consists of at least two environments: the host server environment, often referred to as the resource pool, and a production environment, which is maintained by VMs. There may be other environments—training, development, testing and more—but the first two are the most common. As a rule, you should always segregate the host environment from any VM environment (see Figure 1). This provides an initial layer of protection for all VMs.

Figure 1. Segregating the resource pool from VM environments

• The resource pool should be linked to a resource directory service—one that is apart from the production directory service. This resource directory service should not include any user accounts, only administrative and technical accounts and nothing else.
• All access in the resource directory service should be audited. This ensures that you know who has access and who wants access to the files that make up your VMs.

• Keep the number of resource pool administrators to a minimum while still being able to maintain and operate the environment properly. Resource pool administrators are highly trusted individuals. Screen these individuals thoroughly before giving them this level of authority in your network. If more administrators are required, then use strict delegation practices to assign appropriate rights.

Tips for virtual machine security
One important task to consider when securing VMs is how you will structure VM storage. For example, hypervisors such as Hyper-V will scatter the files that make up a VM, storing the configuration files in one place and the virtual hard drives in another. Consider changing this and keeping all of the VM’s files in a single folder. Although this makes it easier to steal a VM—just grab the folder itself—it also makes it easier to protect it. Set very tight access controls on VM folders, and make sure you audit all access to these folders.
Another important consideration is to protect parked VMs. As resource pool administrators—administrators that manage host servers and VMs—you sometimes create machines that will not be used except as parked or machines that are at rest. Seed machines—machines you use to generate others—are a good example of parked VMs, which are sometimes in a saved state. This generates a file with the memory contents of the VM.
This file can be a risk because it can contain in-memory passwords. Malicious users who gain access to this file could use it to discover these passwords and obtain information they should not have. Parked VMs should always be protected. Even better, if the VM is a seed VM, you should have a temporary password—one that is not a production password—assigned to the parked VM.
Here are more useful tips :

• Make sure that all VMs that are deployed into production are completely up to date before you deploy them. This means applying all patches and service packs before they leave the nest.
• Once in production, make sure you regularly update all VMs, parked or running. It is easy to forget to update VMs that have been parked for long periods of time. Then, when the VM is finally restarted, it is at risk and could cause a serious security breach in your network.
• Try running the latest operating systems on your production VMs. For example, if you are relying on Windows Server, then try running Windows Server 2008 R2 so that you have the most secure version of the OS on your VMs. Running outdated operating systems is asking for trouble because many of them no longer have updates or security patches.

Virtual service offerings (VSOs) or VMs that offer services to end users require more in terms of security settings because they are designed to interact with end users and, therefore, have more services built into the infrastructure. The scope of protection for VSOs will depend on the size of your organization.
Certain security technologies are reserved for resource pools, as some are reserved for VSOs. For example, you will want to run a tight operating system on host servers, minimizing the attack platform, but it might be difficult to do the same with your VMs.
VMs are designed to offer services to end users and, as such, often require that more services be turned on than a host server ever will. For example, if you are relying on Hyper-V, you will want to run Server Core on your host servers, but you might run the full installation on your VMs.
It is more important to make sure that you apply the appropriate level of security on a full installation of Windows Server than to deploy Server Core on VMs. In the long run, you’ll appreciate the access to the graphical interface when it comes to long-term management practices of your VMs.
As you can see, securing VMs is much like securing any other server environment. The practices you use are slightly different from traditional physical environment practices, but the aim and the intent are the same: protect your crown jewels at all times. You can’t go wrong with this philosophy when it comes to virtual machine security.

Implementing virtual machine security

Rely on the following table to make sure your virtual machines are as tightly controlled as possible:

About the experts: Danielle Ruest and Nelson Ruest are IT experts focused on virtualization, continuous service availability and infrastructure optimization. They are authors of multiple books, including Virtualization: A Beginner’s Guide for McGraw-Hill Osborne, as well as the MCTS Self-Paced Training Kit (Exam 70-652): Configuring Windows Server Virtualization with Hyper-V for Microsoft Press. Download a free copy of Chapter 8: Securing Hosts and Virtual Machines for more information on Hyper-V security.

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.