Swedish Windows Security User Group

The traditional perimeter-based network defense is obsolete. Perimeter-based networks operate on the assumption that all systems within a network can be trusted. However, todays increasingly mobile workforce, the migration towards public cloud services, and the adoption of Bring Your Own Device (BYOD) model make perimeter security controls irrelevant. Networks that fail to evolve from traditional defenses are vulnerable to breaches: an attacker can compromise a single endpoint within the trusted boundary and then quickly expand foothold across the entire network.

In 2013, a massive credit card data breach hit Target and exposed the credit card information of over 40 million customers. Attackers used malware-laced emails to steal credentials from contractors that had remote access to Targets network. They then used the stolen credentials to gain access to the network, effectively evading the perimeter defense mechanisms that Target had in place. Once inside the network, the attackers installed malware on payment systems used in Target stores across the US and stole customer credit card information.

Zero Trust networks eliminate the concept of trust based on network location within a perimeter. Instead, Zero Trust architectures leverage device and user trust claims to gate access to organizational data and resources. A general Zero Trust network model (Figure 1) typically comprises the following:

• Identity provider to keep track of users and user-related information
• Device directory to maintain a list of devices that have access to corporate resources, along with their corresponding device information (e.g., type of device, integrity etc.)
• Policy evaluation service to determine if a user or device conforms to the policy set forth by security admins
• Access proxy that utilizes the above signals to grant or deny access to an organizational resource

Figure 1. Basic components of a general Zero Trust network model

Gating access to resources using dynamic trust decisions allows an enterprise to enable access to certain assets from any device while restricting access to high-value assets on enterprise-managed and compliant devices. In targeted and data breach attacks, attackers can compromise a single device within an organization, and then use the “hopping” method to move laterally across the network using stolen credentials. A solution based on Zero Trust network, configured with the right policies around user and device trust, can help prevent stolen network credentials from being used to gain access to a network.

Zero Trust is the next evolution in network security. The state of cyberattacks drives organizations to take the assume breach mindset, but this approach should not be limiting. Zero Trust networks protect corporate data and resources while ensuring that organizations can build a modern workplace using technologies that empower employees to be productive anytime, anywhere, any which way.

Zero Trust networking based on Azure AD conditional access

Today, employees access their organization’s resources from anywhere using a variety of devices and apps. Access control policies that focus only on who can access a resource is not sufficient. To master the balance between security and productivity, security admins also need to factor in how a resource is being accessed.

Microsoft has a story and strategy around Zero Trust networking. Azure Active Directory conditional access is the foundational building block of how customers can implement a Zero Trust network approach. Conditional access and Azure Active Directory Identity Protection make dynamic access control decisions based on user, device, location, and session risk for every resource request. They combine (1) attested runtime signals about the security state of a Windows device and (2) the trustworthiness of the user session and identity to arrive at the strongest possible security posture.

Conditional access provides a set of policies that can be configured to control the circumstances in which users can access corporate resources. Considerations for access include user role, group membership, device health and compliance, mobile applications, location, and sign-in risk. These considerations are used to decide whether to (1) allow access, (2) deny access, or (3) control access with additional authentication challenges (e.g., multi-factor authentication), Terms of Use, or access restrictions. Conditional access works robustly with any application configured for access with Azure Active Directory.

Figure 2. Microsofts high-level approach to realizing Zero Trust networks using conditional access.

To accomplish the Zero Trust model, Microsoft integrates several components and capabilities in Microsoft 365: Windows Defender Advanced Threat Protection, Azure Active Directory, Windows Defender System Guard, and Microsoft Intune.

Windows Defender Advanced Threat Protection

Windows Defender Advanced Threat Protection (ATP) is an endpoint protection platform (EPP) and endpoint detection response (EDR) technology that provides intelligence-driven protection, post-breach detection, investigation, and automatic response capabilities. It combines built-in behavioral sensors, machine learning, and security analytics to continuously monitor the state of devices and take remedial actions if necessary. One of the unique ways Windows Defender ATP mitigates breaches is by automatically isolating compromised machines and users from further cloud resource access.

For example, attackers use the Pass-the-Hash (PtH) and the Pass the ticket for Kerberos techniques to directly extract hashed user credentials from a compromised device. The hashed credentials can then be used to make lateral movement, allowing attackers to leapfrog from one system to another, or even escalate privileges. While Windows Defender Credential Guard prevents these attacks by protecting NTLM hashes and domain credentials, security admins still want to know that such an attack occurred.

Windows Defender ATP exposes attacks like these and generates a risk level for compromised devices. In the context of conditional access, Windows Defender ATP assigns a machine risk level, which is later used to determine whether the client device should get a token required to access corporate resources. Windows Defender ATP uses a broad range of security capabilities and signals, including:

• Rich machine learning and behavioral detection library
• Exploit protection
• Credential protection
• Application isolation
• Antivirus
• Network protection
• Web protection

Windows Defender System Guard runtime attestation

Windows Defender System Guard protects and maintains the integrity of a system as it boots up and continues running. In the assume breach mentality, its important for security admins to have the ability to remotely attest the security state of a device. With the Windows 10 April 2018 Update, Windows Defender System Guard runtime attestation contributes to establishing device integrity. It makes hardware-rooted boot-time and runtime assertions about the health of the device. These measurements are consumed by Windows Defender ATP and contribute to the machine risk level assigned to the device.

The single most important goal of Windows Defender System Guard is to validate that the system integrity has not been violated. This hardware-backed high-integrity trusted framework enables customers to request a signed report that can attest (within guarantees specified by the security promises) that no tampering of the devices security state has taken place. Windows Defender ATP customers can view the security state of all their devices using the Windows Defender ATP portal, allowing detection and remediation of any security violation.

Windows Defender System Guard runtime attestation leverages the hardware-rooted security technologies in virtualization-based security (VBS) to detect attacks. On virtual secure mode-enabled devices, Windows Defender System Guard runtime attestation runs in an isolated environment, making it resistant to even a kernel-level adversary.

Windows Defender System Guard runtime attestation continually asserts system security posture at runtime. These assertions are directed at capturing violations of Windows security promises, such as disabling process protection.

Azure Active Directory

Azure Active Directory is a cloud identity and access management solution that businesses use to manage access to applications and protect user identities both in the cloud and on-premises. In addition to its directory and identity management capabilities, as an access control engine Azure AD delivers:

• Single sign-on experience: Every user has a single identity to access resources across the enterprise to ensure higher productivity. Users can use the same work or school account for single sign-on to cloud services and on-premises web applications. Multi-factor authentication helps provide an additional level of validation of the user.
• Automatic provisioning of application access: Users access to applications can be automatically provisioned or de-provisioned based on their group memberships, geo-location, and employment status.

As an access management engine, Azure AD makes a well-informed decision about granting access to organizational resources using information about:

• Group and user permissions
• App being accessed
• Device used to sign in (e.g., device compliance info from Intune)
• Operating system of the device being used to sign in
• Location or IP ranges of sign-in
• Client app used to sign in
• Time of sign-in
• Sign-in risk, which represents the probability that a given sign-in isnt authorized by the identity owner (calculated by Azure AD Identity Protections multiple machine learning or heuristic detections)
• User risk, which represents the probability that a bad actor has compromised a given user (calculated by Azure AD Identity Protections advanced machine learning that leverages numerous internal and external sources for label data to continually improve)
• More factors that we will continually add to this list

Conditional access policies are evaluated in real-time and enforced when a user attempts to access any Azure AD-connected application, for example, SaaS apps, custom apps running in the cloud, or on-premises web apps. When suspicious activity is discovered, Azure AD helps take remediation actions, such as block high-risk users, reset user passwords if credentials are compromised, enforce Terms of Use, and others.

The decision to grant access to a corporate application is given to client devices in the form of an access token. This decision is centered around compliance with the Azure AD conditional access policy. If a request meets the requirements, a token is granted to a client. The policy may require that the request provides limited access (e.g., no download allowed) or even be passed through Microsoft Cloud App Security for in-session monitoring.

Microsoft Intune

Microsoft Intune is used to manage mobile devices, PCs, and applications in an organization. Microsoft Intune and Azure have management and visibility of assets and data valuable to the organization, and have the capability to automatically infer trust requirements based on constructs such as Azure Information Protection, Asset Tagging, or Microsoft Cloud App Security.

Microsoft Intune is responsible for the enrollment, registration, and management of client devices. It supports a wide array of device types: mobile devices (Android and iOS), laptops (Windows and macOS), and employees BYOD devices. Intune combines the machine risk level provided by Windows Defender ATP with other compliance signals to determine the compliance status (isCompliant) of the device. Azure AD leverages this compliance status to block or allow access to corporate resources. Conditional access policies can be configured in Intune in two ways:

• App-based: Only managed applications can access corporate resources
• Device-based: Only managed and compliant devices can access corporate resources

More on how to configure risk-based conditional access compliance check in Intune.

Conditional access at work

The value of conditional access can be best demonstrated with an example. (Note: The names used in this section are fictitious, but the example illustrates how conditional access can protect corporate data and resources in different scenarios.)

SurelyMoney is one of the most prestigious financial institutions in the world, helping over a million customers carry out their business transactions seamlessly. The company uses Microsoft 365 E5 suite, and their security enterprise admins have enforced conditional access.

An attacker seeks to steal information about the companys customers and the details of their business transactions. The attacker sends seemingly innocuous e-mails with malware attachments to employees. One employee unwittingly opens the attachment on a corporate device, compromising the device. The attacker can now harvest the employees user credentials and try to access a corporate application.

Windows Defender ATP, which continuously monitors the state of the device, detects the breach and flags the device as compromised. This device information is relayed to Azure AD and Intune, which then denies the access to the application from that device. The compromised device and user credentials are blocked from further access to corporate resources. Once the device is auto-remediated by Windows Defender ATP, access is re-granted for the user on the remediated device.

This illustrates how conditional access and Windows Defender ATP work together to help prevent the lateral movement of malware, provide attack isolation, and ensure protection of corporate resources.

Azure AD applications such as Office 365, Exchange Online, SPO, and others

The executives at SurelyMoney store a lot of high-value confidential documents in Microsoft SharePoint, an Office 365 application. Using a compromised device, the attacker tries to steal these documents. However, conditional access tight coupling with O365 applications prevents this from taking place.

Office 365 applications like Microsoft Word, Microsoft PowerPoint, and Microsoft Excel allow an organizations employees to collaborate and get work done. Different users can have different permissions, depending on the sensitivity or nature of their work, the group they belong to, and other factors. Conditional access facilitates access management in these applications as they are deeply integrated with the conditional access evaluation. Through conditional access, security admins can implement custom policies, enabling the applications to grant partial or full access to requested resources.

Figure 3. Zero Trust network model for Azure AD applications

Line of business applications

SurelyMoney has a custom transaction-tracking application connected to Azure AD. This application keeps records of all transactions carried out by customers. The attacker tries to gain access to this application using the harvested user credentials. However, conditional access prevents this breach from happening.

Every organization has mission-critical and business-specific applications that are tied directly to the success and efficiency of employees. These typically include custom applications related to e-commerce systems, knowledge tracking systems, document management systems, etc. Azure AD will not grant an access token for these applications if they fail to meet the required compliance and risk policy, relying on a binary decision on whether access to resources should be granted or denied.

Figure 4. Zero Trust network model expanded for line of business apps

On-premises web applications

Employees today want to be productive anywhere, any time, and from any device. They want to work on their own devices, whether they be tablets, phones, or laptops. And they expect to be able to access their corporate on-premises applications. Azure AD Application Proxy allows remote access to external applications as a service, enabling conditional access from managed or unmanaged devices.

SurelyMoney has built their own version of a code-signing application, which is a legacy tenant application. It turns out that the user of the compromised device belongs to the code-signing team. The requests to the on-premises legacy application are routed through the Azure AD Application Proxy. The attacker tries to make use of the compromised user credentials to access this application, but conditional access foils this attempt.

Without conditional access, the attacker would be able to create any malicious application he wants, code-sign it, and deploy it through Intune. These apps would then be pushed to every device enrolled in Intune, and the hacker would be able to gain an unprecedented amount of sensitive information. Attacks like these have been observed before, and it is in an enterprises best interests to prevent this from happening.

Figure 5. Zero Trust network model for on-premises web applications

Continuous innovation

At present, conditional access works seamlessly with web applications. Zero Trust, in the strictest sense, requires all network requests to flow through the access control proxy and for all evaluations to be based on the device and user trust model. These network requests can include various legacy communication protocols and access methods like FTP, RDP, SMB, and others.

By leveraging device and user trust claims to gate access to organizational resources, conditional access provides comprehensive but flexible policies that secure corporate data while ensuring user productivity. We will continue to innovate to protect the modern workplace, where user productivity continues to expand beyond the perimeters of the corporate network.

 

 

Sumesh Kumar, Ashwin Baliga, Himanshu Soni, Jairo Cadena
Enterprise & Security

The escalating sophistication of cyberattacks is marked by the increased use of kernel-level exploits that attempt to run malware with the highest privileges and evade security solutions and software sandboxes. Kernel exploits famously gave the WannaCry and Petya ransomware remote code execution capability, resulting in widescale global outbreaks.

Windows 10 remained resilient to these attacks, with Microsoft constantly raising the bar in platform security to stay ahead of threat actors. Virtualization-based security (VBS) hardens Windows 10 against attacks by using the Windows hypervisor to create an environment that isolates a secure region of memory known as secure memory enclaves.

Figure 1. VBS secure memory enclaves

An enclave is an isolated region of memory within the address space of a user-mode process. This region of memory is controlled entirely by the Windows hypervisor. The hypervisor creates a logical separation between the normal world and secure world, designated by Virtual Trust Levels, VTL0 and VT1, respectively. VBS secure memory enclaves create a means for secure, attestable computation in an otherwise untrusted environment.

VBS enclaves in Microsoft SQL Server

A key technology that will leverage VBS secure memory enclaves is Microsoft SQL Server. The upcoming SQL Server secure enclave feature ensures that sensitive data stored in an SQL Server database is only decrypted and processed inside an enclave. SQL Servers use of secure enclaves allows the processing of sensitive data without exposing the data to database administrators or malware. This reduces the risk of unauthorized access and achieves separation between those who own the data (and can view it) and those who manage the data (but should have no access). To learn more about the use of secure enclaves in SQL Server, see the blog post Enabling confidential computing with Always Encrypted using enclaves.

Data protection

One of the major benefits of secure memory enclaves is data protection. Data resident in an enclave is only accessible by code running inside that enclave. This means that there is a security boundary between VTL0 and VTL1. If a process tries to read memory that is within the secure memory enclave, an invalid access exception is thrown. This happens even when a kernel-mode debugger is attached to the normal process the debugger will fail when trying to step into the enclave.

Code integrity

Code integrity is another major benefit provided by enclaves. Code loaded into an enclave is securely signed with a key; therefore, guarantees can be made about the integrity of code running within a secure memory enclave. The code running inside an enclave is incredibly restricted, but a secure memory enclave can still perform meaningful work. This includes performing computations on data that is encrypted outside the enclave but can be decrypted and evaluated in plaintext inside the enclave, without exposing the plaintext to anything other than the enclave itself. A great example of why this is useful in a multi-tenant cloud computing scenario is described in the Azure confidential computing blog post. This move allowed us to continually make significant innovations in platform security.

Attestation

Attestation is also a critical aspect of secure memory enclaves. Sensitive information, such as plaintext data or encryption keys, must only be sent to the intended enclave that must be trusted. VBS enclaves can be put into debug mode for testing but lose memory isolation. This is great for testing, but in production this impacts the security guarantees of the enclave. To ensure that a production secure enclave is never in debug mode, an attestation report is generated to state what mode the enclave is in (among various other configuration and identity parameters). This report is then verified by a trust relationship between the consumer and producer of the report.

To establish this trust, VBS enclaves can expose an enclave attestation report that is fully signed by the VBS-unique key. This can prove the relationship between the enclave and host, as well as the exact configuration of the enclave. This attestation report can be used to establish a secure channel of communication between two enclaves. In Windows this is possible simply by exchanging the report. For remote scenarios, an attestation service can use this report to establish a trust relationship between a remote enclave and a client application.

One feature that relies on secure memory enclave attestation is Windows Defender System Guard runtime attestation, which allows users to measure and attest to all interactions from the enclave to other capabilities, including areas of runtime and boot integrity.

Figure 2. Windows Defender System Guard runtime attestation

Elevating data security

There are many secure memory enclave technologies in the industry today. Each have pros and cons in capabilities. The benefit of using a VBS secure memory enclave is that there are no special hardware requirements, only that the processor supports hypervisor virtualization extensions:

• VBS-capable hardware
• OEM hardware configuration
• Hypervisor protected code integrity (HVCI) compliant drivers

Additionally, VBS enclaves do not have the same memory constraints as a hardware-based enclave, which are usually quite limited.

VBS secure memory enclaves provide hardware-rooted virtualization-based data protection and code integrity. They are leveraged for new data security capabilities, as demonstrated by Azure confidential computing and the Always Encrypted feature of Microsoft SQL Server. These are examples of the rapid innovation happening all throughout Microsoft to elevate security. This isnt the last youll hear of secure memory enclaves. As Microsoft security technologies continue to advance, we can expect secure memory enclaves to stand out in many more protection scenarios.

 

 

Maxwell Renke, Program manager, Windows

Chris Riggs, Principal Program Manager, Microsoft Offensive Security Research

 

At Microsoft, we want users to be in control of their devices, including knowing the security health of these devices. If important security features should fail, users should be aware. Windows Defender System Guard runtime attestation, a new Windows platform security technology, fills this need.

In Windows 10 Fall Creators Update, we reorganized all system integrity features into Windows Defender System Guard. This move allowed us to continually make significant innovations in platform security. Windows Defender System Guard runtime attestation, which is built into the core Windows operating system, will soon be delivered in all editions of Windows. Windows Defender System Guard runtime attestation, like Credential Guard, takes advantage of the same hardware-rooted security technologies in virtualization-based security (VBS) to mitigate attacks in software.

Security technologies are targeted by exploits that attempt to run in the same domain of trust. For example, privileged processes are designed to provide a certain degree of isolation (at least in respect to code and data) from regular user-mode processes. The NT kernel determines whether a process is protected based on certain values held in the executive process object. Tampering with these values via a kernel exploit or with a driver (e.g., Mimikatz) can effectively disable process protection. Moving the security decision related to tampering to a separate domain of trust increases complexity for attackers.

Runtime attestation can help in many scenarios, including:

• Providing supplementary signals for endpoint detection and response (EDR) and antivirus vendors (including full integration with the Windows Defender Advanced Threat Protection stack)
• Detecting artifacts of kernel tampering, rootkits, and exploits
• Protected game anti-cheat scenarios (for example, detection of process-protection bypasses that can lead to game-state modification)
• Sensitive transactions (banking apps, trading platforms)
• Conditional access (enabling and enhancing device security-based access policies)

With the next update to Windows 10, we are implementing the first phase of Windows Defender System Guard runtime attestation, laying the groundwork for future innovation in this area. This includes developing new OS features to support efforts to move towards a future where violations of security promises are observable and effectively communicated in the event of a full system compromise, such as through a kernel-level exploit.

Attestation and establishing trust

To introduce Windows Defender System Guard runtime attestation on a technical level, its best to begin at the most visible layer: a client API that will eventually be exposed to a relying party. (Note: We share details of the general design as its currently architected; final implementation may differ.)

We are working towards providing an API that relying parties can use to attest to the state of the device at a point in time. The API returns a runtime report that details the claims that Windows Defender System Guard runtime attestation makes about the security posture of the system. These claims include assertions, which are runtime measurements of sensitive system properties.

For the runtime report to have any significant meaning, it must be generated in a fashion that provides reasonable resistance against tampering. This gives rise to the following basic component requirements:

1. Runtime report generation must be isolated from an attacker
2. This isolation must be attestable
3. The runtime report must be cryptographically signed in a manner that is irreproducible outside the isolated environment

Enter VBS enclaves. Were not going to describe these enclaves in-depth here, but its prudent to give some context. On a device with virtual secure mode (VSM) enabled, virtualization extensions of the underlying Instruction Set Architecture (ISA) are employed to logically divide the system into two (theoretically, more) separate worlds: the normal world running the NT kernel that were all familiar with and a separate secure world running a Secure Kernel (SK). We call these two logical levels of separation Virtual Trust Levels (VTLs), in this case NT being VTL-0 and SK being VTL-1.

VBS enclaves enable what can be thought of as a siloed part of a normal world VTL-0 user-mode process. All code and data in this silo live in VTL-1. Transactions in and out of an enclave are done via a well-defined API backed by VSL calls (the mechanism that NT and SK use to communicate). The result of this intricacy is that, as of Windows Fall Creators Update (1709), it is possible to execute code and hold data within an enclave such that the entire VTL-0 normal world both user-mode and kernel-mode cannot directly act upon the siloed code and data while executing and held within the enclave (in VTL-1).

From the VBS enclave, the runtime attestation component can observe and attest to a set of security properties contained in a report. For example, an app could ask Windows Defender System Guard to measure the security of the system from the hardware-backed enclave and return a report. The details in this report can be used by the app to decide whether it performs a sensitive financial transaction or display personal information.

VBS enclaves can also expose an enclave attestation report signed by a VBS-specific signing key. If Windows Defender System Guard can obtain proof that the host system is running with VSM active, it can use this proof together with a signed session report to ensure that the particular enclave is running.

As for the signature of the runtime report itself, an asymmetrical public-private key pair is generated within the enclave. The public key is signed by the Windows Defender System Guard attestation service backend to create a session certificate. In addition, the Windows Defender System Guard attestation service backend produces a signed session report containing details about the machine. These details include boot security properties, including whether the machine booted with Secure boot enabled, to ensure that the core operating system has not been jailbroken or tampered with. Finally, runtime reports are signed locally by the paired private key, which never leaves the enclave. The runtime and session reports can be verified by relying parties with little effort by verifying the report signatures against the session certificate and then ensuring that the certificate is validly signed, rooted in the relevant Microsoft CA.

Establishing the trust necessary to guarantee that the runtime report is authentic, therefore, requires the following:

• Attesting to the boot state of the machine: the OS, hypervisor, and Secure Kernel (SK) binaries must be signed by Microsoft and configured according to a secure policy
• Binding trust between the TPM and the health of the hypervisor to allow trust in the Measured Boot Log
• Extracting the VSM IDKs from the Measured Boot Log and using these to verify the VBS enclave signature
• Backend verification of the above and signing of the public component of an ephemeral key-pair generated within the enclave with a trusted CA to issue a session certificate
• Signing of the runtime report with the ephemeral private key

Networking calls between the enclave and the Windows Defender System Guard attestation service are made from VTL-0. However, the design of the attestation protocol ensures that it is resilient against tampering even over untrusted transport mechanisms.

Numerous underlying technologies are required before the chain of trust described above can be sufficiently established. To inform a relying party to the level of trust in the runtime report that they can expect on any particular configuration, a security level is assigned to each Windows Defender System Guard attestation service-signed session report. The security level reflects the underlying technologies enabled on the platform and attributes a level of trust based on the capabilities of the platform. We are mapping the enablement of various security technologies to security levels, and we will share this when the API is published for third-party use. The highest level of trust is likely to require the following features, at the very least:

• VBS-capable hardware + OEM configuration
• Dynamic root-of-trust measurements at boot
• Secure boot to verify hypervisor, NT, SK images
• Secure policy ensuring:

  • Hypervisor-protected code integrity (HVCI)-enforced kernel mode code integrity (KMCI)
  • Test-signing is disabled
  • Kernel debugging is disabled

Measurement

Now that we have explained the trusted report component, let us discuss the contents of the runtime report.

The security level exposed in the session report is an important and interesting metric in and of itself. However, Windows Defender System Guard can provide so much more specifically in respect to runtime measurement of system security posture.

We call this runtime measurement component the assertion engine. The idea is to continually measure assert system integrity at runtime, with the security level attesting to security posture at boot.

Some caveats:

• The assertion engine was designed with the ideal system configuration in mind (i.e., a system configuration with the highest security level)

  • Business needs require Windows Defender System Guard runtime attestation to function on systems even with the lowest security level; Windows Defender System Guard runtime attestation makes no guarantees in this scenario and can act as a signal for other security products on non-locked down editions of Windows

• When running the ideal configuration, non-ROP kernel-mode code execution is difficult due to hypervisor-protected code integrity (HVCI)-enforced kernel mode code integrity (KMCI); in this scenario:

  • Data corruption attacks are more likely
  • It can be assumed that it’s difficult to tamper with any required kernel-mode agents in non-racing scenarios
  • The runtime assertions are therefore targeted at attacks that can reasonably be performed under the most restrictive attack conditions

• We are working to limitations of (current) operating system design

  • We have a deep partnership with other teams in Microsoft and we are work in tandem to improve System Guard runtime attestation and core kernel security features. In the current version of the OS, we rely on NT kernel thread management and the Secure Kernel primitives provided to us.

High-level overview of Windows Defender System Guard runtime attestation architecture

Architecturally, the solution is collectively referred to as the Windows Defender System Guard runtime monitor and consists of the following client-side components:

• The VTL-1 assertion engine itself
• A VTL-0 kernel-mode agent
• A VTL-0 process we call the broker to host the assertion engine

To rapidly respond to threats, we opted for a dynamic scripting approach that will allow us to frequently release updates going forward. We chose an open-source library that met our requirements for maturity, footprint, and performance. This scripting component forms the core of the assertion engine that executes in VTL-1 (if available).

Running arbitrary logic in this engine wouldnt be very useful if it couldnt interact with the system in any way. For the engine to perform useful work, we provide native helpers in the form of assists. These assists are executed in VTL-0 either by the broker service or by a Kernel-mode agent.

In the next update to Windows, assertion logic is delivered in-band (within the signed engine DLL itself). At some point in the future, these scripts will be delivered out-of-band. This is a core part of the design. It enables us to immediately respond to security events (for example, the discovery of new attack invariants) without the need for delivering a component update via servicing. Apps and services can take advantage of this attestation technology to ensure that the system is free from tampering and that critical processes are running as expected. This hardware-rooted proof-of-health can then be used to identify compromised machines or gate access to critical cloud services. Runtime attestation serves as a platform for a wide variety of advanced security applications.

We believe that we can significantly raise the bar for security on locked-down platforms with modern hardware and appropriate security policies. In a world where direct privileged code-execution is difficult, we think that attacks will increasingly leverage data corruption. Transient changes are also a challenge in the current model. However, future innovations will make achieving persistence harder, making transient malicious changes more difficult. The idea is to continually elevate defense across the entire Windows 10 security stack, thereby pushing attackers into a corner where system changes affecting security posture are detectable. One can think of runtime attestation as being more about detecting minute symptoms that can indicate an attack rather than looking for flashing signals.

We are very excited about this technology because of its potential for making significant leaps in platform security. Theres a lot more about Windows Defender System Guard runtime attestation that we did not cover in this blog, for example, the detailed design itself and where we see this technology going. Stay tuned.

 

 

David Kaplan (@depletionmode), Windows Defender ATP Research Team
Adam Zabrocki (@Adam_pi3), Windows Offensive Security Research Team
Rafael Goncalves, Enterprise & Security

 

 

---

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.