Edit

Create a WDAC policy for lightly managed devices

Note

Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the Windows Defender Application Control feature availability.

This section outlines the process to create a Windows Defender Application Control (WDAC) policy for lightly managed devices within an organization. Typically, organizations that are new to application control will be most successful if they start with a permissive policy like the one described in this article. Organizations can choose to harden the policy over time to achieve a stronger overall security posture on their WDAC-managed devices as described in later articles.

Note

Some of the Windows Defender Application Control options described in this topic are only available on Windows 10 version 1903 and above, or Windows 11. When using this topic to plan your own organization's WDAC policies, consider whether your managed clients can use all or some of these features and assess the impact for any features that may be unavailable on your clients. You may need to adapt this guidance to meet your specific organization's needs.

As in Windows Defender Application Control deployment in different scenarios: types of devices, we'll use the example of Lamna Healthcare Company (Lamna) to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.

Alice Pena is the IT team lead tasked with the rollout of WDAC. Lamna currently has loose application usage policies and a culture of maximum app flexibility for users. So, Alice knows she'll need to take an incremental approach to application control and use different policies for different workloads.

For most users and devices, Alice wants to create an initial policy that is as relaxed as possible in order to minimize user productivity impact, while still providing security value.

Define the "circle-of-trust" for lightly managed devices

Alice identifies the following key factors to arrive at the "circle-of-trust" for Lamna's lightly managed devices, which currently include most end-user devices:

  • All clients are running Windows 10 version 1903 and above, or Windows 11;
  • All clients are managed by Configuration Manager or with Intune.
  • Some, but not all, apps are deployed using Configuration Manager;
  • Most users are local administrators on their devices;
  • Some teams may need more rules to authorize specific apps that don't apply generally to all other users.

Based on the above, Alice defines the pseudo-rules for the policy:

  1. "Windows works" rules that authorize:

    • Windows
    • WHQL (third-party kernel drivers)
    • Windows Store signed apps

  2. "ConfigMgr works" rules that include:

    • Signer and hash rules for Configuration Manager components to properly function.
    • Allow Managed Installer rule to authorize Configuration Manager as a managed installer.

  3. Allow Intelligent Security Graph (ISG) (reputation-based authorization)

  4. Signed apps using a certificate issued by a Windows Trusted Root Program certificate authority

  5. Admin-only path rules for the following locations:

    • C:\Program Files*
    • C:\Program Files (x86)*
    • %windir%*

Create a custom base policy using an example WDAC base policy

Having defined the "circle-of-trust", Alice is ready to generate the initial policy for Lamna's lightly managed devices. Alice decides to use the example SmartAppControl.xml to create the initial base policy and then customize it to meet Lamna's needs.

Alice follows these steps to complete this task:

  1. On a client device, run the following commands in an elevated Windows PowerShell session to initialize variables:

    Note

    If you prefer to use a different example Windows Defender Application Control base policy, substitute the example policy path with your preferred base policy in this step.

    $PolicyPath = $env:userprofile+"\Desktop\"
$PolicyName= "Lamna_LightlyManagedClients_Audit"
$LamnaPolicy=Join-Path $PolicyPath "$PolicyName.xml"
$ExamplePolicy=$env:windir+"\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml"

  2. Copy the example policy to the desktop:

    Copy-Item $ExamplePolicy $LamnaPolicy

  3. Modify the policy to remove unsupported rule:

    Note

    SmartAppControl.xml is available on Windows 11 version 22H2 and later. This policy includes "Enabled:Conditional Windows Lockdown Policy" rule that is unsupported for enterprise WDAC policies and must be removed. For more information, see WDAC and Smart App Control. If you are using an example policy other than SmartAppControl.xml, skip this step.

    [xml]$xml = Get-Content $LamnaPolicy
$ns = New-Object System.Xml.XmlNamespaceManager($xml.NameTable)
$ns.AddNamespace("ns", $xml.DocumentElement.NamespaceURI)
$node = $xml.SelectSingleNode("//ns:Rules/ns:Rule[ns:Option[.='Enabled:Conditional Windows Lockdown Policy']]", $ns)
$node.ParentNode.RemoveChild($node)
$xml.Save($LamnaPolicy)

  4. Give the new policy a unique ID, descriptive name, and initial version number:

    Set-CIPolicyIdInfo -FilePath $LamnaPolicy -PolicyName $PolicyName -ResetPolicyID
Set-CIPolicyVersion -FilePath $LamnaPolicy -Version "1.0.0.0"

  5. Use Configuration Manager to create and deploy an audit policy to the client device running Windows 10 version 1903 and above, or Windows 11. Merge the Configuration Manager policy with the example policy.

    Note

    If you do not use Configuration Manager, skip this step.

    $ConfigMgrPolicy=$env:windir+"\CCM\DeviceGuard\MergedPolicy_Audit_ISG.xml"
Merge-CIPolicy -OutputFilePath $LamnaPolicy -PolicyPaths $LamnaPolicy,$ConfigMgrPolicy
Set-RuleOption -FilePath $LamnaPolicy -Option 13 # Managed Installer

  6. Modify the policy to set additional policy rules:

    Set-RuleOption -FilePath $LamnaPolicy -Option 3  # Audit Mode
Set-RuleOption -FilePath $LamnaPolicy -Option 12 # Enforce Store Apps
Set-RuleOption -FilePath $LamnaPolicy -Option 19 # Dynamic Code Security

  7. Add rules to allow the Windows and Program Files directories:

    $PathRules += New-CIPolicyRule -FilePathRule "%windir%\*"
$PathRules += New-CIPolicyRule -FilePathRule "%OSDrive%\Program Files\*"
$PathRules += New-CIPolicyRule -FilePathRule "%OSDrive%\Program Files (x86)\*"
Merge-CIPolicy -OutputFilePath $LamnaPolicy -PolicyPaths $LamnaPolicy -Rules $PathRules

  8. If appropriate, add more signer or file rules to further customize the policy for your organization.

  9. Use ConvertFrom-CIPolicy to convert the Windows Defender Application Control policy to a binary format:

    [xml]$PolicyXML = Get-Content $LamnaPolicy
$LamnaPolicyBin = Join-Path $PolicyPath "$($PolicyXML.SiPolicy.PolicyID).cip"
ConvertFrom-CIPolicy $LamnaPolicy $LamnaPolicyBin

  10. Upload your base policy XML and the associated binary to a source control solution, such as GitHub or a document management solution such as Office 365 SharePoint.

At this point, Alice now has an initial policy that is ready to deploy in audit mode to the managed clients within Lamna.

Security considerations of this lightly managed policy

In order to minimize user productivity impact, Alice has defined a policy that makes several trade-offs between security and user app flexibility. Some of the trade-offs include:

  • Users with administrative access

    This trade-off is the most impactful security trade-off. It allows the device user, or malware running with the user's privileges, to modify or remove the WDAC policy on the device. Additionally, administrators can configure any app to act as a managed installer, which would allow them to gain persistent app authorization for whatever apps or binaries they wish.

    Possible mitigations:

    • Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies.
    • To remove the requirement for managed installer, create and deploy signed catalog files as part of the app deployment process.
    • Use device attestation to detect the configuration state of WDAC at boot time and use that information to condition access to sensitive corporate resources.

  • Unsigned policies

    Unsigned policies can be replaced or removed without consequence by any process running as administrator. Unsigned base policies that also enable supplemental policies can have their "circle-of-trust" altered by any unsigned supplemental policy.

    Possible mitigations:

    • Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies.
    • Limit who can elevate to administrator on the device.

  • Managed installer

    See security considerations with managed installer

    Possible mitigations:

    • To remove the requirement for managed installer, create and deploy signed catalog files as part of the app deployment process.
    • Limit who can elevate to administrator on the device.

  • Intelligent Security Graph (ISG)

    See security considerations with the Intelligent Security Graph

    Possible mitigations:

    • Implement policies that require apps be managed by IT. Audit existing app usage and deploy authorized apps using a software distribution solution, like Microsoft Intune. Move from ISG to managed installer or signature-based rules.
    • Use a restrictive audit mode policy to audit app usage and augment vulnerability detection.

  • Supplemental policies

    Supplemental policies are designed to relax the associated base policy. Additionally allowing unsigned policies allows any administrator process to expand the "circle-of-trust" defined by the base policy without restriction.

    Possible mitigations:

    • Use signed WDAC policies that allow authorized signed supplemental policies only.
    • Use a restrictive audit mode policy to audit app usage and augment vulnerability detection.

  • FilePath rules

    See more information about filepath rules

    Possible mitigations:

    • Limit who can elevate to administrator on the device.
    • Migrate from filepath rules to managed installer or signature-based rules.

  • Signed files

    Although files that are code-signed verify the author's identity and ensures that the code hasn't been altered by anyone other than the author, it doesn't guarantee that the signed code is safe.

    Possible mitigations:

    • Use a reputable antimalware or antivirus software with real-time protection, such as Microsoft Defender, to protect your devices from malicious files, adware, and other threats.

Up next