Windows Server 2016 has been “in the making” for a long time, and many of the readers of this site have probably tested the technical previews, given that Microsoft said there were over half a million devices running the final preview and providing feedback to help make the general availability release better. Well, now it’s official: the company launched this latest version of the server operating system at their Ignite conference in Atlanta in September.
As might be expected, security takes center stage when you run down the list of new features and functionalities. That’s not just a good idea – it’s essential in this era of increasingly sophisticated attacks perpetuated by well-funded and well-organized attackers. Windows Server runs machines that perform mission-critical and high security functions, such as domain controllers that contain identity and access information and file servers that store confidential documents. Thus it’s very important that those machines – physical or virtual – be as secure as possible.
In today’s modern data centers, servers are deployed as virtual machines. There are many advantages to this, in terms of cost, ease of backup and restoration of a machine, and hardware resource utilization. However, up until now there has been a gap in organization’s ability to protect those VMs from certain types of attacks.
Ending the admin free reign era
As discussed in a previous article, PAM (Privileged Access Management) in Windows Server 2016, Microsoft’s new security focus on protecting from threats that can be posed by administrative (privileged) privileged accounts. That article was about protection at the identity and access level, using Just in Time (JIT) administration and Just Enough Administration (JEA) to limit the duration and scope of administrative privilege. This time, we’ll talk about how a new technology called Shielded VMs can help to guard against the consequences of malicious insider attacks or stolen administrative credentials.
If someone with unsavory intentions steals admin creds and is able to copy the VM files, he (or she) could run the VM on a different machine and examine all the sensitive information on it at leisure. Shielded VMs prevent this (among other threat scenarios) by encrypting the virtual machine with BitLocker, using a virtual Trusted Platform Module (vTPM). This involves a new service called the Host Guardian Service, which is deployed to store the keys that are required to run the Shielded VMs.
[tg_youtube video_id=”xip5Qtk-7d8″]
First, the fabric
Shielded VMs work with Windows Server 2016’s Guarded Fabric and are dependent on its components. The Guarded Fabric consists of the following:
- Code Integrity, also known as Device Guard in Windows 10. Code Integrity/Device Guard lets you control what software can run, in both user mode and kernel mode. For best security, you can require that drivers be explicitly whitelisted in the Code Integrity policy before they will be allowed to run. Drivers will be blocked from running dynamic code, and compromised drivers are prevented from running and thus putting the server at risk. You can find out more about Code Integrity in the blog post titled Overview of Device Guard on Windows Server 2016 in the Datacenter and Private Cloud Security blog on the TechNet web site.
- Virtualization-based security (VBS) prevents external attacks by creating an isolated user mode area via hardware technology. Isolated user mode was introduced in Windows 10. Its purpose is to isolate any virtualized processes or data from the rest of the operating system. Code Integrity/Device Guard uses virtualization-based security to prevent attackers from making changes to the app control policy.
- Physical and synthetic TPM v2 allows you to use BitLocker encryption, which Shielded VMs use to encrypt virtual machines. Hyper-V on Server 2016 supports the use of a virtual TPM (vTPM), which does not require that there be a physical TPM present on the host machine.
- The Host Guardian Service (HGS) provides “health attestation” for Hyper-V host machines (we’ll talk more about what that means later in this article) and also protects the keys that are required to run Shielded VMs.
How it all works
When you want to run a shielded VM on a Windows Server 2016 Hyper-V host, the Host Guardian Service has to attest to the health of the machine. You can run a shielded VM only on a host that has been designated as a guarded host. So how do you designate a host machine as a guarded host? You have to create a security group for them in Active Directory Domain Services (AD DS) and then configure a trust relationship between the fabric Active Directory and the forest to which the HGS belongs. This is the simplest attestation method is called admin-trusted attestation and it will work with almost any common server hardware.
However, if you want even more security, you can require TPM-trusted attestation. As the name implies, this method is a little more complicated. Like the admin-trusted method, it requires that you designate guarded hosts, but there are additional steps for configuring it. The key is that the host hardware and firmware has to have TPM v2 and UEFI v2.3.1, and the Secure Boot feature has to be enabled.
It’s important to understand that the guarded fabric and shielded VMs are too different things. You can run a traditional VM that’s not encrypted on the guarded fabric, or you can run an encryption-support VM, where the VM disks are encrypted at rest but are not protected from the fabric admins – this means you need to have complete trust in those admins. Admins can still use VM console sessions to manage these VMs.
The most secure type of VM that you can run on the guarded fabric is a shielded VM, which protects the VM and data from fabric admins and from untrusted software running on the host. VM console connections are not allowed on shielded VMs. You also can’t attach a debugger to the VM process and COM/serial ports are not supported.
How shielded VMs use Encryption
Shielded VMs automatically encrypt the operating system disk with BitLocker. You can also encrypt data disks that are attached to the shielded VM, but this isn’t done by default. The BitLocker keys that the system needs in order to boot the shielded VMs are protected by the vTPM.
There are a number of “secrets” that are used by shielded VMs that are not shared with the fabric. These include the VM’s local admin account password, identity related certificates, domain-join credentials, and trusted disk signatures. To protect these, they are saved in a shielding data file, which is encrypted. This file will have a .PDK file extension. The .PDK file is protected by tenant keys, and these secrets are then provided only to the trusted components within the fabric. A key protector is also in the shielding data file. The fabric admin cannot view of use the information in the shielding data file, other than using it to create the shielded VM.
A closer look at the HGS
We said earlier that the Host Guardian Service basically does two things:
- It operates the attestation service that is responsible for making sure shielded VMs can run only on trusted Hyper-V hosts.
- It protects the keys for powering on the shielded VMs.
The HGS should be run in its own forest, created for that purpose, or in a bastion forest that you already have that’s separate from the fabric admins and administrators of the corporate forest. The HGS is installed as a server role on Windows Server 2016. Then you can create an AD forest for the HGS using the PowerShell Install-HgsServer cmdlet. The HGS will need two certificates, for encryption and signing. You can use your own PKI certificates that aren’t backed by a Hardware Security Module, or you can use a certificate that’s backed by an HSM.
Note:
It is also possible to use a self-signed certificate to set up the HGS, but you should do this only when creating a test lab environment, not in a production environment.
Attestation is the process used by the HGS to verify that a guarded host is healthy. The host has to provide the Key Protection service with a certificate of health and it gets this certificate by completing the attestation process successfully. There are two types of attestation that the HGS can use. You have to pick one mode or the other when you initially deploy the HGS, as the same guarded fabric cannot use both at the same time (although you can switch from one to the other). As discussed previously, admin-trusted mode is easiest to deploy but TPM-trusted mode is more secure.
With admin-trusted attestation, the Hyper-V host send a Kerberos ticket identifying the security groups to which it belongs. Membership in the security group that was configured by the trusted HGS admin is taken as verification of the health of the host. With TPM-trusted attestation, the host sends TPM identifying information, the TCG log that contains information about the most recent boot sequence, and Code Integrity policy information. This information is used to determine the health of the host.
Summary
Shielded VMs running on the guarded fabric make Windows Server 2016 capable of implementing much better security than in the past for running virtual machines. There are additional steps that will need to be completed, including setting up the fabric DNS so the guarded hosts will be able to resolve the HGS cluster, and configuring HGS to recognize the guarded hosts, which are beyond the scope of this article. You can find out more of the deployment details in the Shielded VMs and Guarded Fabric Deployment Guide for Windows Server 2016, which you can download from TechNet.
