Before you can address the security of your Hyper-V host, it's important to have a basic comprehension of Hyper-V architecture. Without this, it's difficult to understand how various security measures will affect the components of your deployment.

The most important thing to understand is that, for the most part, the hypervisor is independent of the management operating system. Hyper-V is a type 1 hypervisor, which means that it is not an application or an operating system component. The hypervisor has direct control over the hardware it is installed on. It manages a number of partitions, which contain the virtual machines. One of these partitions, known as parent partition, is where the management operating system runs. The parent partition is the only partition that is allowed to communicate directly with the hypervisor. In Hyper-V, the parent partition provides the hardware drivers used by the hypervisor. To some extent, the parent partition does...

In Chapter 1, Introducing Hyper-V Security, you were briefly introduced to the various delivery methods for Hyper-V in the Acquiring Hyper-V section. The first decision you must make before going into production is which of these methods you'll choose. This is not a clear choice, as each approach has its own strengths and weaknesses.

A general rule in hardening any system is to turn off any system components that lack an identified, definite need. A good place to start narrowing this list to Hyper-V is with the list of roles that Microsoft doesn't support when Hyper-V is enabled. At this time, Microsoft has not published any official statement, but Hyper-V MVP Alessandro Cardoso has written an article on his blog that lists what roles are supported, viewable at http://cloudtidings.com/2013/04/20/sharing-roles-with-hyper-v-on-the-same-physical-host/. These items are:

Although not specifically mentioned, management tools for all the preceding components as well as for Hyper-V are also allowed.

The simplest approach is to not enable any features or roles after installing the management operating system, except Hyper-V and entries...

The Windows Firewall is a built-in component of both Hyper-V Server and Windows Firewall. While this tool is not as robust, secure, or powerful as high-end hardware firewalls, it is one of the better software firewalls available and is quite lightweight. It is possible to disable the functionality of the Windows Firewall, but completely disabling its service causes a number of problems. Since you're required to leave the service running, it's helpful to continue using it even when hardware firewalls are available as a low-cost part of a comprehensive defense-in-depth strategy.

Out of the box, the firewall automatically allows most remote management tools. For normal operations, it should require almost no maintenance. However, some steps can be taken to increase the protection it provides. For one thing, the default rules that enable inbound traffic are open to any source. This subject will be revisited in Chapter 5, Securing the Network, which is dedicated to the...

Unfortunately, an all too common myth around Hyper-V security is that it is better to keep the Hyper-V host in workgroup mode. In reality, if an Active Directory domain is available, it is almost universally better to place all computer systems that are part of the local network into the domain, including the Hyper-V host. The lone exception is for systems that are so high-risk that it's almost expected that they'll be compromised. For these systems, the use of a perimeter network (also known as a DMZ) is a suitable solution. However, it is possible to use Hyper-V inside the local network while allowing all or some virtual machines to access only the perimeter. These options will be seen in Chapter 5, Securing the Network.

For systems that are within the local network, there are quite a few problems with using workgroup security when Active Directory services are available:

Group Policy is a powerful tool that all Active Directory administrators should be familiar with. While it can be difficult to know which policies to set out of the thousands of available options, Microsoft has done a great deal of work for you with the Microsoft Security Compliance Manager (SCM). You can acquire this tool from http://www.microsoft.com/scm. The requirements and instructions for installation, as well as the download file, are given in the links provided on that page. Among the requirements is an installation of SQL Server. An Express installation is included in the package if you haven't got one available.

At the time of this writing, the current version of SCM is 3.0. Its package includes policies for Server and Hyper-V versions only through 2012. However, these policies will work just as well for the 2012 R2 versions. You can click on the File menu and then on Check for Updates to scan the Microsoft repository for any new baselines that may be available...