Step Change in Security with Modern Devices and Architecture


Guest author: Chris Hallum

Prior to Windows 10, we lived in a world where desktop operating system security, whether it was with Linux, OSX, or even Windows was built almost entirely from software. The challenge we faced with this approach was that if malware or an attacker gained enough privilege, could get in-between the hardware and the operating system, or they managed to tamper with the device’s firmware components, they could also find ways to hide from the platform and the rest of your security related defenses.

To address this problem, we needed device and platform trust to be rooted in immutable hardware rather than just software, which can be tampered with. With hardware, we can establish a secure and verifiable chain of trust that starts immediately from the point of power-on and continues on to the point where Windows has successfully booted and all of your security defenses are operational.

With Windows 8 certified devices, we finally could take advantage of a hardware based root of trust with Universal Extensible Firmware Interface (UEFI) Secure Boot. Now, with Windows 10, we’ve taken things to the next level by making sure that this chain of trust can also be verified using the combination of hardware base security components, such as the Trusted Platform Module (TPM), and cloud based services (Device Health Attestation (DHA)) that can be used to vet and remotely attest to the device’s true integrity. The ability to remotely attest to the devices integrity is critical in today’s world, as we can really never trust the device’s ability to self-report its own health and security status.

With this new level of trust and the higher level of certainty that we can maintain, verify, and report on the integrity of Windows devices, the gloves are now off. We’re finally able to invest in making the big architectural changes that can deliver real step changes in terms of security, a goal which simply couldn’t be prioritized if we had to worry about the integrity of the device being undermined in an undetectable way.

Based on this, it’s an exciting time for customers, Microsoft, and of course our partners, as we’re finally on a path to breaking through some of the biggest security challenges we’ve been facing. In the remainder of this blog, we’ll discuss the work we’re doing with industry partners like Intel and our OEM’s to build devices that are more secure at the hardware level, and then we’ll discuss how that hardware has enabled us to deliver a new security architecture for Windows that is going to put attackers in an extremely difficult position, and will prove exponentially more challenging for them to circumvent.

Modern Devices Built for Modern Security

To align and compliment this strategy, we’ve driven key changes in our OEM ecosystem to help enable a more secure, capable device that aligns with our investments in virtualization based security (VBS) and the SystemContainer. This includes regular firmware updates for UEFI, locking down UEFI configs, enabling UEFI memory protection (NX), running key vulnerability mitigation tools (e.g.: ChipSec), and hardening the platform OS and SystemContainer kernels (e.g.: WSMT) from potential SMM related exploits. While we can never guarantee a completely secure device, we can work to mitigate the top vulnerabilities and risks.

Architectural Changes Powered by Modern Devices

We’ve made architectural changes to Windows in almost every release, but one of the most significant architectural designs from a security perspective has existed in Windows for about as far back as anyone can remember. In this architecture, there is an assumption that the long list of defenses on the perimeter of the platform will successfully prevent malware or an attacker from gaining unauthorized access. Sadly, when this assumption fails, there is very little within the interior of the platform to prevent the attacker from gaining broader access and full control.

The architecture itself defines the relationships between the Windows System core (kernel), Windows platform services, Apps, the levels of privilege that are required to interact with each layer, and then finally, the level of privilege users and apps are able to run with. Almost all of the attacks that we observe target the app layer. Apps like the browser are an attacker’s favorite, as this is the gateway that enables them to interact with the user and their device. Browsers represent a huge surface of attack because users can be tricked into installing malicious software while using them, and then because of the complexity of the browser itself, it’s almost certain that attackers will find exploitable vulnerabilities within them.

In either case, when an attacker manages to get a foothold in the app layer, they’ll at least have the user’s level of privilege. Often times this is the Administrator level, giving them free range access to the entire system. But even if the user is using best practices and is logged in with limited Standard User privileges, the attacker may have access to vulnerabilities that will enable them to elevate to an even higher of privilege.

Our first major attempt to solve this problem was in Windows 8, where we introduced a new app platform that we call Universal Windows Apps (UWP). Unlike the architecture mentioned above where apps run with the user’s privilege and have broad access to all Windows Platform Services, UWP apps run with least privilege – meaning they have no access to the system, other apps, and data. They run in a sandbox that we call an AppContainer and, in most cases, the user literally gives the app access to resources, like a document, on demand. For instance, in the UWP version of Microsoft Word, the app only gains access to a specific document when the user explicitly selects it and chooses to open it. This is in sharp contrast to Windows Classic apps (Win32), where once an app is running, it can do anything that the user has the privileges to do (e.g.: open any file; change system configuration).

Universal Windows Apps (UWP) represent both a short and long term solution to the architectural problem we face, but the reality is that the world our customers live in is highly dependent on Win32 apps. Based on this, UWP provides great isolation for new apps, but the legacy apps still carry the same risks that they always have. With Windows 10, we started to work on addressing the challenges of the Win32 world, and we introduced a new hardware based container technology that we call a SystemContainer.

The SystemContainer, much like an AppContainer, isolates what is running within it from the rest of the system and data. However, unlike an AppContainer – which is designed to protect the system, apps, and data from malicious apps, or those that have vulnerabilities within them – the SystemContainer is designed to protect the most sensitive parts of the system – like those the manage user credentials or provide defenses to Windows – away from everything, including the operating system itself, which we have to assume will get compromised.

The SystemContainer uses hardware based isolation and Windows 10’s Virtualization Based Security (VBS) capability to isolate the processes running with it from everything else on the system. VBS uses the virtualization extensions on the system’s processor (e.g.: Intel’s VT-X) to isolate the addressable memory spaces between what is effectively two operating system running in parallel on top of Hyper-V. Operating system one is the one you have always known and use, and operating system two is the SystemContainer, which acts as secure execution environment that runs silently behinds the scenes. Because of the SystemContainer’s use of Hyper-V and the fact that it has no network, user experience, shared memory, or storage, the environment is well secured against attacks. In fact, even if the Windows operating system is fully compromised at the kernel level (which would give an attacker the highest level of privilege), the processes and data within the SystemContainer can still remain secure.

While no security solution is perfect, the SystemContainer represents one of the most impactful architectural changes that we’ve made for Windows security.  Services and data within the SystemContainer are dramatically less likely to be compromised, as the attack surface for these components has been significantly reduced.  With that said, the overall security of Windows Devices requires a close partnership with hardware partners like Intel and our OEMs, and we will continue to work with them to improve the components that Windows security depends on.

With Windows 10 the SystemContainer powers some of our most impactful security features including Credential, Device Guard, Virtual Trusted Platform Module (vTPM), and now, with the Anniversary Update, we are adding yet another component. Windows Hello’s biometrics validation components and the user’s biometric data will be all moved into this environment to help ensure this data can remain secure from even the most advanced threats.

As we move forward with our Windows as a Service model, we will continue to move some of the most sensitive Windows system services into the SystemContainer and we will evaluate how Virtualization Based Security (VBS) could be used to protect things above and beyond the Windows system core, which the SystemContainer is protecting today.

Comments (0)

Skip to main content