This article is a part of a series. The previous article can be found here:
All the Guards – Part 1 (Secure Boot)
In this article I’m going to focus on the next component:
Virtualization Based Security (VBS)
In order to use VSM, you’ll need a number of hardware features to be present and enabled in the firmware of the machine:
– UEFI running in Native Mode (not Compatibility/CSM/Legacy mode)
– Windows 64bit and it’s associated requirements
– Second Layer Address Translation (SLAT) and Virtualization Extensions (Eg, Intel VT or AMD V)
A Trusted Platform Module (TPM) is recommended.
There is a more details in link in the above article of what you need but most modern PC’s today should be capable, however you may want to check this article:
The potential performance impact of Device Guard (HVCI)
The idea is that by enabling virtualization on devices, then you can start to “sand box” and isolate different processes on a machine in their own unique and protected container. However, to achieve all that (which will be covered in upcoming articles) you’ll need to enable virtualization on your device.
Various policies and configurations can achieve this for you automatically but to do it manually open Control Panel, then select Programs and Features and then Turn Windows features on or off on the left. Scroll through the list of features and expand the Hyper-V one as shown above. Select Hyper-V Hypervisor as shown, and then select OK to save and update your device configuration. Typically, you’ll also need to reboot your device for virtualization to be enabled.
Here are others ways you can enable this feature:
Enable virtualization-based protection of code integrity
I will also note that new Surface PC’s will come with this feature enabled per:
There is a small performance hit to your device as is now running virtualised processes, however on most modern Windows devices you should not really notice this.
With that now complete we are ready to look at the next phase of this process:
7 thoughts on “All the Guards–Part 2”