A Windows Defender Application Control (WDAC) policy uses Options to control aspects of how it works. The options are binary choices: Enabled or Disabled; Required or Not Required. This post explains the choices.
The Options are listed here: Understand WDAC policy rules and file rules. The descriptions are fairly clear, so I will not repeat them. This post is about making the choice to use them or not.
Slightly confusingly (at least to me!), you either Set an option, or you Delete it. “Set” means that the option is literally put into the XML policy file. “Delete” means that it is literally removed from the file. If you set the option, then it takes the value when set, which may be Enabled, or it may be Disabled. Therefore the actual default value (if you don’t Set it, or if you Delete it) is whatever is the opposite of the Set value.
To add to the confusion, a policy created with New-CIPolicy has four options set automatically. These are:
- Option 3: Enabled:Audit Mode
- Option 6: Enabled:Unsigned System Integrity Policy
- Option 9: Enabled:Advanced Boot Options Menu
- Option 12: Required:Enforce Store Applications
Confused? These are not the default values (i.e. the value of the option if you don’t set it) but they are the default options set when you create a new policy.
Also, when you create a new policy, the options are not listed in numerical order. When you set an option, it is added to the end of the list of rules, not in numerical order. So you need to look at the rules carefully to make sure you have set what you want.
Depending on exactly what you need, a standard set of options for a desktop environment might be: 0, 2, 4, 6, 9, 10, 11 (if using AppLocker instead), 12, 14, 15, 16.
You set an option by running:Set-RuleOption –FilePath [path to the XML policy] –Option [enter the option number].
You remove/delete an option setting by running:Set-RuleOption –FilePath [path to the XML policy] –Option [enter the option number] –Delete.
Option 0 Enabled:UMCI
- Default value: Disabled
- Default new policy: Disabled
This is definitely required. It is a part of the Basic CIS Controls (and NCSC guidelines) to authorise user applications.
You might wonder how this relates to the –UserPEs switch of the New-CIPolicy cmdlet. The basic method of New-CIPolicy is to perform a scan of the drive. The –UserPEs switch includes user-mode executables in the scan. If they were not in the scan, then they would not be allowed, regardless of Option 0. If you perform a scan to pick up a new application, then you need to use –UserPEs. This also sets Option 0, as well as including them in the scan.
Option 2 Required:WHQL
- Default value: Not required
- Default new policy: Not required
You will have to assess whether you need to allow old drivers to run. This is really a protection against vulnerabilities, rather than unauthorised applications.
Option 3 Enabled:Audit Mode (Default)
- Default value: Disabled
- Default new policy: Enabled
To enforce a policy (i.e. block rather than audit unauthorised executables) you will delete Option 3.
Option 4 Disabled:Flight Signing
- Default value: Enabled
- Default new policy: Enabled
Flight Signing certificates are Microsoft certificates used only for non-released Windows code. If you perform a scan, and include various publisher certificates in a policy, then this option disables the Microsoft Flight Signing certificates. You probably would not have any of this code in a production environment and, if you did, it would probably be for testing. So I would go ahead and set the option to disable Flight Signing certificates.
Option 6 Enabled:Unsigned System Integrity Policy (Default)
- Default value: Disabled
- Default new policy: Enabled
A binary policy can be signed with a code signing certificate. If a policy is not signed, then it can easily be circumvented by deleting the policy or replacing it, although administrator rights are required to do this. If we use file path rules, then an administrator can already run any executable by placing it in one of the allowed file paths.
If a policy is signed, it cannot simply be deleted or replaced. In fact, it is extremely difficult to remove. It can only be replaced with another policy, signed by a certificate that was previously added to the UpdatePolicySigners section of the original signed policy you want to replace. The risk is that, if you were to implement this in a physical desktop environment, and if the signing certificates were to be lost, then you would need to re-image the device to remove or replace the policy.
My view is that signing should only be used in a mature and controlled operational environment.
Option 8 Required:EV Signers
- Default value: Not required
- Default new policy: Not required
Entirely depends on whether you only use drivers with an Extended Validation certificate.
Option 9 Enabled:Advanced Boot Options Menu
- Default value: Disabled
- Default new policy: Enabled
Necessary to fix a physical device that will not boot.
Option 10 Enabled:Boot Audit on Failure
- Default value: Disabled
- Default new policy: Disabled
A precaution in case, in Enforced mode, a driver is blocked, causing the boot to fail. Should not be necessary if the policy has been tested. The risk is that an attacker could disable enforcement by causing a boot driver to fail.
Option 11 Disabled:Script Enforcement
- Default value: Enabled
- Default new policy: Enabled
This option is only supported in Windows 1903 build 18362.145 or later. The Microsoft documentation on this option is incomplete and inconsistent.
Script enforcement has two main functions:
- It blocks MSI’s. Why MSI’s? Application Control refers primarily to Portable Executables (PE’s), which are files encoded in a PE format including EXE, DLL and SYS files, but not MSI’s. So really, I think, “script” here means “non-PE”.
- It does not block scripts, but it puts PowerShell into Constrained Language mode, which blocks specific elements that expose vulnerabilities (calls to Win32 API’s). Note: a policy will only put PowerShell into Constrained Language mode if it is in Enforced mode. In Audit mode, PowerShell remains in Full Language mode.
Both MSI’s and PowerShell scripts can be allowed, although not by a File Path Rule. This means that either they need to be identified by a scan, or Script Enforcement needs to be disabled.
Audit and Enforcement events are logged in the AppLocker MSI and Script event log, not the Code Integrity log. This leads me to think that the actual mechanism is in some way linked to AppLocker. An alternative way of managing MSI’s and scripts is to disable MDAC script enforcement and use an AppLocker policy instead.
Option 12 Required:Enforce Store Applications
- Default value: Not required
- Default new policy: Required
Yes, why not?
Option 13 Enabled:Managed Installer
- Default value: Disabled
- Default new policy: Disabled
This allows you to specify SCCM as the approved installer of applications. Files placed on the system by the installer (e.g. when executing an MSI) are tagged with an attribute that allows them to run. In principle, and the way the documentation is written, this should work with any installer, including Intune, but I think possibly it only works with SCCM.
- The Managed Installer function is implemented in pre-defined policy settings in SCCM: Device Guard management with Configuration Manager. This is the “GUI” version of MDAC implementation, not custom policy.
- The generic documentation for MDAC and Managed Installer is here: Deploy Managed Installer for Windows Defender Application Control. This implies that, in a custom policy, other managed installers could be used.
- But this approach depends on AppLocker settings to use a Managed Installer rule collection. This rule collection does not exist in the AppLocker CSP, and it seems unlikely that Intune supports it.
Option 14 Enabled:Intelligent Security Graph Authorization
- Default value: Disabled
- Default new policy: Disabled
This is the dynamic reputation-based authorization of executable files, using cloud analytics. Using ISG, you don’t know exactly what will be authorised, and so you might argue that it conflicts with the security requirement to allow only explicitly authorised applications. But, when we authorise an application, we implicitly use reputation as a criterion. We don’t test the application for vulnerabilities ourselves. Another argument is that a user should never be allowed to install an application, so it would never need to be dynamically authorised. But ISG does not only apply to user-installed applications. It applies to any executable that is not already allowed by a scan or a file path rule. So it gives some flexibility to the controls.
Option 15 Enabled:Invalidate EAs on Reboot
- Default value: Disabled
- Default new policy: Disabled
This option is rather like certificate revocation. If you do not have a way to revoke authorisation by ISG, then the risk is that you will miss it if the status of an application changes from authorised to unauthorised. The documentation says that the reputation of a file will be re-evaluated periodically, but the title says On Reboot. The problem is that, if a laptop restarts and is off the network, then an application may not be re-authorised. But I don’t see how you could not use this option if relying on ISG. All the core applications will already be authorised by other means e.g. file path rule.
16 Enabled:Update Policy No Reboot
- Default value: Disabled
- Default new policy Disabled
Enable, why not?
Option 17 Enabled:Allow Supplemental Policies
- Default value: Disabled
- Default new policy: Disabled
Only required if using multiple policy format, with base and supplemental policies
Option 18 Disabled:Runtime FilePath Rule Protection
- Default value: Enabled
- Default new policy: Enabled
Allowing a file based on its path implicitly assumes that the path is not user-writeable e.g. we assume that standard users cannot write to C:\Program Files. But in some cases they can. Some sub-folders in C:\Windows are user-writeable. And some old applications modify permissions in Program Files when they are installed. This option in MDAC implements a dynamic check at runtime that the location is not user-writeable. I can’t think of a reason to disable this option.
The –UserWriteablePaths switch includes user-writeable paths in a file path scan, as well as setting this option.
Option 19 Enabled:Dynamic Code Security
- Default value: Disabled
- Default new policy: Disabled
By default, .NET can load external libraries or generate code dynamically, and these are not controlled by WDAC before execution. This option applies WDAC policy to the dynamic code. The caveat is that you need to authorise any external libraries or check whether generated code is allowed or not.