WDAC is a security based technology designed to harden the operating system through a process of whitelisting code that runs in the operating system kernel. This means that applications and services have to gain trust before they are allowed to run which limits the attack surface of the Windows Operating System. This can be especially useful to know that if something is not explicitly allowed to run on Windows it will be blocked and can help block threats such as malware.
WDAC is a very big topic so I’ve highlighted a few things here that are useful and also from some recent experiences supporting the product.
Know your business requirements and a strategy to deploy WDAC
With any technology, the question is “Why” do you want to implement this? You should read Microsoft’s documentation to understand the product and how to deploy this.
There several ways to whitelist applications in WDAC. This can be done via the following methods:
For a complete list and more information see here
Audit vs Enforced Mode
Audit Mode allows you to turn on the WDAC policy and review what would of been blocked if you had used enforced mode. You can review the code integrity logs to confirm if any further binaries should be allowed in the existing policy
Enforced Mode, the WDAC policy is on and will only allow the applications that have been whitelisted. Be careful in Enforcing policies without testing, this can impact functionality of devices and applications.
More details here
Single vs Multi format Policies
Since Windows 1903 Microsoft has introduced a new standard of Multi-Format policies. With this you can use a base policy and supplementary policies
Where can this be helpful?
The base policy may simply be the Windows OS and the supplementary policies may be 3rd party applications
More details here
Kernel Mode vs User Mode Code Integrity
WDAC Policies can be configured to protect applications that run in both Kernel and User Mode, Applications run in user mode, and core operating system components run in kernel mode, some drivers can run in both modes.
See the differences between Kernel Mode and User Mode
User mode and kernel mode – Windows drivers | Microsoft Docs
Windows Defender Application Control and virtualization-based code integrity (Windows 10) – Windows security | Microsoft Docs
Multiple deployment tools and methods
WDAC can be deployed different tools such as Intune, Microsoft Endpoint Configuration Manager (MECM) and Powershell.
There are differences in some of the deployment options and with Intune and MECM so I would advise to read some of the documentation provided by Microsoft. In Intune and MECM you can turn on basic functionality of WDAC that gives you some additional attack surface reduction.
When deploying any policies with WDAC always ensure you first set the policy to Audit so that their are no unintended consequences such drivers, applications or services being blocked which could impact your End User Computing (EUC)
The audit events are captured in the CodeIntegrity event logs at:
Applications and Services Log > Microsoft > CodeIntegrity
Deployment Method – PowerShell
Specific PowerShell commandlets can be used to create a WDAC Policy. This is a very powerful way to create policies and ensure that you are fully in control of what is whitelisted and trusted to be run in the Windows Kernel. This will take more planning up front and should be aligned with your strategy to know exactly applications, services and binaries should be explicitly allowed to run. If you are using single based policy format then you can deploy the policy using Group Policy, if you are using the multiple based polices you will need to find an alternative method to deploy the policy to the intended devices. This method is likely to be used by either experienced admins or by organizations that have very detail strategies on what is required to run.
Deployment Method – Intune
For Intune deployments you have a couple of options here for deploying WDAC
- Device Configuration Profiles
This was the traditional way in Intune to deploy settings to devices. You can simply turn on WDAC from here but I will highlight a few things here that you should be aware of.
a. Ensure the policy is initially set to audit to avoid any unexpected blocks
b. You will notice the link to the documentation in the above screenshot Learn more about Windows Defender Application Control, this takes you to the home page for Application Control for Windows
This is the landing page for all the documentation for WDAC, ideally you would want to be taken to this page that is very specific to the configuration for Intune because we want to know what the Configured, Audit and Enforce settings actually do, before we discuss in more depth lets look at the 2nd way to deploy WDAC from Intune.
2. Endpoint Security – Attack Surface Reduction (ASR)
You can also turn on WDAC here but as you will notice there are a few options related to SmartScreen.
So now we know the options to deploy the WDAC from Intune lets point out a few things in the documentation that are very useful to know before deploying it in Enforce mode
What do these settings do?
The description below shows how WDAC enforces attack surface reduction, this is known as Intune’s built-in policies which are configured in a single-based format
Intune supports both built-in policies and multiple-based policies and there are 2 key statements in this documentation you should be aware of, ensure you understand that the built-in policies require a restart when adding policies. The newer multiple-based policies can be applied without a reboot
The statements below also confirm that single and multiple-based policies use different CSPs in Intune
Last point here, make sure you are aware of the following statement:
If you have unintentionally set Enforce and impacted your environment then you can switch back to Audit to resolve the issue, Lets look at this in more depth…
When you deploy WDAC and use the single-based policy format (with any of the deployment methods) an SIPolicy.p7b is deployed to 2 areas of the Windows Operating System, they are:
Although you can turn the policy to Audit to stop policies applying you can also fully remove them with a little PowerShell
Remove the SIPolicy.p7b from the C:\Windows\System32\Codeintegrity
$CIPolicyPath = ‘C:\Windows\System32\CodeIntegrity\SiPolicy.p7b’
If (Test-Path $CIPolicyPath)
Remove the SIPolicy.p7b from the Windows EFI Partition
$SiPolicy = “B:\EFI\Microsoft\Boot\sipolicy.p7b”
mountvol B: /S
If (Test-Path $SiPolicy)
Test and use the script at your own risk
These blogs and channels below are very helpful