WDAC policy for Lightly managed device¶
| Base policy type | Method used | Signed | Protection score 1-5 |
|---|---|---|---|
| Signed and Reputable (ISG) | WDACConfig module | No / Yes | 3.5 / 4 |
flowchart TD
A(Deploy WDAC base policy with ISG) -->B(Start using your apps)
B --> C(Did your app run without problem?)
C -->|Yes| D[Awesome]
C -->|No| E[Create a Supplemental policy for it]
Video Guide¶
Every time I use the word "App", I'm referring to regular Win32 programs as well as Microsoft Store installed apps; Basically any software that you can run.
This scenario provides a high protection level, higher if you cryptographically Sign it. Using the WDACConfig module, it's very easy to deploy, manage and maintain a system with this configuration.
Deploy the Signed and Reputable base policy on the system¶
Start by deploying the Signed and Reputable base policy on the system, which allows only files and apps that are authorized by the Intelligent Security Graph Authorization which have known good state to run and anything else is blocked.
Unsigned version¶
Signed version¶
Deploy-SignedWDACConfig -CertPath "C:\Certificate.cer" -PolicyPaths "C:\Users\HotCakeX\SignedAndReputable.xml" -CertCN "WDAC Certificate" -Deploy
-
The module creates Signed and Reputable WDAC base Policy based on AllowMicrosoft policy template with ISG related rule options, then merges Microsoft recommended block rules with it. We don't merge Microsoft recommended driver block rules because it is already enabled by default in Windows.
-
The module also automatically starts the Application Identity (
AppIDSvc) service required for ISG Authorization and sets its startup mode to Automatic. It's a protected service so can't be disabled or modified using Services snap-in. -
ISG Authorization requires active Internet connection to communicate with the global ISG network.
-
Recommended to perform a reboot regardless of whether you are deploying signed or unsigned version of the "Signed and Reputable" WDAC base policy.
After finishing deploying the Signed and Reputable base policy, if there is an app that is getting blocked and you want to allow it, you can create Supplemental policies to expand your base policy. To do that, you have multiple options.
Creating Supplemental policy for apps already installed¶
The following commands use the -Deploy optional switch parameter, meaning after Supplemental policy creation, they are automatically deployed on the system.
- If you chose the Signed path, omit it from the commands and instead use the Deploy-SignedWDACConfig cmdlet to Sign and Deploy the Supplemental policy xml files.
Based on signer rules, hashes, file names etc.¶
New-SupplementalWDACConfig -Normal -ScanLocation "C:\Program Files\Program" -SuppPolicyName "App's Name" -PolicyPath "C:\SignedAndReputable.xml" -Deploy
Based on File path with one or more wildcard characters¶
New-SupplementalWDACConfig -FilePathWildCards -WildCardPath "C:\Program Files\Program\*" -SuppPolicyName "App's Name" -PolicyPath
"C:\SignedAndReputable.xml" -Deploy
Based on an installed Windows app's name¶
New-SupplementalWDACConfig -InstalledAppXPackages -PackageName "*App's name*" -SuppPolicyName "App's name" -PolicyPath "C:\SignedAndReputable.xml" -Deploy
Creating Supplemental policy for new app installations or apps already installed¶
If the app you are trying to allow isn't installed, and when you try to install it you see a blocked/error message, you can use the following syntaxes to allow them to run and then automatically create Supplemental policy for them.
These methods also work for apps that were installed prior to deploying the "Signed and Reputable" base policy and now you want to allow them to run by creating Supplemental policy for them.
You can create a Supplemental policy for more than 1 app at a time by browsing for multiple apps' install directories using the commands below.
Based on App's install directory and Event viewer logs - Unsigned version¶
Edit-WDACConfig -AllowNewAppsAuditEvents -SuppPolicyName "App's Name" -PolicyPath "C:\SignedAndReputable.xml" -LogSize 20MB
Based on App's install directory only - Unsigned version¶
Based on App's install directory and Event viewer logs - Signed version¶
Edit-SignedWDACConfig -AllowNewAppsAuditEvents -CertPath "C:\Certificate.cer" -SuppPolicyName "App's Name" -PolicyPath "C:\SignedAndReputable.xml" -CertCN "WDAC Certificate" -LogSize 20MB
Based on App's install directory only - Signed version¶
Edit-SignedWDACConfig -AllowNewApps -CertPath "C:\Certificate.cer" -SuppPolicyName "App's Name" -PolicyPath "C:\SignedAndReputable.xml" -CertCN "WDAC Certificate"
What to Do if You Have a Lot of Supplemental Policies?¶
Currently, the limit for the number of policies (Base + Supplemental) that can be deployed on a system at a time is 32. So if you are getting close to that limit, you can merge some or all of your Supplemental policies automatically into 1 using the command below:
Unsigned version¶
Edit-WDACConfig -MergeSupplementalPolicies -SuppPolicyName "Merge of Multiple Supplementals" -PolicyPath "C:\SignedAndReputable.xml" -SuppPolicyPaths "C:\Supplemental policy for App1.xml","C:\Supplemental policy for App 2.xml","C:\Supplemental policy for App 3.xml"
Signed version¶
Edit-SignedWDACConfig -MergeSupplementalPolicies -CertPath "C:\Certificate.cer" -SuppPolicyName "Merge of Multiple Supplementals" -PolicyPath "C:\SignedAndReputable.xml" -CertCN "WDAC Certificate" -SuppPolicyPaths "C:\Supplemental policy for App1.xml","C:\Supplemental policy for App 2.xml","C:\Supplemental policy for App 3.xml"
Security Considerations¶
One of the differences between using ISG in a WDAC policy vs using Smart App Control (which also use ISG) is that WDAC policy + ISG rule option passes along reputation from app installers to the binaries they write to disk, it can over-authorize files in some cases. For example, if the installer launches the app upon completion, any files the app writes during that first run will also be allowed.
Smart App Control however doesn't do this, it will trust the installer file itself if it's trustworthy and subsequently checks the trustworthiness of any binaries the installer tries to use and write to the disk, if any of those binaries or components can't be verified or are malicious, they get blocked.
Explained more in here:
What to Do When There Is an Update for an Allowed App?¶
If you've created a Supplemental policy for an app that is already installed and now there is a newer version of that app available, you have multiple options:
-
If the Supplemental policy that you created to allow that app is based on FilePath with wildcards, then the app can be updated and no change in policy is required.
-
If the Supplemental policy is based on PFN (Package Family Name) of the app, available only for apps that use MSIX installers, like some of the modern apps installed through Microsoft Store, then you don't need to take any action and the app will be updated without any issues.
-
If the Supplemental policy is only based on the app's digital signature, which is common for well-made apps, then you don't need to take any further action. As long as the new version of the app has the same digital signature / developer identity, then it will be allowed to run.
-
If the Supplemental policy is based on individual File Paths (in contrast to wildcard FilePath rules), or based on FileName rules, then most likely there is no need for any further action to be taken as long as the new app's version uses the same file names or the same file paths for its components.
-
If the Supplemental policy is based on Hash of the app's files, either partially (mixed with signer rules) or entirely (for apps without any digital identity/signature) then all you have to do is to remove the deployed Supplemental policy and create a new Supplemental policy for the app using live audit mode in the module as explained above. Don't need to reboot immediately, but to finish the removal process of a Supplemental policy, whether it's signed or unsigned, a reboot will be eventually needed.