Windows Defender Application Control (WDAC) is a complicated security feature to implement on the Windows 10 desktop. It’s worth taking a look at why we need to do it.
“Application Control” is the function of allowing or denying code the ability to run on a device. We know that certain types of code present a risk to data: malware; or applications with known security vulnerabilities. We have different layers of protection to prevent bad code from running. One of these is to inspect executable files at runtime, to determine whether they should be allowed to run or not. Although Application Control can be used to allow or deny, it is simpler here to assume we are talking about identifying the code we allow, while all else is denied (whitelisting).
The Centre for Internet Security (CIS) defines this as one of the Basic CIS Controls: 2. Inventory and Control of Software Assets. “Actively manage (inventory, track, and correct) all software on the network so that only authorized software is installed and can execute, and that all unauthorized and unmanaged software is found and prevented from installation or execution.” Application Control is also part of the UK National Cyber Security Centre (NCSC) platform-specific guidance for Windows 10.
So it is a basic control, and it is probably mandatory if the organisation subscribes to one of the standard set of security guidelines. The problem is that it is quite a large administrative burden. Instead of relying on anti-malware to spot bad code, we have to identify explicitly everything we want to allow. In principle this is fairly easy: Windows; other Microsoft applications; third party applications. But in practice it is quite hard. How do we know the code is genuine, and has not been tampered with? What about updates; or scripts; or user applications? The desktop is not a monolithic block of code with few changes. It is a dynamic structure of constantly changing code.
In a conventional on-premise desktop environment, the business has a choice of third party tools to use for Application Control. I am most familiar with Ivanti Application Control. Using a client server model, these tools track what runs on the desktop, and allow or deny it. But in a cloud environment the choice is limited.
The Software Restriction Policies (SRP) feature was Microsoft’s first implementation of Application Control. I have never used it. AppLocker was the second (introduced with Windows 7). WDAC is the current implementation. WDAC started life as Code Integrity, then became Windows Defender Application Control (WDAC). Now Microsoft is casting Defender as a cross-platform product, and now they call it Microsoft Windows Defender Application Control (WDAC).
Both AppLocker and WDAC can be implemented with Intune, and so work in a cloud-only environment.
AppLocker is moderately easy to implement with Intune. It is clunky but well-documented. WDAC is a significantly more powerful tool. Like AppLocker, it uses Rules to specify what files can be executed. But it also uses Options to control dynamically what can run. Some of the most interesting of these are:
- Drivers. Require all drivers to be Windows Hardware Quality Labs (WHQL) signed, or from a vendor that has an Extended Verification (EV) certificate.
- Intelligent Security Graph (ISG) Authorization. A bit of a mouthful for dynamic reputation-based whitelisting using Microsoft cloud analytics.
- Managed Installer. If the application is installed by the corporate software distribution tool (e.g. SCCM), then the files can be tagged and allowed.
- Supplemental Policies. Allows dynamic merging of a set of policies e.g. a base policy and others for different desktop configurations.
The Microsoft recommendation is to use WDAC in combination with AppLocker. The National Cyber Security Centre (NCSC) recommendation is the same. Why use two? WDAC results in a single allow or deny decision on a computer for a given piece of code. AppLocker results in a decision for a user group. This means that, with AppLocker, you can allow software for one group of users but not others. For example, you could allow scripts in WDAC, but block all script execution for standard users in AppLocker. The AppLocker rules can only be more restrictive. They cannot be less restrictive. This is because the WDAC policy is evaluated first.
The next step is to look at how to Deploy a WDAC Policy.