How do I block all apps and allow only certain apps using WDAC ?

Configuring Windows Defender Application Control (WDAC) to allow certain apps like Adobe Reader and Google Chrome while blocking all others can be a bit tricky, especially if you're trying to maintain a separate whitelist policy. The process involves creating and deploying a WDAC policy that explicitly allows these applications and blocks others. If you've attempted to create a Supplemental policy and it hasn't worked as expected, let's walk through some steps to troubleshoot and achieve your goal.
Step 1: Verify Policy Configuration
Base Policy: Ensure your base policy is configured to block by default. This serves as your primary policy layer, where you define the default behavior (block all apps).

Supplemental Policy: Your supplemental policy should explicitly list the applications you want to allow, such as Adobe Reader and Google Chrome.

Step 2: Create Allow Entries for Specific Apps
For your supplemental policy where you want to allow specific applications, ensure you're including the correct information. This typically involves:

File Path Rules: Allow apps based on their file paths. This is straightforward but less secure, as attackers could potentially place malicious software in the allowed paths.
Publisher Rules: More secure than file paths, publisher rules allow applications signed by a specific publisher. This requires obtaining the signing certificate information for Adobe Reader and Google Chrome.
Hash Rules: These rules allow specific versions of an application based on their file hash. This is very secure but requires updating the policy for each new app version.
Step 3: Merge Policies Correctly
If you're managing a base policy and a supplemental policy separately, ensure they are correctly linked or merged. The supplemental policy should be referenced correctly in the base policy or deployed alongside it in a way that they work in tandem.

Step 4: Use PowerShell to Create and Deploy Policies
Here's a simplified overview of how you might use PowerShell to create and deploy these policies:

Generate the Base Policy (if not already created):
New-CIPolicy -Level PcaCertificate -FilePath "C:\Path\To\BasePolicy.xml" -UserPEs

Generate Supplemental Policy for Allowlisting:

Identify the applications' publisher information or hashes.
Use New-CIPolicyRule to create rules for your applications.
Create the supplemental policy with New-CIPolicy using the rules generated.

Merge Policies (if necessary):
Merge-CIPolicy -OutputFilePath "C:\Path\To\MergedPolicy.xml" -PolicyPaths "C:\Path\To\BasePolicy.xml", "C:\Path\To\SupplementalPolicy.xml"

Convert to Binary Format (if deploying via Group Policy or SCM):
ConvertFrom-CIPolicy -XmlFilePath "C:\Path\To\FinalPolicy.xml" -BinaryFilePath "C:\Path\To\FinalPolicy.bin"

Deploy the Policy:
You can deploy the policy through Group Policy, SCCM, but first start by manually testing it on a LAB machine.
Place the file in a secure and accessible location on the LAB machine, such as C:\Windows\System32\CodeIntegrity\CiPolicies\Active\

Set the Policy as Active: In most cases, simply placing the policy file in the Active directory and restarting the device will activate the policy. However, to explicitly set a policy as active without relying on the automatic process, use the following PowerShell command:
Add-SignerRule -FilePath "C:\Windows\System32\CodeIntegrity\CiPolicies\Active\YourPolicy.bin" -Kernel -UserPEs
This step is more about adding specific signer rules to an existing policy, but for setting a policy active manually, ensuring it's in the correct directory and recognized by the system at startup is typically sufficient.
After deploying the policy, you can verify that it's active by using the following PowerShell command:
Get-CIPolicyInfo -FilePath "C:\Windows\System32\CodeIntegrity\CiPolicies\Active\YourPolicy.bin"
This command will provide information about the policy, helping you confirm it's correctly deployed and active.
Restart the target machine to ensure the WDAC policy is fully loaded and enforced by the system.
Before deploying a restrictive policy in a production environment, test it thoroughly in a controlled setting to ensure it doesn't inadvertently block essential applications or system processes.
I recently had a client blue screen all their devices, making them non bootable. Be extra careful with WDAC!



Disclaimer: Make sure to do this in a LAB and not in production. I am not responsible for bricking all your devices. 😃