- VMware vSphere 8: Editions, licensing, and pricing - Mon, Nov 21 2022
- Automate file downloads with Windows FTP or curl - Wed, Nov 16 2022
- When did users last change their password in Active Directory? - Thu, Nov 10 2022
Secured Core combines hardware, firmware, and OS features to ensure the integrity of the system during startup and runtime. The hardware requirements include a CPU with activated virtualization extensions (Intel VT, AMD-V), UEFI with Secure Boot, and TPM 2.0.
All modern servers should easily meet these requirements, especially if they have been certified for Azure Stack HCI or Windows Server. The hardware acts as root-of-trust, with the TPM storing the keys needed to verify all components during the system startup.
During the early boot phase, the firmware's secure boot routine ensures that a legitimate boot loader is used and not a rootkit or bootkit.
System Guard monitors the boot process ^
However, in the next phase, Windows does not rely on UEFI integrity, but rather uses System Guard (comprising Secure Launch and System Management Mode (SMM) Protection) to ensure that the system is in a trustworthy state.
Devices whose drivers are not compatible with DMA remapping are prevented from direct memory access by default until an authorized user is logged onto the system.
HVCI as a VBS feature ^
Finally, Secured Core relies on virtualization-based security (VBS), which uses the hypervisor to isolate critical functions from the rest of the operating system, thus protecting them from malware infection.
VBS runs a separate secure kernel at a higher trust level than the actual Windows system kernel. Therefore, the OS kernel and user-mode processes cannot access the protected functions and data directly.
One VBS feature is hypervisor-protected code integrity (HVCI). It monitors kernel code and only allows it to be executed if it has been verified as legitimate. Without it, malware in the context of the kernel would have access to all of the PC's memory. HVCI requires compatible drivers, and their suitability can be checked using the DGReadiness tool.
Configuring Secured Core ^
Some components need to be present in the system, such as the aforementioned TPM 2.0, the UEFI firmware, or a modern processor. Features such as Secure Boot are already enabled by default on most machines, as are CPU extensions for virtualization.
If you want to quickly find out if Secure Boot is enabled, execute the following command in a PowerShell session using elevated privileges:
Information about the virtualization extensions can be found in the Task Manager under Performance or via msinfo32.exe.
The Windows Admin Center (WAC) can be used to check the status of all Secured Core components at a glance. The Security extension has its own tab for this purpose.
You can enable HVCI via the app settings under Device security; Secure Boot is configured in the UEFI settings anyway. The WAC also allows changing the status of the VBS-based features.
Controlling VBS via Group Policies ^
Since Secured Core is not just a concept of Windows Server, but is also present in the client OS, group policies will be the preferred tool to centrally manage the relevant security functions.
The main setting for this can be found under Computer Configuration > Policies > Administrative Templates > System > Device Guard and is called Turn On Virtualization Based Security.
When enabled, four options can be configured via dropdown menus. The first of these is Secure Boot, which can be supplemented with DMA protection on compatible PCs.
Another menu is used to configure HVCI, for which four options are available. Disabled deactivates code integrity, even if it was enabled interactively via the Settings app. On the other hand, Not Configured retains the current state as it is.
Enabled with UEFI lock causes the setting to be permanently stored in the firmware and cannot be removed by resetting the group policy. Rather, it must be physically removed from each PC. Enabled without lock, on the other hand, allows the setting to be changed via GPO.
Activating Secure Launch Configuration activates the System Guard function.
Another group policy can be used to customize DMA protection. By default, it blocks, for example, the connection of Thunderbolt devices that are not compatible with DMA remapping if no user is logged on or the screen is locked.
Under Computer Configuration > Policies > Administrative Templates > System > Kernel DMA Protection, you can change this default behavior to generally block or unblock these devices.
Secured Core in a VM ^
If you apply the described settings to a virtual machine, you can use VBS in general and HVCI in particular. The prerequisite for this, however, is that nested virtualization has been activated for the VM; otherwise, the hypervisor in the guest OS is not available.
System Guard and Boot DMA Protection, however, cannot be used. The WAC identifies both as not supported. For Secure Boot, you need UEFI, which is available only in a generation 2 VM.
The security settings of a VM can be queried in PowerShell with
Get-VMSecurity -VMName "Name-of-VM"
It will also display a parameter called Virtualization¬Based¬Security¬OptOut, which you can set to $true with Set-VMSecurity in case of compatibility problems. These occur, for example, when you try to connect a virtual Fibre Channel adapter.