Windows Defender Application Control (WDAC) is the native Windows 10 security feature to control what files can be executed on the desktop. In Windows 1903, Microsoft has added support for file path rules as a basis for whitelisting. Before this, implementing a WDAC policy for the desktop in production was very difficult, almost impractical. File path rules allow applications in the Windows and Program Files folders to run without first specifying what they are. This is one of a series of posts about how to create and implement a WDAC policy for the desktop, with file path rules, and using Intune to deliver it.
Application Control is one of the basic security controls of a desktop. See a previous post, About Windows Defender Application Control, for the background. With an on-premise desktop environment, you have a choice of third party tools. With a cloud desktop environment, you do not. The National Cyber Security Centre (NCSC) platform-specific guidance for Windows 10 also recommend using WDAC, but it is difficult to do.
Before file path support, implementing a WDAC policy for the desktop was almost impractical. A policy was based on a scan of files. Files or publishers not identified in the scan would not be allowed. If any files were changed or added, and not included in the allowed list, then they would not be allowed to run. This could work for a very static system, like a VDI desktop. But for a normal desktop environment it would be difficult to maintain.
With file path rules, we can allow applications in the Program Files and Windows directories, under the assumption that anything there must have been knowingly installed. When we add this to a basic policy with other rules and options, the combined result is stable. It does not need to change frequently, and the part that does change is not the part allowing all of Windows, Microsoft and third party applications to run. We only need to make further whitelisting for the exceptions not covered by this.
The Microsoft documentation is confusing, sometimes incorrect. I will try to explain some of the confusion so you can watch out for it. This post sketches out the overall approach in developing a WDAC policy. Other posts will give the details.
To create and implement a WDAC policy you need the following tools:
- Windows 1903 or later
- PowerShell. A WDAC policy is created entirely in PowerShell.
- Visual Studio Code, or a similar XML editor. This is to inspect the policy files.
- Three devices. Yes, three! One to develop the policy. One standard operating environment (SOE), with all production policies applied, with standard software installed. This is used to test the policy in Audit mode. And a third SOE to test in Enforced mode. AppLocker and WDAC both have the power to make a device unbootable. You absolutely do not want to implement a policy in production unless you have first implemented the exact same policy (at the binary level, not at the conceptual level) in Audit mode to check that it works.
- Event Viewer, for the audit and enforcement events (and whether a policy has been implemented at all) in Applications and Services Logs/Microsoft/Windows/Code Integrity/Operational.
- Ideally, Microsoft Defender Advanced Threat Protection (ATP). You can view Audit and Block events in the ATP cloud reporting service. This is the only way to see, remotely, the impact of the policy. For example, if an application somewhere in your environment has been blocked, you are not going to know unless a) the user reports it to the Service Desk or b) you see it in ATP.
- A work area and a naming convention. It is hard to keep track of policies, versions and changes. A version control system like GitHub is a good way to manage policy files.
The objective is to produce a policy that meets the security requirement, but allows software updates and additions without constant change of the policy.
- Create a basic policy to allow the desktop to run. Microsoft supplies an example policy that contains the identity of all the certificate used to sign all Microsoft products. This component will ensure that Windows can boot. It will also cover Microsoft applications like OneDrive and Teams that run from the user’s AppData Local folder.
- In addition, allow executables in the Windows directory, and in Program Files, by path. This means that we do not need to specify application that run from these locations.
- Enable Intelligent Security Graph (ISG) authorization. ISG is the Microsoft cloud analytics reputation-based service that identifies applications that should be allowed to run. With ISG enabled, there’s a good chance that common applications running outside the specified paths will be allowed to run.
- Block applications that should NOT be allowed to run. Microsoft maintains a list of Windows utilities and PowerShell files that could be used to circumvent WDAC. They provide a policy file to merge with your own policy, to block these.
The steps to achieve this are:
- Create a basic policy to allow the base image to work
- Test it to make sure it works, before we go any further
- Deploy with Intune, to make sure we can deploy successfully
- Create a policy with file path rules
- Merge the basic policy with the file path policy
- Set the options, including ISG
- Deploy in production and monitor with ATP.
Next: Create a Basic WDAC Policy.