-
Notifications
You must be signed in to change notification settings - Fork 142
WDAC policy for Fully managed device Variant 3
Base policy type | Method used | Signed | Protection score 1-5 |
---|---|---|---|
Allow Microsoft | WDACConfig module | Yes | 4.5 |
flowchart TD
A(Deploy Allow Microsoft Signed base policy) -->B(Identify Important apps that need Supplemental policy)
B --> C[Create Supplemental policy based on App's directory]
C --> D[Want to allow an entire directory?]
D --> E[New-SupplementalWDACConfig -FilePathWildCards]
E --> AA[Deploy-SignedWDACConfig]
C --> F[Want to Scan the app's install directory?]
F --> G[New-SupplementalWDACConfig -Normal]
G --> AB[Deploy-SignedWDACConfig]
B --> H[Is it a game Installed using Xbox app?]
H --> I[Or Is it an app that installs drivers outside app's directory?]
I --> J[Edit-SignedWDACConfig -AllowNewApps]
Note
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 very high protection level. Using the WDACConfig module, it's very easy to deploy, manage and maintain a system with this configuration.
Start by creating the Allow Microsoft base policy xml file, which allows only files and apps that are signed by Microsoft's trusted root certificate.
New-WDACConfig -PolicyType AllowMicrosoft
Now what we have the policy xml file for the Allow Microsoft base policy, we need to sign and deploy it.
Deploy-SignedWDACConfig -CertPath "C:\Certificate.cer" -PolicyPaths "C:\AllowMicrosoftPlusBlockRules.xml" -CertCN "App Control Certificate" -Deploy
Since this is a signed base policy, you need to perform a reboot after deployment so that the anti-tamper protection of a signed base policy will start.
After deploying the base policy, you can create Supplemental policies to allow other apps that aren't signed by Microsoft's trusted root certificate to run. To do that, you have multiple options.
If you deployed the Allow Microsoft base policy on a system that already had apps installed, you can create Supplemental policy for them using the following syntaxes. After creating each Supplemental policy, you need to sign and deploy it using the same Cmdlet we used above.
New-SupplementalWDACConfig -Normal -ScanLocation "C:\Program Files\Program" -SuppPolicyName "App's Name" -PolicyPath "C:\AllowMicrosoftPlusBlockRules.xml"
New-SupplementalWDACConfig -FilePathWildCards -WildCardPath "C:\Program Files\Program\*" -SuppPolicyName "App's Name" -PolicyPath
"C:\AllowMicrosoftPlusBlockRules.xml"
New-SupplementalWDACConfig -InstalledAppXPackages -PackageName "*App's name*" -SuppPolicyName "App's name" -PolicyPath "C:\AllowMicrosoftPlusBlockRules.xml"
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 Allow Microsoft 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.
Edit-SignedWDACConfig -AllowNewApps -CertPath "C:\Certificate.cer" -SuppPolicyName "App's Name" -PolicyPath "C:\AllowMicrosoftPlusBlockRules.xml" -CertCN "App Control Certificate"
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.
- App Control for Lightly Managed Devices
- App Control for Fully managed device - Variant 1
- App Control for Fully managed device - Variant 2
- App Control for Fully managed device - Variant 3
- App Control for Fully managed device - Variant 4
- App Control Notes
- How to Create and Deploy a Signed App Control Policy
- Fast and Automatic Microsoft Recommended Driver Block Rules updates
- App Control policy for BYOVD Kernel mode only protection
- EKUs in App Control for Business Policies
- App Control Rule Levels Comparison and Guide
- Script Enforcement and PowerShell Constrained Language Mode in App Control Policies
- How to Use Microsoft Defender for Endpoint Advanced Hunting With App Control
- App Control Frequently Asked Questions (FAQs)
- New-SupplementalWDACConfig
- Remove-WDACConfig
- Edit-WDACConfig
- Edit-SignedWDACConfig
- Deploy-SignedWDACConfig
- Confirm-WDACConfig
- New-DenyWDACConfig
- Set-CommonWDACConfig
- New-KernelModeWDACConfig
- Get-CommonWDACConfig
- Remove-CommonWDACConfig
- Assert-WDACConfigIntegrity
- Build-WDACCertificate
- Test-CiPolicy
- Get-CiFileHashes
- Get-CIPolicySetting
- Create Bootable USB flash drive with no 3rd party tools
- Event Viewer
- Group Policy
- How to compact your OS and free up extra space
- Hyper V
- Overrides for Microsoft Security Baseline
- Git GitHub Desktop and Mandatory ASLR
- Signed and Verified commits with GitHub desktop
- About TLS, DNS, Encryption and OPSEC concepts
- Things to do when clean installing Windows
- Comparison of security benchmarks
- BitLocker, TPM and Pluton | What Are They and How Do They Work
- How to Detect Changes in User and Local Machine Certificate Stores in Real Time Using PowerShell
- Cloning Personal and Enterprise Repositories Using GitHub Desktop
- Only a Small Portion of The Windows OS Security Apparatus
- Rethinking Trust: Advanced Security Measures for High‐Stakes Systems
- Clean Source principle, Azure and Privileged Access Workstations
- How to Securely Connect to Azure VMs and Use RDP
- Basic PowerShell tricks and notes
- Basic PowerShell tricks and notes Part 2
- Basic PowerShell tricks and notes Part 3
- Basic PowerShell tricks and notes Part 4
- Basic PowerShell tricks and notes Part 5
- How To Access All Stream Outputs From Thread Jobs In PowerShell In Real Time
- PowerShell Best Practices To Follow When Coding
- How To Asynchronously Access All Stream Outputs From Background Jobs In PowerShell
- Powershell Dynamic Parameters and How to Add Them to the Get‐Help Syntax
- RunSpaces In PowerShell
- How To Use Reflection And Prevent Using Internal & Private C# Methods in PowerShell