Planning for Hyper-V Security

**Security Tip of the Month – September 2008
See other Security Tips of Month

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Once you have updated the Windows Server® 2008 operating system with the Hyper-V™ technology release bits and enabled the Hyper-V role, you are ready to run virtual machines (VMs) on your server, now called a virtualization server (also called a “host”).

How does this change your security? Not much. Hyper-V is designed to be fairly transparent. You secure your VMs the same way that you secure physical machines. For example, if you run antivirus software on the physical machine, run it on the VM (not the host). If you segment the physical server to a particular network, do the same to the VM.

Securing the virtualization server itself involves all the measures you take to safeguard any Windows Server 2008 server role, plus a few extra to help secure the VMs, configuration files, and data. For more information on helping to secure Windows Server 2008 workloads, see the “Windows Server 2008 Security Guide.”

Microsoft recommends the following best practices to improve the security of your Hyper-V virtualization servers. Many of these practices apply to your other virtualization servers as well. 

Use a Server Core installation for the parent partition. A Server Core installation of Windows Server 2008 presents the smallest attack surface and reduces the number of patches, updates, and restarts required for maintenance. For detailed information and guidance about how to install Server Core, see the “Hyper-V Planning and Deployment Guide,” which includes step-by-step instructions for enabling the Hyper- V role on both Server Core and full installations of Windows Server 2008. Note that there is no way to upgrade from a Server Core installation to a full installation of Windows Server 2008. If you need the Windows Server user interface or a server role that is not supported in a Server Core installation, you will need to install a full installation of Windows Server 2008.

You will manage Hyper-V on a Server Core installation remotely, using the Hyper-V management tools for Windows Server 2008 and Windows Vista® Service Pack 1 (SP1). For more information, see article 952627 and article 950050 in the Microsoft Knowledge Base. For more information about configuring tools for remote management of Hyper-V see the “Hyper-V Planning and Deployment Guide.”

It is a good idea to build a deployment image of Windows Server 2008 with Hyper-V role enabled to use as the base operating system (OS) for your VMs. Robert Larson wrote a great step-by-step article on how to use the Windows Automated Installation Kit (WAIK) for Windows Server 2008 to slipstream the Hyper-V release-to-manufacturing (RTM) update and the integration components into an image for easy deployment. Just add Server Core to his recipe, and you are good to go.

Do not run any applications in the parent partition. Run all applications on virtual machines, which use child partitions. For example, if antivirus is required, be sure to run it on the VMs rather than the parent partition. Keeping the parent partition free of applications and running on a Windows Server 2008 core installation means fewer host updates, since nothing needs software updates except the Windows Server 2008 core installation, the Hyper-V service components, and the small (~600KB) hypervisor.

You can use Microsoft® System Center Virtual Machine Manager to convert your server to a virtual machine and run it on the virtualization server in a VM. In Virtual Machine Manager, this process is called a physical-to-virtual (P2V) conversion. For more information on P2V, see “Converting Physical Computers to Virtual Machines.” If you don’t want to use the WAIK, you can use P2V on your Server Core installation to use as the base for all your VMs.

Use the security level of your VM to determine the security level of your host. You should deploy VMs onto your virtualization servers that have similar security requirements. For example, if you classify the risk and effort to secure your servers into three levels—secure, more secure, and most secure—you can put the highest degree of compliance effort and control procedures into the “most secure” servers, and lessen the amount of compliance and procedures with the servers that have a lower security classification. This would be true whether the server is physical or running on a virtual machine. If you deploy both “secure” and “most secure” VMs on a host, then you should secure the host as a “most secure” server. To make management easier, deploy VMs with similar security levels on a virtualization server and do not mix VMs with differing security requirements on the same host. This practice also allows you to move VMs among different hosts with the same level of security without worry or extra effort—using, for example, Virtual Machine Manager 2007 host groups.

Do not give virtual machine administrators permissions on the parent partition. According to the principle of least privilege, you should give administrators of a VM (sometimes called department administrators or delegated administrators) the minimum permissions required. Managing the required permissions on all the objects associated with a VM can be burdensome, and if mishandled can lead to potential security issues. Role-based access control (RBAC) allows you to specify access control in terms of the organizational structure of a company. RBAC does this by creating a new object called a role. You assign a user to a role to perform a job function. Hyper-V uses Authorization Manager (AzMan) policies to achieve RBAC.

Ensure that virtual machines are fully updated before they are turned on in a production environment. Because VMs are so much easier to move around and quicker to deploy than physical machines, there is a greater risk that a VM that is not fully updated or patched might be deployed. To manage this risk effectively, use the same methods and procedures to update VMs as you use to update physical servers. For example, if you allow the use of automatic updates using Windows® Update, Microsoft System Center Configuration Manager, or other software distribution method, ensure that VMs are updated and/or patched before they are deployed.

You can use maintenance hosts and quick migration in Hyper-V to accomplish this. A maintenance host is a host that you can dedicate for patching stored resources and for staging virtual machines before you move them into your production environment. For more information about maintenance hosts see “Planning for Hosts.” For information about using quick migration to move VMs to a maintenance host see “Hyper-V Step-by-Step Guide: Testing Hyper-V and Failover Clustering.”

To update the VMs before they are turned on, you can use the Offline Virtual Machine Servicing Tool. For more information on the Offline Virtual Machine Servicing Tool see “Offline Virtual Machine Servicing Tool Executive Overview.”

Use a dedicated Network Interface Card (NIC) for management of the virtualization server. By default, NIC0 is for the parent partition. Use this for management of the Hyper-V server and don’t expose it to untrusted network traffic. Don’t allow any VM to use this NIC. Use one or more different dedicated NICs for VM networking. This allows you to apply differing levels of networking security policy and configuration for your VMs. For example, you can configure networking so that the VMs on the host have different networking access than your host, including using virtual local area networks (VLANs), Internet Protocol Security (IPsec), Network Access Protection (NAP) and Microsoft Forefront™ Threat Management Gateway. In addition, if a VM uses too much bandwidth, a dedicated NIC for the host allows you to access the virtualization server and take action on the VM to correct the situation. For more information about configuring networking, see “Configuring virtual networks” in the Hyper-V Planning and Deployment Guide.

For more information about NAP see For information about Microsoft Forefront Threat Management Gateway and Forefront Code Name “Stirling” (the next generation Integrated Security System in the Forefront line of business security products) see

Use Windows BitLocker™ Drive Encryption to help protect VM resources. BitLocker Drive Encryption works with features in server hardware and firmware to provide secure operating system boot and disk drive encryption, even when the server is not powered or operating. This helps protect data if a disk is stolen and mounted on another machine for data mining. BitLocker Drive Encryption also helps protect data if an attacker uses a different operating system or runs a software hacking tool to access a disk.

Losing a physical disk is a more significant risk in small- and medium-business and remote-office scenarios, where physical security of the server may not be as rigorous as in an enterprise data center. However, it makes sense for all hosts. You should use BitLocker Drive Encryption on all volumes that store VM files. This includes the VMs, virtual hard disks, configuration files, snapshots, and any VM resource, such as ISOs and VFDs. For a higher level of security that includes secure startup, BitLocker Drive Encryption requires Trusted Platform Module hardware (TPM). For TPM management, see the “Windows Trusted Platform Module Management Step-by-Step Guide.”

For more information on how to configure BitLocker Drive Encryption to help protect your server and the VMs running on it, see “Windows Server 2008 Hyper-V and BitLocker Drive Encryption.”

See also “Windows BitLocker Drive Encryption Frequently Asked Questions” and the “BitLocker Repair Tool .“

Important: Use BitLocker Drive Encryption in the Hyper-V parent partition only. Because BitLocker Drive Encryption is not supported within a VM, do not run BitLocker Drive Encryption on a virtual machine.

Additional Resources

  • Virtualization Security Best Practices Podcast:
  • Windows Server Virtualization and Windows Hypervisor: