This post is part of a series focused on Windows Defender Application Control (WDAC). The previous article can be found here:
In this article I’m going to start looking at the XML you use to create policies.
WDAC policies are composed using XML format. You can view a number of example policies on any Windows 10 device by navigating to:
C:\Windows\schemas\CodeIntegrity\ExamplePolicies\
and looking at the file I’ll be starting is process with:
denyallaudit.xml
The first item I want to examine is the Rules block contained within the tags <Rule></Rule> and everything in between as shown above.
Information about the available rules is contained here:
As a best practice, I would suggest the following rule options should be set:
0 Enabled:UMCI – Enabling this rule option validates user mode executables and scripts.
2 Required:WHQL – Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. Kernel drivers built for Windows 10 should be WHQL certified.
3 Enabled:Audit Mode – Instructs WDAC to log information about applications, binaries, and scripts that would have been blocked if the policy was enforced. To enforce the policy rather than just have it log requires removing this option. That will come later in our process, so no now we’ll only be logging results of the policy/
4 Disabled:Flight Signing – WDAC policies will not trust flightroot-signed binaries. This option would be used by organizations that only want to run released binaries, not pre-release Windows builds. In short, we don’t to support Windows Insider builds with our policy.
6 Enabled:Unsigned System Integrity Policy – Allows the policy to remain unsigned. When this option is removed, the policy must be signed and the certificates that are trusted for future policy updates must be identified in the UpdatePolicySigners section.
8 Required:EV Signers – This rule requires that drivers must be WHQL (Windows Hardware Quality Labs) signed and have been submitted by a partner with an Extended Verification (EV) certificate. All Windows 10 and Windows 11 drivers will meet this requirement.
9 Enabled:Advanced Boot Options Menu – Setting this rule option allows the F8 menu to appear to physically present users. This is a handy recovery option but may be a security concern if physical access to the device is available for an attacker.
10 Enabled:Boot Audit on Failure – Used when the WDAC policy is in enforcement mode. When a driver fails during startup, the WDAC policy will be placed in audit mode so that Windows will load.
12 Required:Enforce Store Applications – WDAC policies will also apply to Universal Windows applications.
13 Enabled:Managed Installer – Automatically allow applications installed by a managed installer. For more information, see Authorize apps deployed with a WDAC managed installer
14 Enabled:Intelligent Security Graph Authorization – Automatically allow applications with “known good” reputation as defined by Microsoft’s Intelligent Security Graph (ISG).
15 Enabled:Invalidate EAs on Reboot – When the Intelligent Security Graph (above) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. This option will cause WDAC to periodically revalidate the reputation for files that were authorized by the ISG.
16 Enabled:Update Policy No Reboot – allow future WDAC policy updates to apply without requiring a system reboot.
Since we are going to be modifying the WDAC policy, best practice is to take a copy of the example start point XML file and modify that. Thus, take a copy of:
C:\Windows\schemas\CodeIntegrity\ExamplePolicies\denyallaudit.xml
and use this going forward.
There are two methods of adjusting this new policy. You can directly edit the XML file or you can make the modifications using PowerShell.
To add a policy rule option add the appropriate rule setting encapsulated by <Rule></Rule> and <Option></Option> tags within the <Rules></Rules> global tag like so:
</Rules>
<Rule>
<Option>Enabled:Audit Mode</Option>
<Rule>
</Rule>
and like what is shown above.
You can also make the same updates using PowerShell. The new, copied XML prior to modification appears like:
with five rules. To add the additional rules detailed above use the following:
Set-RuleOption -FilePath “.\newaudit.xml” -Option 0
Set-RuleOption -FilePath “.\newaudit.xml” -Option 2
Set-RuleOption -FilePath “.\newaudit.xml” -Option 3
Set-RuleOption -FilePath “.\newaudit.xml” -Option 4
Set-RuleOption -FilePath “.\newaudit.xml” -Option 6
Set-RuleOption -FilePath “.\newaudit.xml” -Option 8
Set-RuleOption -FilePath “.\newaudit.xml” -Option 10
Set-RuleOption -FilePath “.\newaudit.xml” -Option 12
Set-RuleOption -FilePath “.\newaudit.xml” -Option 13
Set-RuleOption -FilePath “.\newaudit.xml” -Option 14
Set-RuleOption -FilePath “.\newaudit.xml” -Option 15
Set-RuleOption -FilePath “.\newaudit.xml” -Option 16
where newaudit.xml is the policy file being built. The numbers for each option correspond to the:
If you open the XML policy file you should now see all the rule options have been added as shown above (13 in all).
In summary then, we have taken an example policy provided by Microsoft and started to modify it to suit our needs. This modification can either be done by directly editing the XML file or using PowerShell commands. I’d suggest PowerShell is a better way because you can save all the commands together in a script and re-run it if you wish.
With this first modification of the policy complete we’ll next look at how to work with the EKU area in the XML file.
CIAOPS 