Understanding Device Guard and Code Integrity
Traditional Security Usually Asked Whether a Program Looked Dangerous
Antivirus protection traditionally approached software from the perspective of detection.
A program arrived on the computer, security software examined it, and the system attempted to determine whether something about the file indicated malware. Signatures, reputation information, behavioral analysis, and other techniques could contribute to that decision.
The basic assumption was that software could run unless there was a reason to distrust it.
Detection Begins With an Open Door
When unknown applications are generally permitted to execute, security software carries the difficult responsibility of identifying the dangerous ones before they can cause harm.
A New Malicious File Might Not Yet Have a Reputation
Malware authors can modify executable files continually.
A new sample may contain different bytes, use different packaging, or otherwise avoid matching signatures created for an earlier version. Security vendors respond by analyzing new threats and updating detection systems, but the attacker may already have another variation available.
This creates a continuing race between recognition and change.
Unknown Does Not Mean Safe
A file that has never been classified as malicious may simply be new. Absence from a malware database cannot by itself establish that the software should be trusted.
Instead of Finding Every Bad Program, Windows Could Define the Good Ones
Device Guard approached the problem from another direction.
An organization could create a code integrity policy defining which software it trusted. Applications that satisfied that policy could run, while software outside the approved trust model could be prevented from executing.
The default relationship with unknown software could therefore change.
Trust Could Become a Requirement Rather Than an Assumption
Application control reduces dependence on identifying every possible malicious file by restricting execution to software that satisfies an organization’s defined trust policy.
Trust Could Follow the Publisher Instead of One Particular File
Enterprise software changes constantly.
If every application update required administrators to approve a completely new file manually, maintaining an allow policy could quickly become impractical. Code-signing information provides another way to establish trust.
An organization can trust software based on who signed it and the policy rules applied to that publisher.
A Signature Can Represent a Trust Relationship
Publisher-based rules can allow appropriately signed software from an approved source to continue working across updates without treating every new binary as unrelated software.
Microsoft Did Not Have to Decide Every Application an Organization Trusted
Different organizations run different software.
A hospital, engineering company, school, bank, and manufacturing facility may each have specialized applications that would make a universal list of approved programs impossible. Device Guard therefore allowed organizations to define policies appropriate to their own environment.
Trust became an administrative decision.
Enterprise Trust Is Environment Specific
An application can be legitimate software and still be inappropriate on a tightly controlled workstation if the organization has no operational reason for that application to execute there.
Untrusted Kernel Code Could Be More Dangerous Than an Ordinary Application
Kernel-mode drivers operate with extensive privileges.
If malicious or improperly modified code enters the kernel, it can affect fundamental operating-system behavior and potentially interfere with security controls operating above it. Device Guard therefore included code-integrity protection for drivers and system components as well as application-control capabilities.
Trust needed to extend below the desktop.
Kernel Access Changes the Consequences
Code executing in the Windows kernel operates across a much more privileged boundary than an ordinary user application, making integrity enforcement at that level particularly important.
An Administrator Could Be Powerful Without Being Allowed to Rewrite Security Policy
Traditional Windows security gives administrators extensive control over the operating system.
That becomes dangerous when malware gains administrative privileges. If the same compromised operating system can freely modify the mechanism deciding which kernel code is trusted, the attacker may simply weaken the protection before loading malicious code.
Windows needed somewhere stronger to protect the decision.
Administrator Is Powerful but Should Not Mean Omnipotent
Modern Windows security increasingly separates certain critical protections from the ordinary operating-system environment so compromising an administrator account does not automatically provide control over every security boundary.
The Hypervisor Could Separate Critical Security Work From Normal Windows
Hardware virtualization is commonly associated with running virtual machines.
Windows 10 also used virtualization technology for security. Virtualization-based security creates an isolated environment separated from the normal operating system by the hypervisor.
Important security functions can operate across that stronger boundary.
The Operating System Could Have a Neighbor It Could Not Freely Control
Virtualization-based security uses the hypervisor to isolate selected security functionality from ordinary Windows, reducing what malware inside the main operating-system environment can directly manipulate.
The Decision About Trusted Kernel Code Did Not Have to Live Beside the Code Being Judged
Hypervisor-protected code integrity uses virtualization-based security to strengthen enforcement of kernel code integrity.
The security logic and relevant state can be protected from the normal Windows kernel environment. This means malware that compromises the operating system faces an additional boundary when attempting to alter the rules controlling trusted kernel code.
The judge is harder for the defendant to reach.
Isolation Protects the Decision Maker
Moving sensitive code-integrity functionality behind a virtualization boundary makes it more difficult for malicious software operating in normal Windows to tamper directly with the mechanism enforcing kernel trust.
Virtualization-Based Security Depended on More Than an Operating-System Setting
The hypervisor needs processor and firmware capabilities to create and maintain isolated execution environments.
Compatible virtualization extensions, firmware configuration, and other platform security features therefore influence whether a computer can provide the strongest Device Guard protections.
Software cannot manufacture missing processor features.
Two Computers Running the Same Windows Version Can Have Different Security Capabilities
Hardware generation, firmware configuration, Secure Boot support, and virtualization capabilities can determine which virtualization-based protections are available on a particular machine.
The Hypervisor Needed a Startup Environment It Could Trust
A virtualization boundary provides limited security if malicious firmware or boot software gains control before that boundary is established.
Secure Boot helps protect the startup chain by verifying trusted boot components before Windows loads. Device Guard deployments could combine this hardware-backed startup protection with virtualization-based security and code-integrity policies.
The protection depended on layers supporting one another.
Isolation Is Stronger When the Foundation Is Verified
Secure Boot helps establish confidence in the components responsible for starting Windows and its hypervisor before virtualization-based security begins protecting higher-level security functions.
The Rules Themselves Needed Protection From Modification
A policy is useful only while attackers cannot simply rewrite it.
Device Guard code integrity policies could be signed, helping protect them from unauthorized modification or removal. This is particularly important when the objective is to resist attackers who may already possess substantial privileges inside Windows.
The rulebook becomes a protected object.
Protecting the Policy Is Part of Enforcing the Policy
A strong application-control design must consider not only which software is permitted to run but also who or what is capable of changing those permissions after deployment.
Everything Outside the Approved Set Could Be Refused
An allow-based policy creates a fundamentally different security posture from ordinary malware blocking.
Rather than permitting arbitrary applications until one is identified as dangerous, the system can limit execution to software that matches trusted rules. Unknown executables therefore encounter a barrier even when no antivirus signature identifies them as malware.
The unknown program has to prove trust.
Traditional Detection
Software generally runs unless security technology identifies a reason to block it as malicious or suspicious.
Application Control
Software runs when it satisfies the organization’s trust policy, allowing unknown or unauthorized applications to be rejected by default.
A Threat Did Not Need a Known Signature to Be Unapproved
A zero-day threat may exploit a vulnerability or use malware that security vendors have not yet cataloged.
Traditional detection can be challenged when the malicious file is new. An allow-based code-integrity policy asks a different question: does this software satisfy the rules required for execution?
Novelty does not automatically provide permission.
Unknown Malware Can Still Be Unknown and Blocked
When a tightly controlled system permits only approved software, an unfamiliar malicious executable can fail the trust policy without the security product needing to recognize the exact malware family first.
Changing the File Did Not Automatically Create a Trusted Publisher
Polymorphic malware changes its representation to make signature matching more difficult.
That technique can create large numbers of distinct malicious files. But changing bytes does not inherently cause those files to satisfy an organization’s code-integrity policy.
Application control attacks the permission problem rather than the resemblance problem.
A Different Hash Does Not Create Authorization
Malware can alter its binary representation repeatedly, but an allow policy can continue rejecting those variations when they do not meet the organization’s established trust rules.
Application Control Was Not Limited to Traditional EXE Files
Enterprise attacks do not always depend on launching a conventional executable.
Scripts and other forms of code can also perform powerful actions. Device Guard’s broader code-integrity strategy allowed organizations to consider these execution paths when establishing which code should be trusted.
The executable boundary was broader than a filename extension.
Blocking Unknown Programs Is Not Enough if Another Interpreter Can Run Their Instructions
A strong application-control policy needs to account for the different mechanisms through which code can execute rather than assuming every threat arrives as a standalone EXE file.
Organizations Needed to Discover What Their Computers Actually Used
A strict allow policy can break legitimate software when administrators overlook an application, driver, or component required for normal operation.
For that reason, application-control deployment benefits from observation before full enforcement. Administrators can examine what software is being used and refine policies before turning every unrecognized item into a blocked event.
Security policy needs operational knowledge.
Learn the Environment Before Locking It
Testing and auditing help identify legitimate dependencies so application control can be strengthened without unexpectedly disabling software required by users or business processes.
Not Every Legitimate Program Came From a Major Software Publisher
Organizations frequently use applications written internally or supplied by specialized vendors.
These programs may not have the same signing and distribution practices as widely deployed commercial software. Administrators therefore need policies capable of representing the software their particular environment genuinely requires.
A secure allow list must still permit the business to operate.
Application Control Is a Management Project as Well as a Security Feature
The technical ability to block untrusted code is only part of deployment. Organizations also need an accurate understanding of legitimate software, publishers, updates, and operational dependencies.
A Good Policy Needed to Survive Normal Software Maintenance
Applications evolve through patches and upgrades.
A policy built too narrowly around individual file hashes may require frequent maintenance whenever legitimate software changes. Publisher and signing rules can provide a more durable trust relationship when the organization’s security requirements allow them.
Policy design affects maintenance burden.
Trust Rules Need the Right Level of Precision
Rules that are too broad can permit unwanted software, while rules that are too narrow can create unnecessary administrative work whenever approved applications receive legitimate updates.
A Digital Signature Identified a Publisher but Did Not Prove Perfect Behavior
Code signing helps establish software identity and integrity.
It does not guarantee that the program contains no vulnerability, that the publisher’s signing process can never be compromised, or that every signed application is appropriate for every organization.
Trust policy still requires judgment.
Signed and Approved Are Different Decisions
A valid signature can provide evidence about who published software and whether the signed content changed, while an organization’s policy determines whether that publisher or application should actually be trusted to execute.
A Previously Trusted Signing Identity Could Become Untrustworthy
Security relationships can change.
A signing certificate may be compromised, software may later be discovered to contain malicious behavior, or an organization may decide that a publisher should no longer be trusted. Application-control management therefore cannot be treated as permanent after initial deployment.
Trust has a lifecycle.
Yesterday’s Approval Does Not Guarantee Tomorrow’s Permission
Organizations need mechanisms for updating code-integrity policy when software, publishers, certificates, or security requirements change.
Application Control Deliberately Reduced Freedom on Managed Computers
A tightly controlled enterprise computer is not designed to behave like an unrestricted personal machine.
If users can download and execute arbitrary software, the organization loses much of the security benefit provided by an allow-based model. Device Guard therefore fit environments where administrators intentionally wanted stronger control over what could run.
Restriction was part of the design.
Convenience and Control Pull in Opposite Directions
The more freedom users have to execute arbitrary software, the harder it becomes to maintain a strict application-control boundary. Managed environments choose where that balance should sit.
Blocking Unauthorized Code and Detecting Malicious Activity Solved Different Problems
Application control is powerful, but no security mechanism covers every attack path.
Trusted applications can contain vulnerabilities. Authorized tools can be abused. Documents and scripts can create additional execution paths. Antivirus and behavioral security technologies therefore remain useful even when application control is deployed.
The protections complement one another.
Application Control
Restricts which code is authorized to execute according to the organization’s trust policy.
Antimalware
Examines files and activity for evidence associated with malicious behavior, including threats that may appear through otherwise permitted software paths.
Virtualization-Based Security Could Protect More Than Code Integrity
Windows 10 also used virtualization-based security for Credential Guard.
Instead of protecting code-integrity decisions, Credential Guard isolates valuable authentication secrets such as NTLM hashes and Kerberos credentials from the ordinary Windows environment. Malware running in the operating system can therefore face a hypervisor-enforced boundary when attempting to steal those secrets.
The underlying isolation concept supported different security objectives.
One Isolation Technology Could Protect Different Assets
Virtualization-based security provides a protected environment that Windows can use for sensitive operations and secrets rather than leaving every critical security function directly exposed to the normal operating system.
The Processor Was Helping Enforce Software Trust
Historically, many operating-system protections depended primarily on software privilege levels.
Virtualization-based security extended the architecture by using processor virtualization and the hypervisor to create an isolation boundary beneath ordinary Windows. That allowed selected security functions to rely on a layer malware inside the normal kernel could not simply treat as another Windows component.
The hardware was participating in the trust decision.
Security Could Move Below the Operating System It Was Protecting
When critical enforcement operates behind a hypervisor-controlled boundary, compromising the ordinary Windows environment does not necessarily give an attacker equivalent control over the isolated security environment.
Drivers Had to Behave Correctly Under Stronger Integrity Rules
Low-level software written without modern security requirements in mind could encounter compatibility problems when stronger code-integrity protections were enabled.
Organizations therefore needed to test hardware drivers and critical applications before widespread deployment. A security technology that prevents essential equipment from operating can create pressure to disable the protection entirely.
Testing protects both security and availability.
Old Drivers Can Become a Security Deployment Problem
Legacy hardware may depend on drivers that are incompatible with modern code-integrity requirements, making driver inventory and testing important before enabling strict virtualization-based protections across an organization.
The Same Windows Installation Could Behave Differently on Another Motherboard
Replacing a motherboard can change firmware, Secure Boot configuration, TPM availability, and processor virtualization capabilities.
Those changes can affect whether virtualization-based protections can operate as expected. After major hardware service, security configuration should therefore be verified rather than assuming every previous capability remains unchanged.
Hardware repair can influence operating-system security.
Verify Security Features After Major Hardware Changes
Following motherboard replacement or firmware reset, confirm the intended virtualization, Secure Boot, and related platform-security settings before returning a managed computer to service.
Software Failure Did Not Always Mean Windows Was Broken
When application control is enforcing a restrictive policy, software outside that policy may fail to launch by design.
A user may report that an application suddenly stopped working even though the executable itself is intact. Security logs and code-integrity events can help distinguish deliberate policy enforcement from damaged software or operating-system corruption.
The symptom needs context.
Check Policy Before Reinstalling the Program
If an application fails on a managed Windows computer, review application-control and code-integrity events before assuming that reinstalling the software will solve the problem.
The Computer Could Begin From Distrust Instead of Permission
Device Guard represented a broader change in enterprise Windows security.
Rather than depending entirely on discovering malicious software after it appeared, administrators could establish a known set of trusted code and restrict execution around that definition. Virtualization-based security could then strengthen parts of the enforcement architecture against tampering from the operating system being protected.
Trust became something software had to earn.
The Unknown Program No Longer Needed to Be Proven Malicious
In a properly configured allow-based environment, software can be refused because it lacks authorization, eliminating the need to establish that every blocked file is already known malware.
The Strongest Decision Could Be Refusing to Guess
Traditional malware detection has to make judgments about enormous numbers of files and behaviors.
Application control offers another strategy for computers whose software requirements are predictable. If the organization knows what should run, everything else can begin outside the trust boundary until an administrator deliberately approves it.
The system does not have to gamble on the unknown.
A computer with a defined job does not necessarily need permission to run every program someone manages to place on it.
Device Guard Changed the Default From Unknown to Unapproved
Device Guard brought application control, code-integrity policy, and virtualization-backed protection together as part of Windows 10’s enterprise security strategy.
Organizations could define which applications and publishers they trusted rather than relying exclusively on identifying malicious software after it appeared. Virtualization-based security could protect critical code-integrity enforcement from ordinary Windows, making policy harder for a compromised system to undermine.
The important change was philosophical as much as technical: software did not need to be proven malicious before the computer had a reason to refuse it. It could simply fail to meet the rules required to be trusted.
