Understanding Device Health Attestation
A Correct Password Did Not Mean the Computer Was Healthy
Authentication traditionally concentrated on the person attempting to gain access.
If the username, password, certificate, or other credential was accepted, the service had evidence about the user’s identity. But that answered only one part of a larger security question.
The computer being used could still be compromised.
A Trusted User Can Connect From an Untrusted Device
Identity verification establishes who is requesting access, but it does not automatically establish whether the operating system making that request started in a trustworthy security state.
Access Could Depend on More Than Who Knew the Password
Organizations increasingly needed to consider the condition of the endpoint itself.
A legitimate employee connecting from a properly protected business computer presents a different risk from the same employee connecting from a system whose startup security has been compromised.
The device needed a way to provide evidence about itself.
Identity and Device Health Answer Different Questions
User authentication asks whether the person should be trusted. Device health evaluation asks whether the computer being used satisfies the security conditions required by the organization.
Malicious Code Could Start Before Ordinary Security Software
Some of the most dangerous malware attempts to establish itself very early in the startup process.
If malicious code executes before the operating system and its security products are fully active, it may gain opportunities to hide, interfere with later protections, or manipulate the environment those protections depend upon.
The order of execution matters.
Security Software Cannot Inspect the Past
If an attacker successfully changes an important startup component before normal protection begins, examining only the fully running desktop may not reveal exactly what happened during the earlier stages of boot.
The Firmware Could Refuse Software That Was Not Properly Trusted
UEFI Secure Boot provides a mechanism for checking cryptographic trust during the startup process.
Rather than allowing arbitrary boot components to execute, the platform can verify that software participating in startup satisfies the configured trust requirements.
This makes it harder for unauthorized boot software to establish control before Windows.
Startup Security Begins Before Windows Is Fully Running
Secure Boot moves an important trust decision into the firmware and early boot process, reducing dependence on protections that become available only after the operating system has already started.
An Organization Also Wanted Evidence About What Happened
Blocking untrusted startup software is valuable, but managed environments often need something more.
A remote management system cannot simply look at a computer and observe every stage of its startup sequence. It needs trustworthy information that can be evaluated remotely.
This is where measured boot becomes important.
Preventing and Measuring Are Different Security Functions
Secure Boot helps control which startup components are allowed to execute, while measured boot creates evidence about components and security conditions encountered during startup.
Important Components Could Leave Cryptographic Measurements Behind
During measured boot, Windows and the platform can record measurements associated with important portions of the startup process.
These measurements are not ordinary descriptive log entries written only for a human administrator. They participate in a cryptographic trust system designed to make the resulting evidence useful for security evaluation.
The boot process leaves a measurable history.
Measured Boot Does Not Mean Recording a Video of Startup
The system records cryptographic measurements representing important startup components and security state rather than storing a visual or complete byte-for-byte recording of everything the computer did.
The Measurements Needed Somewhere More Trustworthy Than an Ordinary File
If startup measurements were stored only in a normal file, malware controlling Windows could potentially alter that file and claim that the computer had started correctly.
The Trusted Platform Module provides hardware-backed capabilities that can protect and report measurements associated with the platform’s security state.
The evidence gains protection outside ordinary storage.
The Reporter Should Be Harder to Tamper With Than the System Being Reported
TPM-backed measurements help reduce reliance on ordinary operating-system data that sufficiently privileged malware might otherwise rewrite before a remote management service evaluates it.
Startup Events Could Change Protected TPM Values
The TPM contains Platform Configuration Registers commonly referred to as PCRs.
During startup, measurements can be extended into these registers. The process is designed so that the resulting values depend on the sequence of measurements that contributed to them.
A different startup sequence can therefore produce different resulting evidence.
The Final Value Reflects More Than One Event
PCR measurements are extended rather than simply overwritten, allowing the resulting state to represent a chain of measured startup information instead of one freely replaceable value.
A Modified Boot Path Could Produce a Different Measurement
Suppose an important component involved in startup is altered.
The cryptographic measurement associated with that component can differ from the expected value. Because measurements contribute to protected TPM state, the difference can become visible when the device later reports its health.
Tampering can leave evidence even when the machine still boots.
Working Normally Does Not Mean Starting Normally
A compromised computer may still display a familiar desktop and allow applications to open, so visible functionality alone is not sufficient evidence that its startup security state is trustworthy.
The Computer Could Report Its Security State to Someone Else
Measurements become especially useful when they can be evaluated outside the computer that produced them.
Remote attestation allows security information rooted in the device’s TPM to be presented to another system. That external system can then evaluate the reported state rather than simply accepting the endpoint’s unsupported claim that everything is healthy.
Trust can be evaluated remotely.
The Computer Had to Provide Evidence, Not Just an Answer
Attestation is valuable because the endpoint can present hardware-backed security information that another service can evaluate instead of relying only on a software-controlled statement saying the device is secure.
Raw TPM Information Could Be Converted Into Useful Security Assertions
TPM measurements are technically valuable but can be complicated for every management product to interpret independently.
Microsoft’s Health Attestation service could process measured-boot information and produce simpler security assertions about the device’s state.
Management systems could consume those results without implementing every detail of TPM measurement analysis themselves.
Attestation Could Answer Practical Security Questions
Microsoft describes its Health Attestation service as capable of parsing measured-boot information into security assertions that management systems can use when evaluating device health.
Encryption Could Become Part of the Health Decision
Organizations may require managed computers to protect stored information with drive encryption.
A device that normally uses BitLocker but reports that encryption is disabled may no longer satisfy corporate security policy even if the user entering the credentials is legitimate.
Health evaluation can include conditions beyond malware detection.
Healthy Means Meeting the Organization’s Requirements
Device health can include security configuration such as encryption and startup protections rather than being limited to the narrower question of whether antivirus software currently reports a known infection.
A Device With Startup Protection Disabled Could Be Treated Differently
Secure Boot contributes to protecting the early startup chain.
If an organization expects Secure Boot to be active, a device that does not satisfy that requirement can represent a different risk profile. Health information gives management systems a way to incorporate that difference into policy.
Configuration becomes part of trust.
A Security Feature Being Installed Is Not the Same as It Being Active
Managed security should consider whether required protections are actually enabled and operating rather than assuming that a capable computer is automatically configured according to policy.
Diagnostic Configurations Could Change the Security State
Low-level debugging features are valuable during development and troubleshooting.
Those same capabilities can alter the assumptions under which a tightly managed production device is considered secure. An organization may therefore choose to treat certain debugging configurations as inconsistent with normal endpoint policy.
Health attestation can help surface security-relevant startup conditions.
A Useful Engineering Setting May Be an Unwanted Production Setting
Security posture depends partly on context. Features appropriate for diagnosing a laboratory system may not satisfy the requirements imposed on a computer handling protected business information.
Windows Did Not Need One Universal Definition of Healthy
Different organizations have different security requirements.
A hospital, financial institution, school, small business, and software-development laboratory may reasonably impose different rules on their computers. Device Health Attestation provides evidence that management systems can use as part of those organization-specific decisions.
The policy remains under administrative control.
Attestation Supplies Evidence Rather Than Business Policy
The security information reported about a device can be interpreted by management systems according to the requirements of the organization deciding whether that device should receive access.
Mobile Device Management Could Evaluate Windows Computers Before Trusting Them
Windows 10 expanded enterprise management beyond traditional domain-based administration.
Mobile Device Management systems could participate in evaluating device health information and applying policy. This made attestation useful in environments where devices were managed through modern management infrastructure rather than only conventional local or domain controls.
Remote management gained security evidence.
Management Systems Did Not Need to Interpret Every TPM Detail
Microsoft designed the Health Attestation service so MDM solutions could consume simplified security assertions and use them when determining whether a client satisfied required health conditions.
Correct Credentials Did Not Have to Guarantee Full Access
Once device health becomes part of access policy, organizations gain more choices than simply accepting or rejecting the user’s password.
A management system can potentially restrict an unhealthy device, require remediation, quarantine it from sensitive resources, or refuse access until required protections return to an acceptable state.
The endpoint has to earn trust too.
Access Can Depend on User Plus Device
A legitimate account can be denied access from a computer that does not satisfy security policy, allowing organizations to separate identity trust from endpoint trust.
Device Health Could Influence Access Beyond the Local Network
Business resources increasingly existed outside the traditional office network.
Users accessed cloud applications and services from laptops operating in many locations. A health-aware management system could use device security information when determining whether those endpoints should reach protected cloud resources.
The corporate firewall was no longer the only gatekeeper.
The Device Could Carry Its Security Evidence With It
Remote health evaluation supports access decisions for computers outside the physical workplace because trust can be based on reported security state rather than simply on whether the device is connected to an internal network.
Hardware-Backed Evidence Was Harder to Fake Than an Ordinary Setting
A software-only health report has an obvious weakness.
If malware controls the operating system, it may attempt to modify the same files, registry values, services, or application interfaces used to report that the system is healthy. Hardware-backed attestation is designed to make that deception more difficult.
The evidence is rooted below ordinary Windows software.
Never Ask the Suspect to Write Its Own Security Report
Security measurements are more valuable when their integrity does not depend entirely on the operating system whose health is being evaluated.
A Healthy Boot Did Not Prove Nothing Malicious Could Happen Later
Device Health Attestation addresses particular aspects of platform and startup trust.
A computer can start in an acceptable state and later encounter malicious software, a compromised application, stolen credentials, or another attack. Health attestation therefore complements rather than replaces antimalware and other endpoint defenses.
Startup evidence is one layer.
A Good Beginning Does Not Guarantee a Perfect Session
Measured boot provides evidence about startup conditions, but organizations still need defenses against threats that occur after Windows has successfully completed the measured portion of its startup process.
One Could Block While the Other Could Report
The names are similar enough to create confusion.
Secure Boot focuses on enforcing trust during startup by preventing unauthorized boot components from running. Measured Boot focuses on recording security-relevant measurements that can later participate in attestation.
The technologies can work together while performing different jobs.
Secure Boot
Uses platform trust rules to help prevent unauthorized software from participating in the protected startup process.
Measured Boot
Records cryptographic measurements associated with startup so security state can later be evaluated through attestation.
The Same Hardware Could Protect Data and Report Platform State
The TPM supports several Windows security technologies.
BitLocker can use TPM capabilities as part of protecting drive-encryption keys, while measured boot and health attestation use TPM-backed measurements to help establish evidence about the device’s startup state.
One security chip can support different protections.
TPM Is a Platform Security Component Rather Than a Single Feature
The Trusted Platform Module provides hardware-backed cryptographic capabilities that Windows can use for several purposes, including encryption-key protection, device credentials, measured boot, and health attestation.
A Computer That Changed Could Stop Satisfying Policy
Managed devices do not remain static forever.
Firmware settings can change, security features can be disabled, hardware can be serviced, and operating-system configuration can drift from the state originally approved by administrators.
Repeated health evaluation gives organizations a way to notice meaningful security changes.
Trust Does Not Have to Be Permanent
A device that satisfied security requirements yesterday can be evaluated again later rather than retaining unlimited trust after its configuration has changed.
An Unhealthy Device Did Not Necessarily Need to Be Abandoned
Failing a health requirement can indicate a problem without proving that the computer is permanently compromised.
An administrator may be able to restore required configuration, enable a disabled protection, repair startup components, update firmware, or otherwise remediate the system before it is evaluated again.
Health policy can support recovery rather than only punishment.
Restriction Should Lead Toward Remediation
A practical device-health strategy gives users and administrators a path for restoring a computer to an acceptable state so normal access can resume after the underlying security condition is corrected.
Security Was No Longer Only About Proving Who the User Was
Modern access decisions increasingly combine several forms of evidence.
The identity of the user matters. The registration of the device can matter. Its configuration can matter. Its startup measurements can matter. The sensitivity of the requested resource can matter.
Trust becomes contextual.
Access Can Be a Decision Instead of a Password Check
Device health allows organizations to evaluate more than possession of a valid credential and incorporate the security condition of the endpoint into the decision to grant access.
The Server Could Receive Evidence About a Computer It Could Not Physically Inspect
A remote service normally has limited visibility into the physical computer connecting to it.
TPM-backed attestation creates a mechanism for communicating security information rooted in hardware and startup measurements. This gives remote management infrastructure evidence that would be difficult to obtain through an ordinary network connection alone.
The endpoint can make aspects of its platform state externally verifiable.
The computer no longer had to say, “Trust me.” It could provide evidence about how it started.
Device Health Attestation Made Startup Security Part of Access Control
Device Health Attestation extended Windows security beyond protecting the computer locally.
Measured Boot could record security-relevant startup information with help from the TPM, while Microsoft’s attestation infrastructure could convert that information into security assertions useful to management systems. Organizations could then incorporate those results into decisions about whether a device should receive access to protected resources.
The change was important because a valid user credential answered only who was requesting access. Windows 10 increasingly gave organizations a way to ask another question before trusting the connection: did the computer itself provide acceptable evidence about the security state in which it started?
