Understanding Virtualization-Protected Code Integrity
Blocking Untrusted Software Created Another Problem
Application control sounds straightforward in principle.
An organization decides which software should be trusted, Windows checks the code attempting to run, and anything outside the approved policy is refused.
But the security mechanism making that decision also needs protection.
The Guard Itself Can Become a Target
If malware can compromise the component responsible for deciding what code is trusted, the attacker may attempt to manipulate the decision instead of defeating every individual application-control rule.
The Windows Kernel Sat Beneath Ordinary Applications
User applications normally operate above the Windows kernel and depend on it for access to memory, devices, processes, and many other system resources.
Code executing in kernel mode therefore occupies a much more privileged position than an ordinary desktop application.
A successful kernel compromise can change the security problem dramatically.
Administrator and Kernel Are Not the Same Level
An administrator account is highly privileged, but kernel-mode execution gives malicious code access to an even more fundamental part of the operating system where many security mechanisms themselves operate.
Windows Needed to Decide Whether Code Was Allowed to Execute
Code Integrity participates in determining whether executable code satisfies the trust requirements imposed by Windows and organizational policy.
For a tightly controlled business computer, those requirements can be substantially more restrictive than simply allowing any executable the user happens to download.
The organization can define what belongs on the machine.
Trust Can Be Defined Before the Program Arrives
Application-control policy allows administrators to establish approved code, publishers, or other trust rules so execution is governed by policy rather than relying entirely on recognizing malware after it appears.
A Program Did Not Need to Be Proven Malicious Before It Could Be Refused
Traditional antimalware protection asks whether software appears dangerous.
Application control can ask a different question: is this software among the code the organization has decided to trust?
Those approaches address the problem from opposite directions.
Malware Detection
Attempts to identify code that is known or suspected to be malicious and prevent or remediate the threat.
Application Control
Defines what code is trusted to execute and can refuse software that falls outside the organization’s approved policy.
Unknown Software Could Start From a Position of No Trust
On a general-purpose computer, users commonly expect newly downloaded programs to run unless security software finds a reason to stop them.
A restrictive application-control environment reverses that assumption. Software must satisfy the organization’s trust policy before execution is permitted.
Unknown code does not automatically receive an opportunity to run.
The Question Changes From Why Block It to Why Trust It
An allow-based security model reduces dependence on identifying every possible malicious program because software outside the approved trust policy can be refused even when no malware signature exists for it.
Compromising Code Integrity Could Undermine the Policy
A strong application-control policy is valuable only while Windows can enforce it reliably.
If sufficiently privileged malware can alter the code, memory, or data used by the enforcement mechanism, an attacker may attempt to convince the operating system that prohibited code should be accepted.
The policy therefore needs protection from the environment it controls.
Rules Are Weak When the Attacker Can Rewrite the Referee
Protecting application-control policy requires more than creating a list of trusted software; the system responsible for enforcing that list must itself resist modification by compromised code.
Virtualization Could Protect More Than Virtual Machines
Hardware virtualization was familiar primarily as a way to run multiple operating systems on one physical computer.
Windows 10 used the same underlying processor capabilities for another purpose. Virtualization-based security could create an isolated execution environment separated from the ordinary Windows operating system.
The hypervisor became part of the security architecture.
Virtualization Became a Defensive Tool
Windows 10 virtualization-based security uses Hyper-V technology to establish a protected environment in which selected security-sensitive code and data can be isolated from the normal operating system.
The Kernel Was No Longer the Lowest Software Authority in the System
When virtualization-based security is active, the Hyper-V hypervisor operates beneath the normal Windows kernel.
That positioning allows the platform to establish memory boundaries that the ordinary operating system is not supposed to cross, even though Windows continues running normally above the hypervisor.
A new trust boundary appears below the kernel.
Higher Privilege Does Not Mean Unlimited Privilege Anymore
Virtualization-based security is designed so selected protected memory can remain outside the normal kernel’s direct control, reducing what a kernel compromise can automatically reach.
The Trust Decision Could Be Isolated From Ordinary Windows
Device Guard could use virtualization-based security to protect Code Integrity.
Instead of leaving the complete trust decision inside the same normal kernel environment that malware might attempt to compromise, sensitive Code Integrity functionality could operate within the hypervisor-protected security boundary.
The referee moved behind another wall.
Isolation Protected the Decision, Not Just the Application
The important architectural change was that security-sensitive Code Integrity functionality could be separated from the ordinary Windows kernel rather than relying entirely on the kernel to protect its own enforcement mechanism.
Malware Could Control Windows Without Automatically Controlling Everything
Historically, gaining kernel execution often meant reaching one of the most privileged positions available within the operating system.
Virtualization-based security introduced an additional boundary beneath that environment. Selected secrets and security services could remain isolated even if ordinary Windows experienced a serious compromise.
The attacker could reach the kernel and still encounter another wall.
Compromise Could Be Contained by Architecture
Virtualization-based security does not make a kernel compromise harmless, but it can prevent that compromise from automatically granting direct access to selected security-sensitive resources protected by the hypervisor.
Several Technologies Worked Together to Establish Trust
The original Device Guard concept combined multiple Windows security capabilities rather than representing one isolated scanner.
Secure Boot helped establish trust during startup. Configurable Code Integrity defined which software was approved. Virtualization-based protection could harden Code Integrity itself against tampering.
Each layer addressed a different weakness.
Device Guard Described a Security Configuration
Microsoft used the Device Guard name for a collection of technologies that could work together to restrict execution to trusted code and strengthen enforcement through hardware-backed security.
The Protection Needed a Trustworthy Startup Path
A protected Code Integrity environment is less useful if malicious software controls the computer before Windows security begins.
UEFI Secure Boot helps verify trusted components during the earliest portions of startup so unauthorized boot software has greater difficulty inserting itself beneath the operating system.
The chain begins before Windows reaches the desktop.
Later Security Depends on Earlier Security
Virtualization-based protection relies on a trustworthy platform foundation, making Secure Boot and compatible firmware important parts of establishing the environment in which protected Windows security services operate.
Not Every Computer Could Provide the Same Isolation
Virtualization-based security depends on processor and platform capabilities.
The system needs hardware virtualization support, appropriate firmware, and compatible security features to establish the protected environment as designed. Enterprise deployment therefore required administrators to consider hardware readiness as well as Windows configuration.
This was not merely an application installed on top of any PC.
Architecture Determines What Security Is Possible
Hardware-backed isolation depends on capabilities provided by the processor, firmware, and platform, so software policy alone cannot reproduce every protection on hardware that lacks the required foundation.
Kernel Code Could Be Restricted Before It Loaded
Device Guard Code Integrity policy could apply to drivers and system files as well as ordinary applications.
This is important because a malicious or unauthorized driver operates much closer to the kernel than a conventional desktop program. Preventing untrusted kernel code from loading reduces opportunities for attackers to gain that privileged position.
The policy reaches below the application layer.
Application Control Was Not Only About Applications
Code Integrity policy could govern kernel-mode drivers and system components, helping organizations restrict some of the most privileged executable code on the computer.
Ordinary Executables Could Be Required to Meet Organizational Trust Rules
Businesses often operate computers with predictable software requirements.
A workstation used for accounting, point-of-sale activity, manufacturing, healthcare, or another controlled purpose may need only a defined collection of approved applications. Device Guard policy could restrict execution to software trusted by the organization.
Anything else could remain outside the allowed environment.
Predictable Computers Are Easier to Lock Down
Application allowlisting is particularly practical on systems where administrators know which software is legitimately required and users do not routinely need to install arbitrary programs.
Executable Content Was Broader Than Traditional EXE Files
Attackers do not need to package every malicious operation as a conventional executable.
Scripts and other forms of executable content can also perform powerful actions. Device Guard’s broader Code Integrity approach allowed organizations to think about trusted execution beyond the familiar application file.
The policy could address more of the execution surface.
The File Extension Is Not the Security Boundary
A strong application-control strategy considers the different mechanisms through which code can execute rather than assuming that blocking unfamiliar EXE files alone prevents unauthorized activity.
Organizations Did Not Need to Approve Every File Individually
Maintaining an exact list of every permitted executable can become difficult as legitimate software is updated.
Code-signing information allows policy to trust software based on approved publishers or signing authorities under appropriate conditions. New versions can then remain manageable without manually cataloging every individual binary.
Trust can follow a controlled software source.
A Trusted Publisher Can Simplify an Allowlist
Publisher-based rules can make application control more maintainable by allowing appropriately signed software from approved sources while continuing to reject code that falls outside the organization’s trust policy.
Microsoft Did Not Need to Decide Every Application an Organization Was Allowed to Run
Different businesses use different software.
A hospital may trust applications that would never appear on an engineering workstation. A manufacturer may depend on specialized control software unknown to a general consumer PC. Device Guard allowed organizations to establish policies appropriate to their own environments.
Trust could be enterprise-specific.
Known to Microsoft and Approved by the Organization Are Different Standards
Enterprise application control can incorporate organizational policy so software is permitted because it satisfies the business’s trust requirements rather than merely because it is common or widely distributed.
An Administrator-Level Attacker Could Try to Rewrite the Rules
Application control loses much of its value if anyone who obtains administrative access can simply disable the policy and launch whatever software they want.
Microsoft therefore provided mechanisms for protecting Code Integrity policy, including signing policies so unauthorized modification becomes more difficult.
The rules need integrity too.
Administrative Access Should Not Automatically Mean Policy Ownership
Protecting and signing Code Integrity policy helps organizations resist attempts by malicious users or compromised administrator accounts to alter the rules governing which software is trusted to execute.
The Enforcement Mechanism Could Be Protected From the Normal Kernel
A signed policy helps protect the rules stored on the system.
Virtualization-based security addresses a different problem: protecting sensitive Code Integrity enforcement from tampering while the computer is running. The two protections therefore reinforce different parts of the trust system.
One protects the policy; another protects the decision environment.
Stored Integrity and Runtime Isolation Solve Different Problems
A policy can be cryptographically protected against unauthorized modification while virtualization-based security separately hardens the runtime mechanism responsible for applying trust decisions.
Elevation Did Not Necessarily Put the Attacker Above Every Security Boundary
Administrator privileges are extremely powerful and a compromised administrator account remains a serious security event.
But Windows 10’s hardware-backed security architecture aimed to make selected protections resistant even to threats operating with substantial authority inside the normal operating system.
The hierarchy of trust became deeper.
More Privilege Does Not Have to Mean Universal Access
Hardware-backed isolation can create boundaries that ordinary Windows administrator privileges are not intended to control directly, reducing the assumption that compromising an administrator automatically compromises every protected security resource.
Virtualization Could Protect Secrets as Well as Trust Decisions
Credential Guard and Device Guard were closely associated with Windows 10’s virtualization-based security architecture, but they addressed different problems.
Credential Guard isolates selected authentication secrets to make credential theft more difficult. Device Guard’s virtualization-protected Code Integrity focuses on strengthening the mechanism that decides whether code is trusted to execute.
The isolation technology supports different defenses.
Credential Guard
Uses virtualization-based isolation to help protect valuable authentication material from theft and reuse by malware.
Device Guard Code Integrity
Uses virtualization-based protection to harden trust decisions governing which code is permitted to execute.
Security Did Not Need the Name of Every Future Virus
Malware changes continuously.
If security depends exclusively on identifying known malicious software, attackers can attempt to create new variants that are sufficiently different to avoid immediate recognition. An allow-based execution policy approaches the problem differently.
The unknown program may simply lack permission to execute.
Unknown Malware Can Still Be Unapproved Software
An organization does not necessarily need a malware signature for a newly created threat when the malicious program already falls outside the set of code authorized to run on the managed device.
A Strict Allowlist Could Also Block Legitimate Work
Application control can be extremely effective and extremely disruptive when deployed carelessly.
Businesses often have old utilities, internally developed software, uncommon drivers, unsigned components, and specialized applications that may not initially satisfy a restrictive policy.
Those legitimate dependencies need to be understood before enforcement.
A Perfectly Locked Computer That Cannot Do Its Job Is Not a Successful Deployment
Organizations need to inventory required applications and drivers, test policies, and account for legitimate software updates before enforcing restrictive Code Integrity rules across production systems.
Administrators Needed to Learn What Would Be Blocked
Security policy should not begin with guesswork.
Before a restrictive application-control configuration becomes mandatory, administrators need visibility into the software actually required by users and systems. Testing can reveal legitimate components that would otherwise be unexpectedly refused.
Deployment is as important as the technology itself.
Build the Trust Policy From Evidence
Application inventories, controlled testing, and staged deployment help organizations create restrictive policies without discovering critical software dependencies only after users can no longer launch them.
Approved Software Would Not Stay on One Version Forever
Applications and drivers require updates for security, compatibility, and functionality.
An application-control policy therefore needs a strategy that allows legitimate updates while continuing to reject unauthorized code. Publisher and signing rules can help make that process manageable.
Trust needs to survive maintenance.
Static Rules Meet a Changing Software Environment
A practical Code Integrity deployment must account for the ongoing lifecycle of approved software rather than assuming the exact files present on the day the policy is created will remain unchanged indefinitely.
The Protected Environment Was Not Just Another Windows Process
Ordinary process isolation still depends heavily on the Windows kernel enforcing boundaries correctly.
Virtualization-based security establishes separation with assistance from the hypervisor and processor virtualization capabilities. That places the protected environment outside the ordinary process hierarchy controlled by the normal kernel.
The security boundary is architectural rather than merely procedural.
The Wall Was Built Below the Operating System
By relying on hardware virtualization and the Hyper-V hypervisor, Windows could protect selected security functionality using a boundary that ordinary kernel-mode code was not intended to cross.
The Kernel Did Not Need to Hold Every Valuable Secret and Decision
For decades, the operating-system kernel represented the ultimate software authority on a conventional PC.
Windows 10’s virtualization-based security model began separating selected high-value functions from that traditional environment. Credential material and Code Integrity decisions could receive protection from a layer beneath ordinary Windows.
The operating system was beginning to defend itself from itself.
A compromised kernel could remain extremely dangerous without automatically becoming the owner of every protected security decision.
Virtualization Gave Code Integrity Somewhere Safer to Make Its Decisions
Device Guard represented a significant change in the way tightly managed Windows computers could decide what software was allowed to execute.
Organizations could establish Code Integrity policies defining trusted applications, drivers, and system files. Windows 10 could then strengthen enforcement by using virtualization-based security to isolate sensitive Code Integrity functionality from the normal kernel environment. Microsoft describes this protected Code Integrity service as operating in a Hyper-V-protected container alongside regular Windows.
The architectural idea was more important than any single policy rule. Instead of assuming that the operating-system kernel could always protect every security mechanism after a deep compromise, Windows could create another boundary beneath it. The component judging whether code deserved to run could be given a protected place from which to make that decision.
