Microsoft virtualization-based security, also known as “VBS”, is a feature of the Windows 10 and Windows Server 2016 operating systems. It uses hardware and software virtualization to enhance Windows system security by creating an isolated, hypervisor-restricted, specialized subsystem. Starting with vSphere 6.7, you can now enable Microsoft (VBS) on supported Windows guest operating systems.
You may or may not be familiar with these new Windows features. Based on conversations I have with security teams, you might want to become familiar! What you will hear first and foremost is the requirement for “Credential Guard” which is why I added that to the title. In order to level set the conversation in this blog I will go over the features as they related to a bare metal installation of Windows and then a Windows VM on ESXi.
Bare Metal .vs. Virtualized
What follows is my interpretation of the Microsoft technologies based on publicly available documentation and websites I have been following since the features became public.
As always, because we are talking about Microsoft features in their OS, you should consult their documentation for exact wording and guidance.
Windows on Bare Metal
In order to set the stage and help you better understand what is necessary to enable VBS on a hypervisor-based platform, let’s start by talking about enabling VBS on a laptop or desktop, where Windows is the bare metal installation.
To enable VBS on a laptop or desktop you need to ensure certain bios/firmware settings have been enabled and Windows is installed based on some of these settings. A brief list of things to be set include:
UEFI firmware
Secure Boot
Hardware virtualization (Intel VT/AMD-V settings) and IOMMU
Windows installed with all the above settings enabled
Only then can you enable VBS within the Microsoft Windows OS. The following graphic represents how Windows 10 is installed on the hardware and the components at play when you enable VBS.
After you have configured VBS in Windows the system will reboot and the Microsoft hypervisor will load and then Windows. The hypervisor will also leverage virtualization to bring up additional Windows components (e.g. credential management subsystem) in a separate memory space.
TPM 2.0 (Trusted Platform Module)
Most modern systems have a TPM 2.0 device built in to the hardware. (represented in the graphic above) If enabled then Windows will use it to secure credentials stored in the credentials subsystem. If the hardware TPM is not enabled in the BIOS or not in the hardware, then Windows will still use VBS and you can still enable Credential Guard but the credentials won’t be as secure.
Pass the Hash and Credential Guard
In a traditional Windows installation hashed credentials, including Active Directory credentials, were available to almost anyone with enough local OS privileges because they lived in the same memory as Windows. That was known as the Pass the Hash exploit. Enablement of a VBS feature called Credential Guard will keep account hash information outside the scope/memory of the Windows instance. This mitigates the Pass the Hash exploit according to Microsoft.
All communication between Windows and the additional Windows components are via RPC calls run through a Microsoft hypervisor-based communications channel.
ESXi on Bare Metal
Ok, so now let’s introduce vSphere into the mix. For some time now you have been able to install Windows 10 or Server 2016 as a virtual machine. Here’s an example of a standard VM running Windows 10 on an ESXi server.
In a vSphere world, ESXi is the bare metal installation. In order to support Windows 10 with VBS you have to present to the Windows 10 VM the same level of BIOS/Firmware/Hardware. Only in this case, the VM has no access to the bare metal so functionality will be virtualized.
In order to enable VBS the VM must be running at Virtual Hardware version 14. New versions of Virtual Hardware expose newer functionality and support for VBS comes with version 14.
The VM needs hardware virtualization and IOMMU to be exposed/granted to the VM. This is more popularly known as “Nested Virtualization”. Why do we need to run a Windows VM “nested”? Because the Microsoft’s hypervisor will be booting first so that it can provide to Windows the necessary capabilities for VBS.
Additionally, The VM needs to have Secure Boot enabled and be booting from the EFI firmware. Just like in our laptop/desktop example.
Note: If you are creating new Windows 10 or Windows 2016 VMs make sure you are selecting UEFI firmware before installing! Switching from traditional BIOS to UEFI (“EFI” in VM options) is “painful”. Switching after the fact introduces additional steps.
You can see in the image below that there is a new “Enable” checkbox for Virtualization Based Security. When you check that box all of the necessary changes are made. The VM now has CPU virtualization extensions exposed to it, IOMMU is turned on and EFI firmware and Secure Boot are enabled.
Virtual TPM 2.0
Notice how “virtual TPM” is not enabled by default when you select VBS. vSphere 6.7 allows for adding a “virtual TPM 2.0” device but that will introduce an additional requirement. You need vSphere VM Encryption. Here’s why.
A hardware TPM has the ability to store information securely in a hardware-based “vault”. A virtual TPM doesn’t have a hardware based “vault”* so instead, the data to be secured in the TPM is written to the “.nvram” file which is encrypted using VM Encryption. This provide a number of key features:
Data written to the vTPM is secured with very strong encryption.
Because we use VM Encryption, we retain the portability of virtual machines.
A virtual machine with a vTPM can be vMotioned, backed up with existing tools, etc…
Because the VM is encrypted, the predefined “No Cryptography Administrator” role can now be used to restrict permissions on the VM.
This secures console access, prevents downloads of the VM from the datastore and enforces a “least privilege” operational model
Encryption is only performed on the VM “Home” files and not the VMDK’s unless you choose to encrypt the VMDK’s.
Impact to performance is minimal as we are only encrypting a few hundred kilobytes/megabytes of files on the datastore.
The vTPM is not dependent on the physical TPM.
*A physical TPM has a number of technical challenges. It’s not designed for 100’s or 1000’s of VM’s to store their credentials. It’s too small for that. Storage in a TPM is measured in kilobytes, not gigabytes. It’s also a serial device so it is very slow.
More information on ESXi’s use of the hardware TPM and how vTPM’s work is coming in another blog article.
Windows with VBS on vSphere
Here’s an example of a standard Windows 10 VM and a Windows 10 VM with VBS enabled running on vSphere:
It’s all about “virtual hardware”
You can see that we are primarily talking about virtual hardware support in this blog article. The virtual machine that needs VBS is presented with nested virtualization, virtualized TPM, Firmware/BIOS support for Secure Boot and UEFI, etc. Same as on the laptop/desktop example. vSphere 6.7 provides that necessary virtual hardware support to allow Windows 10 and Windows 2016 to be able to function as designed.
For example, when you add a virtual TPM 2.0 device to the VM the Windows guest OS sees this as a standard TPM 2.0 device using existing Windows drivers.
At no time are we talking about anything “special” that has to be installed and run in the guest OS to make all of this work. Once all settings are enabled at the vSphere level you would use standard Microsoft methods to enable VBS in the Guest OS.
How easy is this?
Very! This builds upon our goal of making security easy to implement. In my testing in the lab this has worked quite well. I used the Microsoft Device Guard and Credential Guard hardware readiness tool to check compliance with VBS and enable Credential Guard. The tool is an easy to use PowerShell script. VBS can also be enabled with Group Policies.
Please consult your Microsoft Documentation for the best method to enable these features in your Windows guest OS and environment.
Operations
I find that many folks compare running an operating system on bare metal to running on vSphere as apples to apples. They really aren’t. It’s really more apples to oranges. What is different is that running VM’s on a hypervisor brings with it new operational methods and controls. You need to think more about VM’s as objects and how you can manage them at scale.
A laptop is a single entity with a number of hardware-based controls. You can lock the end user out of the system BIOS and set requirements for things like encryption based on their credentials. But in a virtualized desktop environment you don’t really need that because the end users don’t have access to the underlying hardware or management plane of the VM. Using the same methods as securing the laptop doesn’t translate directly to how you would secure a VM and some of them could actually interfere with how to properly secure them in the datacenter. So, be open to understanding the different use cases. Don’t try to jam the square peg into the round hole.
Wrap Up
Support for VBS and virtual TPM has been one of the most interesting moments in my career at VMware so far. From the time I presented the technology to a number of folks after it was announced at MS Tech Ed a couple of years ago to its release today has been a wild and fun ride.
I would like to tip my hat to the VMware engineers who made this happen at a VERY rapid rate. Microsoft worked closely with this engineering team so that we could provide a supported virtual hardware layer that Microsoft’s operating system could take advantage of. I would like to thank Microsoft as well for their support of this effort.
Expect more information on this and other 6.7 features as we get closer to VMworld! As always, you can reach me on Twitter at @vspheresecurity or @mikefoley. Those are probably the easiest and quickest ways to ask a question and get a response.
