Understanding Device Guard and Code Integrity
Traditional Malware Protection Usually Asked Whether a Program Was Bad
Antivirus software historically approached executable files by trying to determine whether something about them indicated malware.
Known signatures, suspicious characteristics, reputation information, and later behavioral techniques could all contribute to that decision. If the security product recognized the threat, it could prevent the program from running or remove it.
The model depended heavily on identifying what should not be trusted.
Most Software Was Allowed Until Something Made It Suspicious
A traditional security model generally permits ordinary applications to execute unless another security mechanism identifies a reason that the particular program should be blocked.
The First Victims Could Encounter a File Before Anyone Had Classified It
Malware changes constantly.
Attackers can modify executable files, create new variants, change packing techniques, and distribute previously unseen programs. Security companies then need to collect samples, analyze them, and update detection systems.
That creates a period in which the malicious file may be new to defenders.
Unknown Does Not Mean Safe
A program that has never been classified as malicious may simply be new. The absence of an existing malware signature is therefore not proof that the software should be trusted.
The Same Threat Could Keep Changing Its Appearance
Some malware deliberately modifies characteristics of its executable representation.
The underlying purpose may remain similar while the binary presented to security products changes. This can make simple exact-signature matching less effective and forces defensive systems to use additional forms of analysis.
The attacker benefits when defenders must recognize every variation.
Changing the File Does Not Require Changing the Attack
Malware can alter portions of its representation while preserving the behavior its operator wants, creating many samples that are related but not necessarily identical.
Instead of Finding Every Bad Program, Windows Could Require Proof That Software Was Trusted
Device Guard introduced a different security model for managed Windows systems.
An organization could define which applications were trusted to execute. Software outside that policy could then be prevented from running rather than receiving permission merely because it had not yet been identified as malware.
The default assumption could become restrictive.
Trust Could Be Required Before Execution
Application control changes the problem from maintaining an endless list of everything malicious to defining the software and publishers an organization has decided should be allowed to run.
Approved Software Could Run While Everything Else Faced a Barrier
An organization generally knows which applications its managed computers are expected to use.
Office software, accounting programs, management tools, line-of-business applications, approved browsers, and signed system components can form a relatively controlled software environment.
That knowledge can become enforceable policy.
A Managed Computer Does Not Need Permission to Run Every Program Ever Created
When a device has a defined business purpose, restricting execution to approved software can remove opportunities that exist when arbitrary applications are permitted by default.
The Publisher Could Matter More Than the Individual Filename
Code signing allows software to carry cryptographic information identifying its publisher and protecting the integrity of the signed content.
Application-control policy can use trusted publishers as part of deciding what software should be allowed. That means an organization does not necessarily need to approve every future version of an application independently when its signing identity is appropriately trusted.
The trust can follow the publisher.
A Signature Provides Identity and Integrity
Code signing can help establish who published software and whether signed content has been altered since signing, giving application-control policy stronger information than a filename alone.
Applications From a Controlled Distribution Channel Could Be Recognized
Windows applications obtained through Microsoft’s controlled application ecosystem carried information that could participate in trust decisions.
Organizations could combine Microsoft-signed software, approved publishers, Store applications, and internally approved code according to their requirements.
The trusted set did not have to come from only one source.
Trust Could Be Defined Around the Organization
Device Guard allowed administrators to establish application-control policies reflecting the software their particular environment expected rather than depending on one universal list suitable for every Windows computer.
A Business Could Trust Its Own Applications
Organizations sometimes depend on custom software that does not arrive from a large commercial publisher.
Application-control deployment therefore needed a way to accommodate internally developed or otherwise approved programs. Organizations could sign software they had chosen to trust and incorporate that trust into policy.
Custom did not have to mean forbidden.
Application Control Requires Knowing the Environment
Before restrictive policies are enforced, administrators need an accurate inventory of legitimate applications, scripts, installers, drivers, and business tools required by the computers being protected.
Windows Could Check Software Before Allowing It to Become Executable
Code integrity is responsible for determining whether code satisfies the requirements established by Windows and configured policy.
With Device Guard, those decisions could extend beyond basic operating-system requirements and incorporate an organization’s application-control rules.
Execution itself became conditional.
Blocking Before Execution Is Different From Cleaning Up Afterward
If untrusted code never receives permission to execute, security software does not have to wait for the program to begin performing malicious actions before attempting to contain the damage.
A Malicious Driver Could Operate With Extraordinary Privilege
Drivers run in highly privileged portions of Windows.
A malicious or improperly trusted kernel driver can therefore create much more serious consequences than an ordinary restricted application. Driver-signing and code-integrity requirements help reduce the opportunity for arbitrary kernel code to load.
Device Guard extended the larger trusted-code philosophy into this security model.
Kernel Access Changes the Stakes
Code executing in the Windows kernel can interact with critical memory and operating-system resources, making strict control over which drivers are allowed to load an important security requirement.
What If Malware Already Controlled a Powerful Account?
Application-control policy is valuable only if attackers cannot simply rewrite the rules after obtaining administrative privileges.
Traditional operating-system security boundaries become much more difficult to defend when malicious code gains control at a highly privileged level. Windows therefore needed stronger isolation for some of the decisions determining whether code could execute.
Virtualization offered another boundary.
The Judge Should Not Live Beside the Attacker
If malware can freely modify the component responsible for deciding whether malware is trusted, application control becomes far less meaningful. Protecting the decision mechanism itself is therefore part of the security design.
The Hypervisor Could Separate Code Integrity From Ordinary Windows
Windows 10 could use Hyper-V virtualization technology to establish a protected security environment alongside the normal operating system.
Code-integrity functions could operate within that virtualization-based boundary, making them harder for malware in ordinary Windows to manipulate even after the malware obtained substantial privileges.
The security decision gained separation from the environment being judged.
Device Guard Could Use Hardware-Enforced Isolation
Microsoft designed Device Guard so virtualization-based security could isolate important code-integrity decision-making from the regular Windows operating system and strengthen protection against privileged attackers.
The Hypervisor Could Become a Security Tool
Virtual machines traditionally allow several operating systems to share one physical computer while remaining separated.
Windows 10 applied the same fundamental isolation technology internally. A protected security environment could coexist with ordinary Windows without presenting the user with another desktop or conventional virtual machine.
Hardware virtualization became part of endpoint security.
One Computer Could Contain Different Trust Zones
Virtualization-based security uses hardware-assisted isolation to create boundaries within a single physical Windows device, allowing sensitive security functions to operate separately from the normal operating-system environment.
Kernel Memory Should Not Become Arbitrary New Code
One dangerous condition occurs when memory can be modified and then immediately treated as executable kernel code.
Virtualization-protected code integrity can enforce stronger rules around executable kernel memory so that code must satisfy integrity checks before it is permitted to execute.
This restricts another route attackers might use after gaining privileged access.
Changing Memory Should Not Create Trusted Kernel Code
Preventing arbitrary writable kernel memory from becoming executable helps preserve the distinction between data an attacker may manipulate and code the operating system has approved to run.
Being New Was No Longer Enough to Avoid the Policy
A newly created malicious executable may not match any known malware signature.
Under a restrictive application-control policy, however, the relevant question is not whether security software recognizes the program as malicious. The program must satisfy the organization’s trust policy before it can execute.
Novelty provides less advantage.
Zero-Day Malware Can Still Be Untrusted Software
An application-control system can block a previously unseen malicious program because the program lacks approved trust, even when no security vendor has yet created a signature identifying that exact file as malware.
The Encryptor Had to Run Before It Could Encrypt Anything
Ransomware ultimately requires executable instructions to perform its work.
If the malicious program arrives on a tightly controlled computer but does not satisfy the application-control policy, blocking execution can interrupt the attack before the ransomware begins processing the user’s files.
The defensive decision occurs early in the chain.
Prevention Can Be Simpler Than Recovery
Preventing unauthorized code from starting avoids the far more difficult problem of restoring encrypted files, rebuilding compromised systems, and determining what additional actions the malware performed after execution.
Application Control Was Not Limited to EXE Files
Attackers do not need to rely entirely on traditional executable programs.
Scripts and other interpreted content can provide another path for performing unauthorized actions. Enterprise application-control strategies therefore need to consider script execution in addition to conventional binaries and drivers.
Trusted code includes more than one file type.
Blocking Unknown Executables While Allowing Every Script Leaves Another Door Open
A complete application-control strategy considers the various mechanisms through which Windows can execute instructions rather than treating only conventional executable files as potentially active code.
Administrators Needed to Learn What Would Break Before Enforcing the Rules
A restrictive application policy can be extremely effective and extremely disruptive if configured incorrectly.
Computers often run background utilities, update components, scripts, drivers, and business applications that administrators may overlook during initial planning. Immediately blocking anything missing from policy can therefore interrupt legitimate work.
Observation should come before enforcement.
Measure Before You Block
Running application-control policy in an auditing or evaluation phase allows administrators to identify legitimate software that would be affected before converting the policy into an enforced production restriction.
Knowing What the Business Actually Used Was No Longer Optional
Application control requires an organization to understand its legitimate software environment.
That includes obvious desktop applications as well as less visible components such as scheduled tools, administrative scripts, installers, plug-ins, services, drivers, and software-update mechanisms.
An accurate inventory makes restrictive trust possible.
You Cannot Define Trusted Software Without Knowing What Needs to Run
Application inventory turns an operational question into a security requirement because missing legitimate software from policy can interrupt work while unnecessarily broad rules can weaken the protection.
Today’s Approved Application Would Eventually Change
Software is not static.
Vendors release security fixes, feature updates, and new versions. An application-control strategy must therefore allow legitimate maintenance without forcing administrators to rebuild policy manually for every routine update.
Publisher-based trust can help solve that problem.
Trust the Right Identity at the Right Scope
Publisher rules can simplify legitimate software updates, but excessively broad trust can also permit more software than intended. Policy design needs to balance maintainability with restriction.
Trusted Identity Could Be Abused
Digital signatures strengthen application control, but they are not magic.
If an attacker obtains access to a trusted publisher’s signing key, malicious software may be signed in a way that appears to come from that trusted identity. Certificate revocation and careful trust-policy design therefore remain important.
The trust system must protect its roots.
Signed Does Not Automatically Mean Safe
A digital signature establishes information about identity and integrity. Whether that identity should be trusted to run arbitrary code is a separate policy decision.
A Business Computer Could Have Different Rules From a Personal PC
A personal computer may legitimately run an unpredictable variety of applications selected by its owner.
An enterprise workstation often has a much narrower purpose. Administrators may know exactly which software employees need and can therefore impose restrictions that would be inconvenient on a general-purpose personal system.
The environment determines whether strict application control is practical.
Open Software Model
Users can install and execute a broad range of applications, providing flexibility but giving unauthorized software more opportunities to run.
Controlled Software Model
Administrators define the trusted software environment and prevent applications outside that policy from executing.
Application Trust Could Be Stronger Than an Ordinary Permission Check
Administrator privileges remain extremely powerful and should be protected carefully.
But Device Guard’s use of virtualization-based security was intended to strengthen code-integrity enforcement beyond a model that depended entirely on ordinary Windows privilege separation.
The hypervisor could help protect the mechanism making trust decisions.
Administrative Power and Application Trust Are Different Questions
A user or process having broad control over normal Windows does not necessarily mean every arbitrary binary should automatically become trusted code under a virtualization-protected application-control architecture.
Trust Needed to Start Before the Desktop
An application-control policy is less meaningful if attackers can compromise the system before Windows security mechanisms are established.
UEFI Secure Boot helps verify components involved in the startup process so untrusted boot software cannot simply take control before the operating system begins enforcing its protections.
Application trust therefore connects to platform trust.
Security Built Later Depends on What Started Earlier
Boot integrity helps establish a trustworthy foundation for operating-system protections that depend on the system reaching a known security state before ordinary applications begin running.
The Processor Was Helping Decide What Software Deserved to Run
Windows security increasingly relied on capabilities below the application layer.
Processor virtualization extensions, firmware protections, Secure Boot, and related platform features could help establish and isolate the environment used for sensitive security decisions.
Malware defense was no longer purely an antivirus-software problem.
The Security Boundary Could Extend Into the Hardware
Virtualization-based security demonstrates how processor and firmware capabilities can help protect operating-system security mechanisms from software operating within the ordinary Windows environment.
Trusted Software Could Still Contain Vulnerabilities
Application control answers whether software is authorized to execute.
It does not guarantee that every approved application is perfectly secure. A trusted browser, document reader, or business program may contain a vulnerability that an attacker attempts to exploit.
Other defensive layers remain necessary.
Allowed Does Not Mean Invulnerable
Application control reduces unauthorized execution, while antimalware, exploit mitigations, patching, browser protection, and other security technologies address threats that can arise within software the organization legitimately allows.
One Feature Controlled What Started While Another Protected How Programs Executed
Several Windows 10 security technologies can sound similar because they all attempt to make exploitation more difficult.
Control Flow Guard protects certain indirect control-flow transitions inside compatible running programs. Device Guard’s application-control model determines whether software satisfies trust policy before it is permitted to execute.
The names are similar; the security jobs are not.
Device Guard
Uses application-control and code-integrity policy to restrict execution to software that satisfies defined trust requirements.
Control Flow Guard
Helps protect compatible applications against certain memory-corruption exploits by validating protected indirect control-flow destinations.
Trusted Execution and Protected Credentials Could Share the Same Isolation Idea
Credential Guard uses virtualization-based security to isolate selected authentication secrets.
Device Guard used related virtualization concepts to strengthen code-integrity enforcement. The protected assets were different, but both reflected a larger Windows 10 security strategy: move important security functions away from ordinary operating-system memory and protect them with stronger isolation.
The hypervisor became a reusable defensive boundary.
One Isolation Technology Could Protect Different Security Assets
Virtualization-based security could support multiple protections because the fundamental capability was separation from the normal Windows environment, whether the protected asset involved credentials or code-integrity decisions.
Blocking Malware and Blocking Payroll Software Could Look Identical to the Computer
An application-control engine follows policy rather than understanding business priorities.
If an essential application is accidentally omitted, the system can correctly enforce the policy and still create a serious operational problem. Deployment therefore requires testing, inventory, change management, and a recovery plan.
Strong controls need careful administration.
A Perfectly Enforced Bad Policy Is Still a Bad Result
Application control should be introduced methodically because restrictive rules can interrupt legitimate software just as effectively as they interrupt malware.
The Best Time to Stop Malware Could Be Before Its First Instruction
Once malicious software begins executing, defenders face a more difficult situation.
The malware may attempt to alter files, steal credentials, disable security software, establish persistence, communicate across the network, or exploit additional vulnerabilities. Preventing execution removes those opportunities before they begin.
Application control moves the decision earlier.
No Execution Means No Malicious Behavior From That Program
A malicious binary prevented from starting cannot perform the actions contained in its code, making pre-execution trust enforcement a fundamentally different defensive position from detecting damage after the program is already active.
Absence From a Malware Database Was No Longer the Important Test
Device Guard represented a significant change in perspective.
Instead of assuming that software could execute until defenders proved it malicious, managed Windows systems could be configured around software the organization had deliberately chosen to trust.
The burden shifted toward authorization.
The program did not have to be recognized as malware if the computer already knew it was not authorized to run.
Device Guard Turned Software Trust Into an Execution Requirement
Device Guard gave organizations a way to approach malware from the opposite direction.
Rather than depending entirely on identifying every malicious file, administrators could define trusted applications, publishers, drivers, and other approved code. Windows code-integrity enforcement could then prevent software outside that policy from executing, while virtualization-based security could provide stronger isolation for important integrity decisions.
Antivirus, patching, exploit mitigation, and careful administration remained necessary. But the fundamental idea was powerful: a completely new malicious program did not necessarily need to be recognized as malicious. If the computer had never been given a reason to trust it, that alone could be enough to refuse execution.
