Why use shielded VMs for your privileged access workstation (PAW) solution?

It’s great to see customers trying out PAWs and it’s generating a lot of great questions. Many questions are related to shielded VMs so I’d like to focus this blog post on sharing our reasoning for building the PAW solution on shielded VMs.

Running virtual machines (VMs) on Windows client is not new, but running a shielded VM on Windows client is. The ability to run shielded VMs on client was introduced in the Windows 10 1709 release. There are many security considerations built in to shielded VMs, from secure provisioning to protecting data at rest. As part of the PAW solution, the privileged access workload gains additional security protections by running inside a shielded VM.   

There are tons of documents/videos on technet about shielded VMs, this is a good starting point. Note that this blog post is not intended to repeat the content, but rather focus on its usage from the PAW perspective.  

So why shielded VMs?

There are two aspects to this question: 

1. Why do we want to use VMs? (as opposed to dedicated physical PAW devices )? 

1. What are the security benefits when running a shielded VM over a regular VM? 

The use of VMs reduces the number of devices per user. In most environments where PAW is deployed, its user must carry at least 2 devices; in some cases, 5 or more (based on customer feedback). By using VMs, a user can carry just one device with all their workloads and the PAW itself running in different isolated VMs.  

Admins also have an easier time managing the VM images as the images can be more tailored to a specific role. For example, the PAW VM used by Domain Admins to manage Active Directory will differ from the VM image that SQL admins use allowing each to be locked down in ways specific to its role. If there is a need for new applications, admins can easily create new VM images.  

Furthermore, you can harden the OS on the physical machine when all the workloads are moved to VMs. Using application whitelisting (such as a code integrity policy), the physical machine can be further locked down allowing it to run only authorized VMs.  

Let’s dive into the second question about the security benefits of using shielded VMs. It starts with enforcing higher security requirements on the physical PAW itself through remote health attestation: 

1. The physical device must have TPM version 2.0. The endorsement key from the TPM is used as a strong form of device identity;  

1. The TPM is also used in measured boot to ensure that the security configuration and the binaries loaded in the boot process match the approved (healthy) baseline configuration; 

1. Finally, the code integrity policy is also measured and validated against the policy managed by the Host guardian service.  

If the device itself is compromised, any changes to operating system binaries or the code integrity policy will cause it to fail attestation and prevent VMs from running. In short, shielded VM security starts with a clean, trustworthy host as illustrated below: 

In addition to the host remote health attestation, shielded VMs use a virtual TPM to encrypt data through Bitlocker. If the physical device is compromised, the virtual disks are encrypted and the attacker will either have to find a way to break BitLocker encryption or compromise the Host guardian service in the datacenter; neither is trivial. 

A typical process to create a VM is to simply attach a copy of a VHDX which contains the appropriate operating system. In a production deployment, admins usually create syspreped images and distribute the images through file shares. At deployment time, however, there is no guarantee that the VHDX file the admin created hasn’t been tampered with. Shielded VMs add security measures to detect images that have been tampered with and prevent deployment. Admins create a signature (.vsc files) for each trustworthy VHDX. The signature is included in the encrypted shielding data files (.pdk files) and used to check the VHDX during provisioning. If the VHDX’s current signature doesn’t match, VM provisioning will fail. Shielding data files are unique to shielded VM provisioning and you can find more information here. Therefore, to create a PAW VM, you will need to have a shielding data file and a VM template disk with a matching or trusted signature. You can find the steps to create shielding data files here. 

In my next blog post, I will share how I built a couple of PAW VM template. If you have ideas/requests, you are welcome to share it with us.