- How to change the PowerShell prompt - Wed, Mar 22 2023
- Trim characters from strings in PowerShell - Tue, Mar 14 2023
- Set Chrome, Firefox and Edge as default mail client (mailto handlers) - Mon, Mar 6 2023
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.
The Secured Core security concept is based on features of hardware firmware and software
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.
Another mechanism is Kernel DMA Protection, which is intended to prevent attackers from gaining access to the computer's RAM via external PCI devices and thus stealing passwords or injecting malware.
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.
VBS uses a kernel shielded by the hypervisor to protect critical OS functions
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:
Confirm-SecureBootUEFI
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.
Overview of the status of Secured Core in Windows Admin Center
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.
Interactive configuration of HVCI in the Settings app
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.
These settings can be used to configure three features for Secured Core
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.
Define the behavior of DMA protection for devices that do not support DMA remapping
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.
