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:
|Table 1: Checklist for virtual machine security|
|Communications||Make sure all users, including administrators, understand their responsibilities in terms of virtual machine security practices.|
Pay special attention to the following:
|Anti-malware||Implement proper antivirus technologies.|
|General directory security||
Implement tight permissions management.
Implement special password policies that require highly complex passwords for administrators.
Tighten delegation-of-authority settings on your servers.
Secure the file system to protect VMs.
Implement access-based enumeration to further protect information.
Rely on digitally signed installation packages for all third-party or custom software product installations.
|Web services||Implement tight Web server security on all Web servers.|
|User identification||Rely on smart card or two-factor authentication for administrators in highly secure environments.|
|Security policies||Assign proper policies for the VM network.|
Tightly control all resource access.
Implement encryption for mobile users.
|Role-based access control||Implement in every application as much as possible.|
|Access auditing/monitoring||Turn on auditing to track all changes.|
|Perimeter networks||Configure the firewall settings to control access to all servers, especially those in the perimeter network.|
|Virtual private networks (VPNs)||Rely on VPN connections for all remote access.|
|Remote access||Implement a remote access authentication service for users working remotely.|
|Public key infrastructures (PKI)||Implement PKI in support of smart card deployment and software restrictions.|
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.
- The Second-Wind of Private Cloud –Focus Technology Solutions
- Private Cloud Migration Success Guide –TechTarget
- Focus: Private cloud –ComputerWeekly.com
- Why Physical Networks Don't Cut It for the Private Cloud –SearchSecurity.com