Chapter 5: Hardware and Virtualization – Mastering Windows Security and Hardening

Chapter 5: Hardware and Virtualization

In this chapter, we will cover the importance of hardware and virtualization as it relates to security. These items can be easily overlooked but are critical components of the overall strategy for securing your Windows systems. As you purchase hardware, you need to consider the process that exists for the supply chain. Who is manufacturing the hardware and how do we trust that the components that build the final product are clean and free from vulnerabilities? How do we validate that no additional components have been added that could compromise our security and privacy? As we are aware, most of the manufacturing process occurs oversees and we have no visibility into the supply chain process other than receiving a product that's ready to turn on and use. We also need to take into consideration the existence of hardware vulnerabilities that become extremely difficult to manage. Ensuring your hardware is current and secure is just as important as protecting your OS. Vulnerabilities such as Meltdown and Spectre are prime examples of this. You can learn more about Meltdown and Spectre by reading this article:

In addition to the underlying physical hardware is the hardening and securing of virtualized infrastructure that's used to deploy your data center and virtual workstations for users. Chances are most of you have some form of virtualization deployment within your environment. Moving from a decentralized management model to a centralized model for your systems could allow a single point of compromise to morph into a major compromise of many systems within your virtual infrastructure. For this reason, it is critical that you take the time to understand the hardware being used within your environment and ensure it is protected correctly and is secured. A weakness within your hardware is a vulnerability to the running OS on that hardware and all the investment you've spent on hardening the OS becomes obsolete.

Throughout this chapter, we will provide the awareness needed to ensure you know the best protection for your hardware and virtualized infrastructure for protecting your Windows OS is available. As you read through this chapter, you will learn more about the following topics:

  • Physical servers and virtualization
  • Introduction to hardware certification
  • BIOS and UEFI, TPM 2.0, and Secure Boot
  • Advanced protection with Virtualization-Based Security (VBS)
  • Hardware security recommendations and best practices

Technical requirements

For the Physical devices and virtualization section, you will need a Windows 10 OS running with the supported hardware listed throughout to set up Hyper-V on Windows 10. You will also need access to an Azure subscription to set up a VM within Azure:

For the remainder of this chapter, each section will have baseline requirements needed in order for you to turn on specific hardware-based security features and will include links to more information.

Physical servers and virtualization

Today, your organization will most likely have physical devices for both your data center and end users. In your data center, your servers will be running some form of Windows Server on top of the physical hardware layer and your end user devices will be running a version of Windows OS on top of the hardware layer. This adds an additional layer of concern as it relates to security. Within the physical device, your OS requires interaction with the hardware and your data will, at times, be in use on hardware components such as the CPU and RAM, which will be in clear text. The same will apply to the hard drive, which will contain your OS and any personal data stored locally when data is at rest. If no action is taken regarding your storage devices, your data will be in clear text and easily readable. Understanding the physical layer of your devices and what can be done to help better protect them is a critical step in protecting your Windows OS.

In addition to running a single OS on a physical device comes the concept of virtualization. Virtualization, in its simplest form, allows you to take a physical server and install multiple isolated virtual machines (VMs) with their own OSes and applications running on them. This allows greater efficiency and workloads with your current hardware and resources. There is a high chance that your organization has a combination of physical devices and a virtualized infrastructure within your data center. Prior to data center virtualization, you were required to deploy a physical server for each app/service you wanted to deploy (most likely more than one physical server for enterprise grade setups to support the separation of roles and high availability (HA) scenarios). This was a manageable process in the early days of server compute data centers but as more demand came along with the extremely fast pace of technology and the need for more apps, the ability to deploy physical servers quickly became very challenging and expensive.

Fortunately, the advancement of data center virtualization became available and the ability to deploy multiple OSes on a single piece of server hardware has been a game changer within the enterprise. In the following diagram, the physical server deployment underlying hardware only has one operating system, while the virtualized deployment has many sharing the same hardware host:

Figure 5.1 – Physical server deployments versus virtualized deployment

Within the end user world, virtualization has also been widely adopted. Physical devices are a primary driver for the most part, but virtualization of the desktop has allowed companies to overcome many challenges as it relates to quickly deploying desktops to contractors/vendors and offshore employees. Virtualization also provides access to legacy apps that may not be supported on the latest OS and provides additional desktops to users for development and testing. It is also a great scenario for part-time workers or those who only need limited access intermittently. Virtualization provides ample opportunity with great flexibility, but we must remember that it runs on a physical device and the same physical security concerns (and then some) exist when it comes to protecting Windows.

Microsoft virtualization

Let's take a quick look at what virtualization technologies Microsoft provides for both the Windows Server environment and end user desktop.


For a traditional on-premise deployment, Microsoft has its Hyper-V technology, which is a hypervisor-based virtualization platform. Like other enterprise-grade platforms, Hyper-V allows you to manage, deploy, and run multiple VMs on a single piece of hardware, thus allowing better use of your hardware resources. The following requirements are needed to run the Hyper-V platform:

  • Hyper-V Virtual Machine Management Service
  • The virtualization WMI provider
  • The virtual machine bus (VMbus)
  • Virtualization service provider (VSP)
  • Virtual infrastructure driver (VID)

The following tools can be used for managing the Hyper-V environment:

  • Hyper-V Manager
  • Hyper-V module for Windows PowerShell
  • Virtual Machine Connection (sometimes called VMConnect)
  • Windows PowerShell Direct
  • System Center Virtual Machine Manager

For further information about Hyper-V, visit this link:

Hyper-V can be run on both Windows Server and Windows Desktop, with the latest versions being Windows Server 2019 and Windows 10. There are differences between some of the features with Hyper-V on Windows Server and the Windows Desktop version. The primary differences are that Hyper-V on Windows Server is designed for more of an enterprise-grade deployment, thus allowing the migration of VMs between hosts and access to enterprise-grade storage for improved VM performance.

On the other hand, Hyper-V for Windows Desktop allows users to spin up multiple VMs for testing purposes, development purposes, and to run older versions of a client OS. Windows Server also supports advanced hardware protection features using TPM attestation with Guarded Fabric and Shielded VMs.

Hyper-V supports multiple versions of Windows Server, Windows Desktop, Linux OS, and Linux and Free BSD.


To view a list of supported operating systems that can run on Hyper-V, visit this link:

In order to get started with Hyper-V on Windows Server, you will need the following as a minimum:

  • 64-bit processor with second-level address translation (SLAT).
  • VM Monitor Mode extensions.
  • At least 4 GB of RAM. This will increase the more VMs you would like to run concurrently.
  • Virtualization support turned on in the BIOS or UEFI:

    a) Hardware-assisted virtualization.

    b) Hardware-enforced Data Execution Prevention (DEP):

    -- Intel: XD bit (execute disable bit).

    --AMD: NX bit (no execute bit).

In addition to the basic requirements for Hyper-V, you will want to ensure you enable Guarded Fabric and Shielded VMs for best protection and security. In short, Guarded Fabric is the infrastructure component used to enable and protect Shielded VMs from being compromised. Shielding a VM allows it to only be run on an approved host and prevents unauthorized access within the environment, offline, or outside of the protected environment. Shielded VMs first became available in Hyper-V 2016 and require the following features:

  • UEFI 2.3.1 (ensure boot is configured to use UEFI)
  • TPM v2.0
  • IOMMU and SLAT
  • Secure boot enabled

You will need to be using generation 2 VMs and will require a minimum Windows Server 2012 OS in order to enable the Shielded VM feature.


More information on Guarded Fabric and Shielded VMs can be found at this link:

Getting started with Hyper-V on your Windows 10 OS is a pretty painless task. The feature is free to enable, and you will only need licenses for the respective OS you would like to run.

The minimum requirements needed to enable Hyper-V on Windows 10 are as follows:

  • Windows 10 Enterprise, Pro, or Education
  • 64-bit processor with SLAT
  • CPU support for VM Monitor Mode Extension (VT-c on Intel CPUs)
  • Minimum of 4 GB memory
  • Enabled in BIOS: Virtualization Technology and Hardware Enforced Data Execution Prevention

Before you enable this feature, verify the hardware is compatible by opening PowerShell or Command Prompt, type systeminfo, and press Enter. Scroll down to the Hyper-V requirements and verify Yes is listed next to all items.

To view the additional Windows 10 requirements to run Hyper-V, visit the following informational link:

To install Hyper-V through the Windows UI, follow these instructions:

  1. On your supported Windows 10 device, go to Search and type Turn Windows features on or off.
  2. Select Turn Windows features on or off to open the Windows Features window.
  3. Search for Hyper-V and select it. Ensure all sub-options are selected.
  4. Click OK and click Restart Now when prompted to reboot your device, as follows:

Figure 5.2 – Turning the Hyper-V feature on or off in Windows Features


For additional methods to enable Hyper-V, visit the following link:

Now that Hyper-V is enabled, you can start creating VMs on your Windows 10 device and set up your own lab to implement and test the recommendations being provided in this book.

For more information on setting up your first VM, follow the instructions provided here: You will need a license to run any Windows VMs that you have set up.


The following link is for the installation documentation for Hyper-V on Windows Server. This deployment is more involved and will require multiple physical devices in order to be set up and secured correctly:

Azure virtual machines

Microsoft's Azure cloud Infrastructure as a Service (IaaS) offering allows us to set up and consume VMs on-demand with no underlying infrastructure required from the customer. To create a VM within Azure, follow these steps:

  1. Log into the Azure portal at
  2. Click on the Portal menu in the top left (if the menu is hidden).
  3. Select All services and choose Compute.

Here, you will see all the compute services, including virtual machines. You can either click on the Virtual Machines option to be directed to the Virtual Machines portal or you can hover over Virtual Machines to view additional information and options:

Figure 5.3 – Virtual machine tool tip in the All services section of Microsoft Azure

In addition to the Virtual Machines management portal, the Azure Marketplace has pre-defined images provided by Microsoft available to deploy. To view the available images within the Marketplace, follow these steps:

  1. Search for Marketplace within the top search menu and choose Marketplace.
  2. Select Compute in the Categories blade.
  3. Search for Windows to view all the available Windows images:

Figure 5.4 – Available Windows images to deploy using ARM from the Azure Marketplace

For more information about Windows VMs running in Azure, visit this link:

We recommend that you use Azure to deploy and test security configurations for Window Server and desktop for topics that are covered in this book.

Windows Virtual Desktop

Another option available for virtualization in Azure is Windows Virtual Desktop. This PaaS offering from Microsoft provides both desktop and app virtualization within the Azure cloud. The following features are provided with the Windows Virtual Desktop service:

  • Multi-session Windows 10 hosts for non-persistent and persistent virtual machines.
  • Desktop and application virtualization with MSIX support and app attach for app streaming.
  • FSLogix profile containers using AzureNet App files for highly available streaming profiles.
  • Office 365 ProPlus and OneDrive are fully compatible.
  • Support for Windows 7 virtual desktops.
  • Unified management portal to manage user sessions, published applications, and persistent and multi-session hosts.

Take a look at the following link to learn more about the Windows Virtual Desktop service running in Azure:


Windows Virtual Desktop can be thought of as an end user cloud offering, similar to the Citrix Cloud service.

Next, we'll look at the security concerns that affect the underlying hardware of our systems.

Hardware security concerns

Protecting the hardware of your systems is a critical task and one that may not have been at the forefront of your security priorities in the past. Over the years, we have invested heavily on the software side of security but recently, the impact of hardware vulnerabilities has shown the criticality of ensuring your hardware is protected from exploits, thus requiring more attention in this area to address the risks.

The following are some of the risks with hardware that must be addressed:

  • Hardware vulnerabilities, including the following:

    – Rootkits embedded in the BIOS and UEFI

    – Side channel attacks toward CPUs

    – Kernel-level exploits

    – Firmware attacks

    – Memory vulnerabilities

  • Insider threats such as those with physical access to hardware and privileged access to your environment.
  • Referencing back to the NIST Cybersecurity Framework, Supply Chain Risk Management was added to the latest version 1.1 in 2018. NIST references the following cyber supply chain risks to be aware of:

    – Any insertion of counterfeit items as part of the supply chain process.

    – The production of items that have not been approved.

    – Tampering with any items within the process.

    – Theft of any items.

    – The insertion of malicious software and hardware at any time during the process.

    – Manufacturing and development practices not maintaining expected standards during the supply chain process.

You can view additional information about the Cyber Supply Chain Risk Management project and the risks at this link:


NIST Cyber Supply Chain Best Practices:

Now that we've covered various security concerns and common scenarios that can cause exposure to risk, let's look at the concerns for the virtualized environment.

Virtualization security concerns

Now we have moved into a world where we have centralized hundreds and thousands of standalone workloads into significantly less hardware with the advancement of virtualization, it is just as critical that we ensure our virtualized infrastructure is protected correctly. A breach of a virtualized host could mean a compromise in hundreds of servers over a single physical server in the traditional model.

The following are some of the risks with virtualization that must be addressed:

  • Everything listed in the Hardware security concerns section. Your virtualized infrastructure will be running on the same hardware.
  • Hypervisor threats.
  • Virtual machine escape or the ability to interact with the physical host operating system or hypervisor directly from a virtual machine.
  • Non-segregation of resources, network, data, and so on.
  • VM sprawl and allowing the business or non-IT users deploy VMs as needed.
  • Non-encrypted storage, physical drives, virtual disk files, network traffic, and so on.

Although there are security tools and configurations that help ensure the security of your VMs and the data within them, you may want to consider physical separation of specific functions within your virtualized infrastructure. For example, the management plane, the production environment, the demilitarized zone (DMZ), and maybe highly confidential databases should be separated. Ensure the separation of these functions includes the physical host, network, and storage. This will help safeguard against the aforementioned risks. The following diagram shows a representation of using virtualization and isolation to separate different functions within an infrastructure deployment:

Figure 5.5 – Architecture of separating core functions on its own hardware


Microsoft docs has a writeup on Hyper-V security in Windows Server that can be found at this link:

Cloud hardware and virtualization

As you move your workloads to the cloud, you will, at a minimum, subscribe to an IaaS service. Because of the dynamic changes with the cloud offering, you will no longer have any responsibilities regarding the hardware layer and the virtualized hypervisor layer. This will shift your effort from needing to implement any best practices being recommended in this chapter to validating that the provider has these best practices implemented and in place. With Microsoft Azure, Microsoft is only responsible for implementing the security requirements for both the hardware and virtualized hypervisor layer of the services being provided to you. This does not include any additional security hardening on the software layer, including the OS – this will be your responsibility. You will need to work with Microsoft (or your cloud provider) to provide evidence that they have implemented the best security practices with their cloud hardware and virtualization offerings. This is where you need to ensure Microsoft (or your cloud provider) provide responses to a security survey if they don't already have one available and request audits, penetration tests, and security assessments.

As we go through the remainder of this chapter, you will be provided with an overview of the hardware security components and recommendations to ensure your systems are as secure as possible. Although not always feasible based on hardware life cycle programs, it is recommended that you keep your hardware as current as possible and ensure the latest updates for any BIOS/UEFI, firmware, and drivers are applied, especially if there are any publicly known vulnerabilities.

Introduction to hardware certification

Ensuring your hardware is certified is a critical process of the overall security program. As you purchase new servers, PCs, storage, and peripherals, it is critical you validate that the hardware is compatible with your deployed systems. Using non-compliant hardware could make your hardware vulnerable to a compromise or the additional hardware components could even have a compromise already embedded in them.

An example would be allowing the use of USB drives on your devices. Users receiving a free USB drive don't realize that the drive itself could be infected and that, once inserted into your device, it could compromise your entire organization. Because of this, it is critical you only allow pre-certified USB drives that are encrypted and provided by the organization to be used by employees. Any data that is copied from a USB drive to a company device must require encryption. Another concern, as mentioned previously, is the supply chain process. Ensuring the vendor has certified the hardware for Windows significantly reduces the risk the hardware could be pre-infected with vulnerabilities. This doesn't necessarily mean it will be 100% guaranteed, but your risk is reduced significantly.

Purchasing and procurement teams are a critical component in validating the hardware you purchase has been through an appropriate certification process. These teams will help during the supply chain process to ensure vendors are compliant with your requirements, ensure contracts are maintained as promised, and maintain vendor relationships. You will need to work closely with procurement as they work through the request for proposal (RFP) and requirements for hardware-related requests. To ensure the procurement process is optimized, guidelines from technical and security experts should be clearly defined. One important point to call out is that you should be careful with going cheap on your hardware purchases. There is always a drive to bring costs down but opting for hardware that is cheaper than certified hardware could be a costly mistake. It may prove more cost-effective to get a contract with a vendor, standardize on hardware, and purchase a warranty program. There's a good saying in life: you get what you pay for!


Auditing, including vendor management, will be covered in more detail in Chapter 13, Testing and Auditing. This chapter will cover vendor management as it relates to compliance with your suppliers.

In addition to verifying the supply chain process is clean, you will want to ensure you are using hardware that has been certified and approved by Microsoft to run the Windows OS. Microsoft has a very well-defined Windows Hardware Compatibility Program for vendors to follow to ensure they are maintaining the highest standards of security and compatibility for running Windows. Using any hardware outside of this compatibility list could render your Windows OS unstable, and even more importantly, create security gaps within your systems.


Information about the Windows Hardware Compatibility Program can be found at this link:

To view the Windows Hardware Compatibility List, browse to, type in a product name, and click Search. You will be provided with a list of compatible hardware based on your search. The following example returned all the items with laptop in their name:

Figure 5.6 – Windows Compatible Products List for hardware compatibility

There is an additional portal where you can view certified products specific to Windows Server within the Windows Server Catalog. To view supported hardware for Windows Server, browse to Within the landing page, go to the Hardware section and click on the version of Server or specific product category that you would like to view. As you browse through the items, you will see which specific version is supported by Microsoft, along with the badges that were awarded for certification. Hyper-V 2016 and 2019 are also supported for any hardware that has been awarded the Windows Server 2016 and 2019 certified badges:

Figure 5.7 – Windows Server Catalog badges

As you read through this section, you probably realized there is a lot more due diligence needed before you go out and purchase any hardware. Although there is an incredible ecosystem of hardware that supports Windows, you will want to ensure that the hardware you are purchasing is the latest and supports the most current versions of Windows Server and Windows 10. The most current hardware will provide more enhanced features over older hardware. The following sections will cover the hardware security features that need to be enabled on your hardware. In the next section, we will review the BIOS, UEFI, Secure Boot, and TPM components.

BIOS and UEFI, TPM 2.0, and Secure Boot

BIOS, also known as the Basic Input/Output System, is loaded directly onto a PC motherboard. Its purpose is to initialize the physical hardware, go through a series of processes, and eventually boot into Windows. Just like the operating system or PC software, the BIOS in your systems can become outdated and vulnerable to unauthorized modification. Furthermore, the BIOS initializes privileged hardware processes with greater rights than the operating system itself. Malware not only targets the OS, but other mechanisms in the boot process, including the boot loader and hypervisor used for virtualization. It's important to have a system of authorized update mechanisms for updating the BIOS and ensure it's only configured and signed by an authentic source such as the device manufacturer. In order to maintain the integrity of the BIOS and mitigate risks from malware such as bootkits, digital signature verification should be used for updates and include a manual rollback and recovery process.


A bootkit is a manipulation of the Master Boot Record, which allows malicious software to load prior to the operating system and remain active after the OS loads.

According to the NIST BIOS Protection Guidelines, organizations should have an authenticated BIOS update mechanism using the Root of Trust for Update (RTU) measurement with approved digital signature algorithms for verification, as specified in NIST FIPS 186-3, Digital Signature Standard. The updated standard (186-4) can be found at this link:

The NIST security guidelines for protecting BIOS are specified in four system BIOS functionalities and state the following:

  • Use an authenticated BIOS update mechanism with digital signatures to validate the integrity of updates.
  • Secure the local update process with system passwords, physical locks, or only allow BIOS updates through a local update process with physical IT presence.
  • Use integrity protection features to prevent modifications to BIOS.
  • Implement non-bypassability features to ensure only the authenticated update mechanism is used.

To read more about the NIST security guidelines for protecting BIOS, visit this link:

Unified Extensible Firmware Interface

UEFI is also a form of BIOS and is now standard on most manufactured hardware. BIOS and UEFI (BIOS) have a similar boot process regarding the initializing flow but with some differences. UEFI does not rely on a boot sector to copy a Master Boot Record and uses what's known as a boot manager to determine what to boot. The traditional BIOS runs 16-bit code and leverages only the Master Boot Record, which presents limitations such as support for drives larger than 2 TB. UEFI uses the GUID Partition Table (GPT) and supports 32-bit or 64-bit code processes in "protected mode" before transferring control over to the OS during the runtime (RT) processes. The higher bit support has more space that allows for friendlier UIs and faster boot times. UEFI incorporates security technologies such as Secure Boot and additionally supports booting over the network or from flash memory.

Like the BIOS, the first phase in the UEFI boot process is known as the Security Phase (SEC). This acts as a core root of trust (or boot block in BIOS) to validate the integrity of the code and other firmware components before moving to the rest of the boot process. One of the biggest security advantages of using UEFI over BIOS is the ability to validate boot loaders by checking its digital signature using Secure Boot. If a boot loader has been replaced by malicious code, it won't be allowed to execute based on an invalid or revoked digital signature. This check starts the entire trusted boot process, which secures the boot chain all the way until Windows loads.

There are many types of security features built into the UEFI setup and they will vary by vendor. Some of the more common security features found in the UEFI setup are as follows:

  • Password settings that include setting a supervisor password and lock settings preventing users from making changes without entering the supervisor password. You can also require a password at unattended boot, at restart, and even at the boot device list.
  • Fingerprint settings to use biometrics during pre-desktop authentication as an alternative or in conjunction with entering a supervisor password.
  • Security Chip settings for the Trusted Platform Module (TPM).
  • UEFI BIOS Update settings to add protection regarding BIOS updates, including rollbacks.
  • Memory Protection for execution prevention against virus and worm attacks that create memory buffer overflows.
  • Virtualization settings to enable or disable virtualized hardware support such as Intel VT-x or AMD-V.
  • I/O Port Access to enable or disable the use of devices such as wireless, Bluetooth, USB, cameras, microphones, and so on.
  • Internal device access tamper detection of the physical covers of storage devices.
  • Anti-theft to enable a "lo-jack" for your PC using a third-party provider.
  • Secure Boot settings.
  • Intel Software Guard Extensions (SGX) for hardware-based isolation of application code in memory.
  • Device Guard, which is a feature set that consists of Configurable Code Integrity (CCI), VSM Protected Code Integrity, and Secure Boot. Device Guard features set the foundation for Virtualization-Based Security (VBS), which we will discuss in more detail later.

UEFI Secure Boot

Secure Boot is a hardware-based security feature available in the UEFI environment that ensures only trusted software and firmware can execute in the boot chain. Each software, driver firmware, and OS boot loader (Windows Boot Manager) has a digital signature or hash that is validated by referencing signature keys stored in the Secure Boot database. Secure Boot consists of a platform key (PK) created by the OEM that creates the trust to the key exchange key (KEK) with a public/private key pair. The KEK has public signing keys and is used to modify or add signatures to the whitelist (DB) or revoked signature (DBX) database to accommodate for new releases of Windows and known bad signatures for revocation purposes. These "allow" or "deny" databases are used for validation against the certificates, keys, or image hashes of boot loaders, firmware, and drivers. For example, if malware such as a bootkit invalidates the boot loader, then UEFI checks the secure boot database and won't allow the operating system to boot when the signature doesn't exist or is blacklisted. This is important to note because rootkits are typically low-level and hide themselves from the operating system, making them undetectable by most antivirus software:

Figure 5.8 – Sample flow of Secure Boot validating the signature of Windows Boot Manager

Follow these steps to learn how to configure Secure Boot in UEFI BIOS:

  1. Boot into UEFI Setup. Typically, pressing F12 or F10 during startup will load a boot device list where you can choose this setup.


    If you're logged into Windows 10, hold down Shift and choose Restart to be presented with Advanced Options to boot into UEFI.

  2. Secure Boot settings are typically found under the Security tab.
  3. Change Secure Boot to Enabled, as shown in the following screenshot:

Figure 5.9 – Secure Boot configuration on a Lenovo ThinkPad workstation

Next, we'll look at the features of the TPM security chip that is embedded in the hardware

Trusted Platform Module (TPM 2.0)

A Trusted Platform Module or TPM provides hardware-based security typically in the form of a tamper-resistant chip built directly onto a motherboard. A TPM helps by providing a hardware layer separated from the memory and operating system. Its main purpose is to perform cryptographic functions in isolation and is often considered the hardware Root of Trust. TPMs primarily deal with the encryption and decryption of security keys and are passive, so they do not rely on the operating system to process instructions. Each TPM chip has its own unique RSA private key that's imprinted directly to the chip itself. This private key is never exposed to another external process, so only allow the decryption of TPM encrypted keys to be handled from the same TPM chip.

The TPM also has built-in protection against dictionary attacks, which are used to guess the authorization value for gaining access to protected keys. This is known as a TPM lockout and in Windows 10, a maximum count threshold of 32 is set with a 10-minute healing time to prevent tampering. TPM lockout settings can be managed using Group Policy and are located under Computer Configuration\Administrative Templates\System\Trusted Platform Module Services.

For more information about managing TPM lockout in Windows 10 and Server 2016 and later, visit this link:

Windows computers containing a TPM provide enhanced security features that can be leveraged for the following types of functions:

  • Encryption, decryption, and other cryptographic functions
  • Key storage and generation
  • Integrity validation (security such as Secure Boot for firmware and boot loaders)
  • Strong user and device authentication technologies (Windows Hello for Business and Virtual Smart Cards)
  • Antimalware boot measurements for start state integrity checks
  • Virtualized-based security features such as Windows Device Guard and Credential Guard
  • BitLocker drive encryption
  • Health attestation services for both local and remote attestation

In some use cases, such as Bitlocker drive encryption, a USB drive can act as a TPM alternative and must be present for the computer to start Windows. This is known as a TPM startup key and allows the use of BitLocker without a physically compatible TPM chip. Together, in conjunction with a TPM chip or PIN, this enables a form of BitLocker two-factor authentication.

Unlike in earlier versions of Windows, Windows 10 handles most of the provisioning of the TPM and reduces the need for manual configuration. For more information on how Windows 10 uses the TPM, visit this link:

TPM 2.0 and Windows 10 support a feature known as the Health Attestation service. This allows MDM services such as Intune to collect telemetry data from Windows 10 managed devices in your organization for remote device health attestation reports. The state of your device's health attestation can be used with risk-based conditional access and block access to resources if certain compliance conditions aren't met. The additional level of analysis provides runtime protection of hardware after boot. The following screenshot shows a report of Windows Health Attestation telemetry from Microsoft Intune:

Figure 5.10 – Windows Health Attestation report from Intune

The TPM security chip is typically enabled in the Security tab of UEFI setup of processes such as Secure Boot:

Figure 5.11 – TPM 2.0 enabled on a Lenovo ThinkPad workstation

To summarize, we just provided an overview of BIOS, UEFI, TPM, and Secure Boot. We discussed the security features of each, as well as the differences in BIOS compared with UEFI. We then discussed NIST recommended practices for securing BIOS and UEFI and the many functions of the Trusted Platform Module and how it's leveraged. In the next section, we are going to talk about advanced protection with Virtualization-Based Security (VBS) and how to enable features that are dependent on VBS such as Credential Guard and Device Guard.

Advanced protection with VBS

First available in Windows 10 and Windows Server 2016, VBS leverages physical hardware components and a Hyper-V hypervisor to create isolation or virtual secure mode for user and kernel operations. For a system to be considered VBS-capable, it needs to meet the following minimum hardware requirements:

  • TPM 2.0
  • UEFI SecureBoot Enabled
  • Intel VT-x or AMD-v
  • IOMMU (Intel VT-D, AMD-Vi) Input/Output memory management unit
  • SLAT for Virtual Address Translation
  • Windows Hardware Lab Kit (HLK) System Certified
  • Device Servicing Program (Drivers and Firmware on Windows Update service)

For more detailed information around the hardware requirements for VBS, visit this link:

VBS leverages hypervisors in order to create an isolated virtual secure mode to define virtual trust levels. The main hypervisor runs all the normal user mode operations, kernel mode code, and processes such as the Windows OS in non-virtual secure mode. The other hypervisor runs a secure isolated user and kernel mode in virtual secure mode. User and kernel mode code that run in the secure hypervisor can access normal mode operations, but not vice versa. For example, if malware infects the OS, it will remain contained to the OS and be inaccessible to virtual secure mode. This is mainly due to the features of SLAT, which stands for Second Level Address Translation.

The SLAT controlled by the hypervisor changes the page protections on the secured user and kernel mode processes to block access. Even kernel mode operations running on the main hypervisor in normal mode are blocked from accessing secure mode. Many available features of VBS are enabled by default in Windows 10 Enterprise and can be managed with Group Policy or Intune. The following diagram shows the level of separation that is accomplished through VBS security. Normal Windows operating processes occur on the left and are blocked from accessing secure mode on the right:

Figure 5.12 – A hypervisor isolates normal user and kernel modes

The following features are dependent on the VBS hardware requirements in order to be enabled:

  • Credential Guard
  • Device Guard with Windows Defender Application Control
  • Windows Defender Application Guard (Microsoft Edge Sandbox)
  • Hypervisor-protected code integrity (HVCI)

The following screenshot is from System Information on Windows and shows that virtualization-based security is running:

Figure 5.13 – MSinfo32.exe displaying VBS features on this system

Let's look at some of the features that leverage VBS. First, we will cover Credential Guard.

Credential Guard

Credential Guard helps protect user authentication and access tokens in the Local Security Authority Subsystem (LSASS) or Lsass.exe file from being stolen. Without Credential Guard enabled, derived credentials such as Kerberos tickets and password hashes are stored in memory without the secure isolated protection of a VBS hypervisor and are vulnerable to password stealing malware. With Credential Guard enabled, credentials are stored in a protected isolated process called Lsaiso.exe. LSAISO is only accessible by LSASS using secured remote procedure calls (RPC) and credentials stored in LSAISO are not exposed to processes outside of this protected container. This mitigates tools from stealing NTLM password hashes and Kerberos ticket-granting tickets stored in the memory thanks to virtual secure mode's isolation:

Figure 5.14 – LsaIso.exe process running in Task Manager

The following are the types of attacks that Credential Guard helps protect us against:

  • Pass-the-Hash (PtH) is where an attacker can bypass entering a user's credentials by passing a captured password hash as an alternative authentication method.
  • Pass-the-Ticket (PtT) is similar to PtH but where an attacker authenticates by using a Kerberos ticket instead of the user's password.


    With Credential Guard enabled, single sign-on does not work with NTLMv1, MS-CHAPv2, Digest, and CredSSP authentication methods, and applications will prompt for credentials. It is also recommended to use certificate-based authentication for Wi-Fi and VPN using PEAP-TLS and EAP-TLS.

If you're considering enabling Credential Guard, it is recommended to read about the important considerations mentioned in the preceding information tip before turning it on. More information can be found at this link:

Next, we'll look at how to enable Credential Guard. We will use both Intune and Group Policy to do so.

Enabling Credential Guard with MDM (Intune)

To enable Credential Guard from Intune, follow these steps:

  1. Log into Microsoft Endpoint Manager at
  2. Choose the Devices blade and select Configuration Profiles under Policy.
  3. Create a profile.
  4. Give it a descriptive name such as Endpoint Protection – Windows Credential Guard.
  5. Choose Windows 10 and later as the platform.
  6. Choose Endpoint Protection as the profile type.
  7. Select Microsoft Defender Credential Guard.
  8. Select the dropdown and choose to enable with or without UEFI lock.
  9. Click OK.
  10. When back on the Overview page, choose Assignment.
  11. Select a security group to assign the policy to, as shown in the following screenshot:

Figure 5.15 – Windows Defender Credential Guard Device Configuration profile in Intune


Note that enabling Credential Guard with Intune will also enable VBS and Secure Boot with Direct Memory Access (DMA).

Enable with UEFI Lock (recommended) ensures that Credential Guard cannot be remotely disabled. If you need to disable it remotely, choose Enable without UEFI lock.

Now, we'll look at how to do this with Group Policy. As a best practice, we always recommend deploying Group Policy in a test environment before deploying it into a production.

Enabling Credential Guard with Group Policy

To enable Credential Guard with Group Policy, follow these steps:

  1. Open the Group Policy Management Console (GPMC) and create a new policy scoped to the OU where the devices you wish to apply the settings to are.
  2. Give it a friendly name such as Windows 10 and Server 2019 – Credential Guard.
  3. Go to Computer Configuration > Policies > Administrative Templates > System > Device Guard.
  4. Open Turn on Virtualization Based Security and choose Enabled (radio button).
  5. Modify the following dropdowns, as shown in the following screenshot:

    – Select Platform Security Level: Secure Boot and DMA Protection

    – Credential Guard Configuration: Enabled with or without UEFI lock:

    Figure 5.16 – Virtualization-Based Security Group Policy settings

  6. Close GPMC.

For more information about how Windows Defender Credential Guard works, visit this link:

Device Guard

Device Guard is the combination of Virtualization-Based Security features, UEFI Secure Boot, and application control policies, which are used to determine what applications can run on your Windows systems. Application control policies are enforced using Microsoft Windows Defender Application Control (WDAC) (for Windows). WDAC policies are binary files that contain the instructions for whitelisting applications, file paths, COM objects, and can even enforce script signing. Windows Defender Application Control is built around the zero-trust model (discussed in Chapter 1, Fundamentals of Windows Security) and when a policy is enabled, applications need to be explicitly whitelisted in order to run, otherwise they will be blocked. Unlike AppLocker, WDAC enforces policies at the device level and cannot be granularly assigned to specific users and groups. Microsoft recommends a combination of WDAC and AppLocker if you need to be granular with policy configurations. When WDAC is combined with Hypervisor Protected Code Integrity and UEFI SecureBoot, it is known as Device Guard.

WDAC can be deployed without enabling VBS, but it does not provide virtual secure mode isolation to prevent WDAC policies being tampered with. Used together, Device Guard helps protect both user and kernel mode operations with this secure virtualized isolation. Device Guard and, more specifically, Windows Defender Application Control can be enabled with Group Policy, Intune, or Configuration  Manager.

Enabling Device Guard and Windows Defender Application Control with Group Policy

To enable Device Guard with Group Policy, modify the Turn on Virtualization Based Security policy we created with Credential Guard and enable Virtualization Based Protection of Code Integrity (with or without a UEFI lock):

Figure 5.17 – Virtualization-Based Protection of Code Integrity Group Policy

Policies are built and defined in XML format and converted into binary with PowerShell. After your policies have been converted into binary, they need to be stored in a deployment share that can be read by computers in your Active Directory domain if you're using Group Policy. After the policy has been saved, an additional GPO needs to be configured. Follow these steps to learn how:

  1. In GPMC, create a new policy or modify the existing Credential Guard policy.
  2. Go to Computer Configuration > Policies > Administrative Templates > System > Device Guard.
  3. Open Deploy Code Integrity Policy and Enable it.
  4. Enter the UNC path to the .bin file located on the deployment share.
  5. Click OK.

The following screenshot shows the Code Integrity policy file path for the Deploy Code Integrity Policy Group Policy preference:

Figure 5.18 – Deploy Code Integrity Policy Group Policy

For more detailed information about deploying Windows Defender Application Control policies with Group Policy, visit this link:

To enable basic enforcement of WDAC policies in Intune, create a new Endpoint Protection device configuration profile, as follows:

Figure 5.19 – Windows Defender Application Control Device Configuration profile in Intune

Using the UI-based Endpoint Protection profile is limited to what you can set for WDAC and does not support supplemental policies. Use the ApplicationControl Configuration Service Provider (CSP) with a custom profile for fine-grained control over WDAC policies. More information about the ApplicationControl CSP can be found at this link:


Deploy a Microsoft Defender Application Control policy in audit mode first to understand the effects it will have on your Windows devices. Once enabled, policies log to Event Viewer under Applications and Services\Microsoft\Windows\CodeIntegrity\Operational. WDAC events can also be queried with KQL language using the Advanced Hunting feature of Microsoft Defender ATP.

Now that we have covered Device Guard, let's discuss how VBS can protect browser-level exploits with Windows Defender Application Guard.

Windows Defender Application Guard

Windows Defender Application Guard is designed to leverage the Virtual Secure Mode hypervisor isolation of VBS to protect against browser-based attacks through containerization of the Edge browser. Currently, WDAG has built-in support for Microsoft Edge browser, but extends these features to Google Chrome and Firefox through browser extensions. This allows untrusted sites that are opened in Chrome or Firefox to be redirected to a protected Edge browsing session:

Figure 5.20 – Application Guard Extension available in the Google Chrome web store


When enabling the extension or deploying it through Intune, a Win32 component will need to be installed to activate Application Guard. A restart will be required.

Application Guard protects users from sites that aren't defined as trusted in a network isolation policy. Whenever a site is opened that's not in this policy, a new containerized browsing session is opened leveraging the virtual secure mode of VBS and isolating this session from user and kernel mode attacks on the underlying system.

A few examples of attacks Application Guard protects against are as follows:

  • Zero-day and unpatched vulnerabilities exploited from a website
  • Drive-by attacks where malicious code is injected into a website
  • Cross-site scripting (XSS) attacks and other web-based malware

Application Guard can be enabled through Group Policy, Intune, or Configuration Manager, as follows:

Figure 5.21 – Windows Defender Application Guard Device Configuration profile

The following screenshot shows how to configure network boundaries using the Network boundary profile type in Intune:

Figure 5.22 – Network boundary profile for configuring a trusted network boundary in Intune

Next, we'll look at Hypervisor-Protected Code Integrity and how it's used to enhance Windows Defender Application Control.

Hypervisor-Protected Code Integrity

Earlier in this chapter, we covered Windows Defender Application Control (WDAC) code integrity policies designed to whitelist what applications, drivers, and file paths can run. Hypervisor-protected code integrity adds an additional protection layer on top of this by taking these code integrity policies and expanding them into the virtualization-based security features of hypervisor isolation. This helps to ensure that WDAC policies remain resilient against tampering. HVCI is not only applicable to a single system running on physical hardware but can also protect generation 2 virtual machines with a Hyper-V host in Server 2016 or later.

HVCI is the key component of the Memory Integrity functionality of the Core Isolation security features in Windows system security. This helps to ensure that that the code integrity service used to validate the signatures of drivers and kernel mode processes are contained with hypervisor isolation, thus making them protected from being tampered with by malicious code:

Figure 5.23 – Memory integrity feature enabled in Core isolation for VBS security features in Windows Security


While most modern systems have the hardware and drivers to fully support HVCI, it is important to point out that ALL drivers must be HVCI compatible; otherwise, it can result in blue screens or system failures.

To view the list of baseline protections that are required for both VBS and HVCI, visit this link:

Enabling HVCI

If you followed the previous section to enable Windows Defender Application Control and Device Guard, then HVCI has inadvertently been enabled. To recap from earlier, do the following:

  1. Open GPMC and create a new GPO or modify an existing one.
  2. Go to Computer Configuration > Policies > Administrative Templates > System > Device Guard.
  3. Open Turn on Virtualization Based Security and choose Enabled (radio button).
  4. Ensure the dropdown under Virtualization Based Protection of Code Integrity is set to Enabled with or without a UEFI lock, as follows:

Figure 5.24 – Group Policy preference to enable HVCI and Virtualization-Based Security features

HVCI can also be validated by running msinfo32.exe in an elevated PowerShell window. Look for Virtualization-based security Services Running that lists Hypervisor-enforced Code Integrity, as shown in the following screenshot:

Figure 5.25 – System Information system summary showing that VBS services are running and configured for HVCI

Next, we'll have a look at System Guard.

Windows Defender System Guard

System Guard is a collective of hardware protection features (such as Secure Boot) that ensure the integrity of your system is protected on boot as well as after Windows is running. Using local attestation through Root of Trust Management (RTM) measurements and through remote attestation, RTM measurements can be sent for analysis to an MDM solution such as Intune or Configuration Manager. If a PC is determined to be untrustworthy, remote action can be taken to isolate the device. This helps to protect the system after boot through analysis and monitoring of these measurements. System Guard, by design, is aligned with the zero-trust security model and assumes that all processes could be compromised.

System Guard uses Dynamic Root of Trust measurement (DRTM) with a process known as Secure Launch to dynamically protect and add management flexibility over the Static RTM (SRTM) that's typically used for local attestation of boot processes. As we discussed earlier, the security phase (SEC) in UEFI is loaded at the start of boot and begins the Trusted Boot process. In order to achieve compliance with an SRTM, each piece of code in the entire boot process must be validated from start to finish against a whitelist of known trusted measurements. Due to the large number of hardware vendors, executables, libraries, BIOS versions, code updates, and length of code, support for scaling this whitelist is difficult. Also, SRTM does not protect the runtime after load operations and requires trust be maintained through the entire boot process. Dynamic root of trust measurement and the Secure Launch technology of System Guard help overcome these challenges.

DRTM simplifies SRTM management by allowing for the boot process (sometimes unvalidated) to be executed and immediately controlled by being forced into a secure Launch Code container. This launch code is known good code that's used to continue the boot process and is independent of specific hardware configurations. This dynamic measurement allows for more flexibility, and code that's not added to SRTM measurements can boot the system before Secure Launch takes control. The system can maintain a Trusted Computing Base standard without you having to reset the entire TPM and validate the entire boot chain end to end. Trusted Computing Group (TCG) has defined a Trusted Computing Base (TCB) as what protects the system and enforces computer security policy.

For more information on the DRTM specification, visit this link:


Only TPM2.0 supports System Guard Secure Launch and remote attestation. To enable System Guard Secure Launch, all requirements for Device Guard, Credential Guard, and VBS must be met.

We have just covered many of the hardware-based security features that are used to protect your systems all the way through the boot process. Now, we'll recap this chapter by providing a list of security recommendations.

Hardware security recommendations and best practices

When looking at the security of hardware, it's important to keep these considerations in mind:

  • Only purchase hardware that has been through a proper hardware certification program. The Windows Hardware Compatibility Program Certification process is a great resource to help ensure the hardware is reliable and compatible for Windows.
  • Have a good secure system for upgrading Firmware/BIOS and ensure the proper protections are enabled to ensure only approved sources can update them.
  • Purchase physical hardware with a minimum of TPM 2.0 in order to leverage the advanced cryptographic functionality it offers. Most new hardware-based security features require it.
  • Turn on Virtualization-Based Security as soon as possible and enable Credential Guard, Device Guard, and Application Guard to put the power of your hardware into action.


In this chapter, we provided an overview of the hardware-based security features used to protect Windows from the boot chain, the OS layer, and for virtualization of the OS. We covered hardware concerns in terms of vulnerabilities such as rootkits and bootkits and the importance of the supply chain to ensure your organization purchases hardware that has been properly certified. Next, we covered BIOS, Secure Boot, and TPM and how these hardware components are the framework for hardware backed VBS. We talked about the latest advanced protection features using VBS such as Credential Guard, Device Guard, Windows Defender Application Control, and Hypervisor-Protected Code Integrity, as well as how to enable them using MDM or through Group Policy.

Finally, we finished by discussing how System Guard uses dynamic root of trust measurements and remote attestation to help protect your systems from the boot process into runtime.

In the next chapter, we will discuss networking and the fundamentals that play a large role in securing your Windows systems. We will discuss physical hardware components used in the network infrastructure and the Windows Defender Firewall software, including configurations with Intune, Group Policy, and Configuration Manager. We will enable a feature of Windows Defender known as Windows Defender Exploit Guard-Network Protection, which acts as a proxy to protect us against social engineering and phishing attacks. Finally, we will provide an overview of Azure network solutions that are used to secure Windows systems inside an Azure virtual network.