With the Windows 10 May 2019 Update we delivered several important features for Windows Defender Application Control (WDAC), which was originally introduced to Windows as part of a scenario called Device Guard. WDAC works in conjunction with features like Windows Defender Application Guard, which provides hardware-based isolation of Microsoft Edge for enterprise-defined untrusted sites, to strengthen the security posture of Windows 10 systems.
Our focus for this release was responding to some longstanding feedback on manageability improvements. We’re excited to introduce the following new capabilities in Windows Defender Application Control:
- File path rules, including optional runtime admin protection checks
- Multiple policy file support with composability
- Application Control CSP to provide a new, richer MDM policy management capability
- COM object registration support in policy
- Disabling script enforcement rule option
Application control is frequently identified as one of the most effective mitigations against modern security threats, because anything that’s not allowed by policy is blocked from running. Even striving towards a simple policy like mandating that only signed code is allowed to execute can be incredibly impactful: in a recent analysis of Windows Defender ATP data, we saw that 96% of malware encountered is unsigned. Systems like Windows 10 in S mode, which uses WDAC technology to enforce that all code must be signed by Windows and Microsoft Store code signing certificates, have no malware infection issues.
The new capabilities are designed to ease the journey for customers adopting application control in real-world environments with large numbers of applications, users, and devices.
File path rules, including optional runtime admin protection checks
For many customers looking to adopt application execution control while balancing IT overhead, rules based on file paths on managed client systems provide a useful model. The Windows 10 May 2019 Update introduces support for both allow and deny rules based on file path in Windows Defender Application Control.
File path rules had been one of the few features available in AppLocker, the older native application control technology, that were not available to WDAC; deployment tools and methodologies built on top of AppLocker like AaronLocker have relied on these rules as an important simplifying option for policy management. As we sought to close that gap, we wanted to preserve the stronger security posture available with WDAC that customers have come to expect. To this end, WDAC applies, by default, an option to check at runtime that apps and executables allowed based on file path rules must come from a file path that’s only writable by administrator or higher privileged accounts. This runtime check provides an additional safeguard for file path rules that are otherwise inherently weaker than other identifiers like hash or signer rules, which rely on cryptographically verifiable attributes.
This runtime capability can be controlled with the “Disabled:Runtime FilePath Rule Protection” rule option.
The following example shows how to easily create rules for anything allowed under “Program Files” and “Program Files (x86)”, and then merge them with the sample policy that allows all Windows signed code (available under C:\Windows\schemas\CodeIntegrity\ExamplePolicies). The resulting merged policy file allows all Windows signed code and applications installed under “Program Files” and “Program Files (x86)” with the runtime protection that checks that anything executing under those paths is coming from a location only writable by administrator or higher privileged accounts.
Multiple policy file support with composability
Limiting support to a single policy file means that a variety of app control scenarios from potentially different stakeholders or business groups need to be maintained in one place. This comes with an associated overhead: the coordination required to converge on the appropriate rules encapsulated in a single policy file.
With the Windows 10 May 2019 Update multiple policy files are supported for WDAC. To facilitate composing behavior from multiple policy files, we have introduced the concept of base and supplemental policies:
- Base policies – For any execution to be allowed, the application must pass each base policy independently. Base policies are used together to further restrict what’s allowed. For example:
Let’s assume a system has two policies: Base Policy A and Base Policy B with their own sets of rules. For foo.exe to run, it must be allowed by the rules in Base Policy A and also the rules in Base Policy B. Windows Defender Application Control policies on prior Windows 10 systems will continue to work on the May 2019 Update and will be treated as base policies.
- Supplemental policies – As the name suggests, supplemental policies complement base policies with additional rules to be considered as part of the base policies they correspond to. Supplemental policies are tied to a specific base policy with an ID; a base policy may have multiple supplemental policies. Supplemental policies expand what is allowed by any base policy, but deny rules specified in a supplemental policy will not be honored.
Application Control CSP
Customers have been able to deploy Windows Defender Application Control policies via MDM using the CodeIntegrity node of the AppLocker configuration service provider (CSP). The AppLocker CSP has a number of limitations, most notably the lack of awareness of rebootless policy deployment support.
The Windows 10 May 2019 Update now has a new Application Control CSP, which introduces much richer support for policy deployment over MDM and also provides support for:
- Rebootless policy deployment (For policies that have the “Enabled:Update Policy No Reboot” option set, the new Application Control CSP will not schedule a reboot on client systems getting the policy)
- Support for the new multiple policies
- For device management software vendors, better error reporting
COM object registration support
Windows Defender Application Control enforces a built-in allow list of COM object registrations to reduce the risk introduced from certain powerful COM objects. Customers have reported that while this capability is desirable from a security perspective, there are specific cases in their environments where they’d like to allow the registration of additional COM objects required for their business.
With the Windows 10 May 2019 Update customers can now specify COM objects that need to be allowed in environments they’re managing with Windows Defender Application Control policies.
Disabled: Script Enforcement rule option support
The Windows 10 May 2019 Update with KB4497935 introduces proper support for the Disabled: Script Enforcement rule option.
Customers recognize the importance of having restrictions on script hosts but are often looking to break up their application control projects into smaller chunks to help with deployment feasibility. The “Disabled:Script Enforcement” rule option in the policy now turns off policy enforcement for MSIs, PowerShell scripts, and wsh-hosted scripts. This will allow IT departments to tackle EXE, DLL, and driver enforcement without needing to also simultaneously address script host control.
Try the new capabilities today
We invite everyone to try these new Windows Defender Application Control capabilities, alongside existing features like managed installer. For customers using Microsoft Defender ATP, consider using Advanced hunting to query the WDAC events centrally to understand and monitor the behavior of all these new policy controls on client machines in your environment. Learn about both new and existing functionalities with the Windows Defender Application Control deployment guide.
We’re also working on supplementing the documentation we have out now. Stay tuned for updates from our team for tools and guidance on GitHub that provide more practical examples and ready-to-use scripts.
Senior Program Manager, Windows Defender Application Control team