Why you need secured-core Windows servers

Microsoft has been focusing on hardware-based security recently, with Windows 11 requiring use of TPMs and other security systems to help ensure that your software is safe, and your operating system hasn’t been compromised. That hardware-based approach to security isn’t only for desktop and personal systems; Windows Server 2022 brings many of those tools to your data center.

SEE: Software Installation Policy (TechRepublic)

Hardware-based security is an essential element of securing modern systems, as technologies like containers and virtualization abstract your workloads away from the underlying host OS. The more we ignore the host OS, the more it needs to be secure, as it is the controller for all your applications and services. They may all be isolated from each other, but they’re all visible to the host. A compromise at that level doesn’t risk one application, it risks everything running on the server, especially if you’re running a private or hybrid cloud.

What is secured-core in Windows servers?

That’s where secured-core server comes in, using hardware-based security tools to protect your servers right from the moment they start to boot. The intent is to defend your systems by preventing malicious code from running, either by checking code as it runs or using digital signatures to authenticate applications and drivers. Secured-core builds on the hardware security features built into modern processors, like AMD’s ASP secure processor, which helps manage and lock down the trusted execution environment used for secure boot.

Microsoft is focusing on using a hardware root-of-trust to manage its secured-core platform, starting with familiar TPM-based systems. The Trusted Platform Module is either hardware- or firmware-based, providing a secure environment to store encryption keys, certificates and other digital signatures, and checksums and hashes. It doesn’t need to be particularly big; it only needs to be secure. Secured-core systems need a second generation TPM.

The first and most obvious task is using the TPM to ensure the integrity of a server’s BIOS and firmware, using pro-loaded signatures. These are configured when the hardware is built and depend on the server manufacturer. Having this in place even before the OS is installed gives you a way of checking that your server hasn’t been tampered with before it starts to boot. This then leads to a similar secure boot service to that used by Windows.

By using the TPM to manage signatures, we can use it as part of what Microsoft describes as a dynamic root of trust for measurement. The way systems boot changes over time, as software updates and new services are installed. This means measuring how the various components load and storing and checking these measurements. DRTM gives you another way to ensure your environment is booting correctly, reducing the risk to your servers of root kits and other low-level malware.

Using virtualization-based security

One important aspect of secured-core is virtualization-based security. Here Windows Server takes advantage of the hypervisor functionality built into modern processors to isolate key processes from the rest of Windows. So, for example, it runs a tightly focused environment during log-on that helps protect your admin credentials. Applications running in the background can’t interact with the virtualized log-on environment, so malware can’t snoop on your keystrokes and capture passwords and IDs.

VBS supports a lot more than Windows’ log on services. It provides an isolated, secured section of memory that can be used by Windows to manage various security tools, keeping them protected from exploits. Using this virtual secure mode, it’s possible to check code before it’s run, managing how Windows creates new memory pages, checking them before they’re allowed to execute. As an extra precaution code can’t write to an executable page, significantly reducing the risk of a buffer overflow.

Similarly Hypervisor-protected Code Integrity adds another layer of protection to the Windows Kernel. Referred to in Windows’ security settings as Memory Integrity, this is used to check all kernel mode code, like drivers, before it runs, allowing Windows to block unsigned drivers. Even if malware gets into the kernel, the various levels of VBS reduce the risk of it being able to access data or the underlying Windows platform. This feature is at the heart of the signed driver tools Microsoft is developing, as well as its recently announced smart application control service.

One advantage of these techniques is that they don’t only protect systems from malware, they can also reduce the risk of bugs affecting your servers. It’s a useful coincidence that many of the techniques used by malware are very similar to common driver and kernel mode failures. Keeping systems reliable is a useful side effect of tools like HVCI and VBS.

Managing secured-core

You can manage secured-core functionality from Windows Admin Center, enabling it on supported hardware without having to manage machines individually. While the most benefit comes from running secured-core server tools from first boot on a new server, where it’s possible to measure everything on a clean system, there’s still value in turning on services like Memory integrity. That‘s because while there may be malware lurking in your servers, as part of an advanced persistent threat, these techniques provide a better level of protection than an unsecured server.

Microsoft provides other management tools for secured-core systems, for example using it with MDM-delivered policies to lock down configurations. It’s very easy for anyone with admin permissions to accidentally toggle a secured-core service off, and so we need to have additional protections that revert changes as soon as they’re made. So, for example, if HVCI is required and gets turned off, it’ll automatically be turned back on, keeping servers following your centrally applied security baseline.

This is only the first generation of Microsoft’s secured core approach. The second generation builds on technologies like its Pluton security co-processor, providing a more proactive protection model than the relatively passive TPM. One advantage of Pluton is that it’s simple to keep the security subsystem updated, using the same tooling that Microsoft is using for its Azure Sphere secure Internet of Things platform, updates are pushed regularly, much like Patch Tuesday, but at a hardware level. So, you’re always going to be running the latest version of your processor’s security firmware, with no need to manage updates across an entire data center of servers.

It’s important to remember that secured core is only a tool to help make your systems more secure. Even with it running you shouldn’t drop your existing security models and tooling. A dedicated attacker still has opportunities; it’s just that they now must work at a level above the Windows kernel, attacking parts of the stack.

Even so, it’s not a reason to ignore implementing secured-core servers in your network, of course. Secured core may not be a universal defense, but it does significantly reduce risk with very little work needed on your part. And that is always going to be a win.