Edit

Essential Eight application control

  • Article

This article details methods for achieving the Australian Cyber Security Centre (ACSC) Essential Eight Maturity Model for Application Control, using Microsoft App Locker and Windows Defender Application Control.

Why pursue the ACSC Essential Eight application control guidelines?

Application control is a security approach designed to protect against malicious code executing on systems. When this security approach is implemented, it ensures only approved code such as executables, software libraries, scripts, installers, and drivers is authorized to execute. Due to its effectiveness, application control is one of the Essential Eight from the ACSC's Strategies to Mitigate Cyber Security Incidents.

Application control

Application control is a security approach designed to protect against malicious code executing on systems. When this security approach is implemented, it ensures only approved code such as executables, software libraries, scripts, installers, and drivers is authorized to execute.

While application control is primarily designed to prevent the execution and spread of malicious code on a system, it can also prevent the installation and use of unapproved applications.

Achieving organizational maturity level requirements

  • Maturity level 1 (ML1): can be achieved by using Microsoft AppLocker
  • Maturity levels 2 and 3 (ML2 & ML3): can be achieved by using Microsoft Windows Defender Application Control

Implementation of application control

Implementing application control involves the following high-level steps for an organization:

  • Identifying approved applications
  • Developing application control rules to ensure only approved applications can be executed
  • Maintaining the application control rules using a change management process
  • Validating application control rules on a frequent basis

When determining how to enforce application authorization within your organization, the Australia Cyber Security Centre considers the following methods suitable when implemented correctly:

  • Cryptographic hash rules
  • Publisher certification rules
  • Path Rules (when file system permissions are configured to prevent the unauthorized modification of folder and file permissions, folder contents and individual files)

Application control can prevent the unauthorized execution of unapproved applications. Application control can also contribute to the identification of attempts by a threat actor to execute malicious code on a system. Configuring WDAC to generate event logs for authorized and unauthorized executions can provide valuable information to an organization's security operations center.

It's important to note that an application control solution doesn't replace antivirus and other security software solutions that are already in place. WDAC always works in concert with antivirus solutions such as Defender Antivirus. Using Microsoft security solutions together contributes to an effective defence-in-depth approach to preventing the compromise of systems.

Maturity Levels (ML) for application control

The Australia Cyber Security Centre has three maturity levels for their mitigation strategies that constitute the Essential Eight. The maturity levels are based on mitigating increasing levels of trade craft used by a threat actor. Within the context of application control, the Australia Cyber Security Centre determines what is required to meet ML 1, 2 and 3.

ISM Mar 2024 control Maturity level Mitigation
ISM-0109 3 Event logs from workstations are analyzed in a timely manner to detect cyber security events.
ISM-0140 2, 3 Cyber security incidents are reported to ASD as soon as possible after they occur or are discovered.
ISM-0123 2, 3 Cyber security incidents are reported to the Chief Information Security Officer, or one of their delegates, as soon as possible after they occur or are discovered.
ISM-0843 1, 2, 3 Application control is implemented on workstations.
ISM-1490 2, 3 Application control is implemented on internet-facing servers.
ISM-1656 3 Application control is implemented on non-internet-facing servers.
ISM-1544 2, 3 Microsoft’s recommended application blocklist is implemented.
ISM-1657 1, 2, 3 Application control restricts the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organization-approved set.
ISM-1658 3 Application control restricts the execution of drivers to an organization-approved set.
ISM-1582 2, 3 Application control rulesets are validated on an annual or more frequent basis.
ISM-1659 3 Microsoft’s vulnerable driver blocklist is implemented.
ISM-1660 2, 3 Allowed and blocked application control events are centrally logged.
ISM-1815 2, 3 Event logs are protected from unauthorized modification and deletion.
ISM-1819 2, 3 Following the identification of a cyber security incident, the cyber security incident response plan is enacted.
ISM-1870 1, 2, 3 Application control is applied to user profiles and temporary folders used by operating systems, web browsers and email clients.
ISM-1871 2, 3 Application control is applied to all locations other than user profiles and temporary folders used by operating systems, web browsers and email clients.
ISM-1228 2, 3 Cyber security events are analyzed in a timely manner to identify cyber security incidents.
ISM-1906 2, 3 Event logs from internet-facing servers are analyzed in a timely manner to detect cyber security events.
ISM-1907 3 Event logs from non-internet-facing servers are analyzed in a timely manner to detect cyber security events.
ISM Mar 2024 control Maturity level Control Measure
ISM-0109 3 Event logs from workstations are analyzed in a timely manner to detect cyber security events. Use Defender for Endpoint P2. Windows Event Logs are captured within Microsoft Sentinel and Microsoft Defender XDR using Windows Security Events via AMA or Windows Forwarded Events solutions.
ISM-0140 2, 3 Cyber security incidents are reported to ASD as soon as possible after they occur or are discovered. Not in scope of this document. See note after this table. 3
ISM-0123 2, 3 Cyber security incidents are reported to the Chief Information Security Officer, or one of their delegates, as soon as possible after they occur or are discovered. Not in scope of this document. See note after this table. 3
ISM-0843 1, 2, 3 Application control is implemented on workstations. Configure and use Windows Defender Application Control / AppLocker depending on the organization’s maturity level requirements.
ISM-1490 2, 3 Application control is implemented on internet-facing servers. Configure and use Windows Defender Application Control
ISM-1656 3 Application control is implemented on non-internet-facing servers. Configure and use Windows Defender Application Control
ISM-1544 2, 3 Microsoft’s recommended application blocklist is implemented. Microsoft's 'recommended block rules' are implemented
ISM-1657 1, 2, 3 Application control restricts the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organization-approved set. Microsoft recommends a defined list of File Publisher Rules or File Hashes are created within an application control policy. 1
ISM-1658 3 Application control restricts the execution of drivers to an organization-approved set. Hypervisor-protected code integrity is enabled and is default for Windows 11 2022+
ISM-1582 2, 3 Application control rulesets are validated on an annual or more frequent basis. Not in scope of this document. See note below this table. 3
ISM-1659 3 Microsoft’s vulnerable driver blocklist is implemented. Microsoft's 'recommended driver block rules' are implemented
ISM-1660 2, 3 Allowed, and blocked application control events are centrally logged. Use Defender for Endpoint P2. Windows Event Logs are captured within Microsoft Sentinel and Microsoft Defender XDR using ‘Windows Security Events’ via AMA or ‘Windows Forwarded Events’ solutions.
ISM-1815 2, 3 Event logs are protected from unauthorized modification and deletion. Role-Based Access Control for Microsoft Defender XDR and Microsoft Sentinel is enforced.
ISM-1819 2, 3 Following the identification of a cyber security incident, the cyber security incident response plan is enacted. Not in scope of this document.  See note below this table. 3
ISM-1870 1, 2, 3 Application control is applied to user profiles and temporary folders used by operating systems, web browsers and email clients. Microsoft recommends a defined list of File Publisher Rules or File Hashes are created within an application control policy. Maturity Level 1 can be achieved with Microsoft AppLocker. Maturity Level 2 and 3 requires Windows Defender Application Control. 2
ISM-1871 2, 3 Application control is applied to all locations other than user profiles and temporary folders used by operating systems, web browsers and email clients. Implementation and configuration of Windows Defender Application Control
ISM-1228 2, 3 Cyber security events are analyzed in a timely manner to identify cyber security incidents. Not in scope of this document.  See note after this table. 3
ISM-1906 2, 3 Event logs from internet-facing servers are analyzed in a timely manner to detect cyber security events. Use Defender for Endpoint P2. Windows Event Logs are captured within Microsoft Sentinel and Microsoft Defender XDR using Windows Security Events via AMA or Windows Forwarded Events solutions.
ISM-1907 3 Event logs from non-internet-facing servers are analyzed in a timely manner to detect cyber security events. Use Defender for Endpoint P2. Windows Event Logs are captured within Microsoft Sentinel and Microsoft Defender XDR using Windows Security Events via AMA or Windows Forwarded Events solutions.

Important

1 To meet ISM-1657, Microsoft recommends a defined list of File Publisher Rules or File Hashes have been created within an application control policy. If File Path Rules are too be leveraged, an organization must ensure the user is prevented from the unauthorised modification of folder and file permissions, folder contents and individual files. For example, user shouldn’t have Write Access within NTFS to the File Path Rule location.

2 To meet ISM-1870, Microsoft recommends a defined list of File Publisher Rules or File Hashes have been created within an application control policy. Maturity Level 1 can be achieved with Microsoft AppLocker. Maturity Level 2 and 3 has a requirement for Windows Defender Application Control due to the additional ISM requirements. File Path Rules are not recommended for ISM-1870 due to the user having file system permission within user’s profile and temporary folders.

3 Controls ISM-0140, 0123, 1582, 1819 and 1228 are explicitly primary people and process controls. Microsoft recommends people and processes are documented and stored as artefacts in Purview Compliance Manager, as part of automated technology evidence for Essential 8 compliance reviews.

Application control for Windows

Which solution to use?

Microsoft recommends that customers implement Windows Defender Application Control (WDAC) rather than AppLocker. Windows Defender Application Control is undergoing continual improvements. While AppLocker continues to receive security fixes, it doesn't receive feature improvements.

However, AppLocker can also be deployed as a complement to Windows Defender Application Control for scenarios such as shared devices, where it's important to prevent some users from running a specific application. Microsoft recommends your organization should enforce Windows Defender Application Control as the most restrictive level possible for your organization, and using AppLocker to further fine-tune user mode restrictions, if necessary.

Tip

While WDAC is preferred, it can be simpler and easier for most organizations to achieve ML1 using just AppLocker as a starting point, both solutions are complimentary.

AppLocker

AppLocker was introduced with Windows 7 and allows organization to control which user mode (applications) processes are allowed to run on their Windows Operating Systems. AppLocker Policies can apply to all users on a system, or to individual users and groups with rules that can be defined based on:

  • Cryptographic hash rules
  • Publisher certification rules
  • Path rules

AppLocker policies can be created on any supported versions and additions of the Windows Operating System and can be deployed using Group Policy, PowerShell, or a Mobile Device Management solution.

Windows Defender Application Control

Windows Defender Application Control (WDAC) was introduced with Windows 10. It allows organizations to control which user mode (applications) and kernel mode (drivers) processes are allowed to run on their Windows Operating Systems. WDAC policies are applied to the managed system as a whole and affects all users of the device with rules that can be defined based on:

  • Cryptographic hash rules
  • Publisher certification rules
  • Path Rules
  • Reputation of the application as determined by Microsoft's Intelligent Security Graph
  • Identity of the process that initiated the installation of the application by managed installer

WDAC policies can be created on any supported client edition of Windows 10, Windows 11 or on Windows Server 2016 and above. WDAC policies can be deployed using Group Policy, a Mobile Device Management solution, Configuration Manager or PowerShell.

Due to Microsoft's Windows as a Service to allow the development and deployment of new features to our customers, some capabilities of WDAC are only available on specific Windows versions.

For detailed information about Windows Defender Application Control and Applocker, see Windows Defender Application Control and AppLocker feature availability.

Essential Eight application control using AppLocker for ML1

Use AppLocker to achieve ML1

When the admin is deploying an AppLocker policy for user-based application control, the following rules can be used as a sample path-based implementation. This includes the rules, enforcement of rules and the automatic starting of the Application Identity service.

Suggestion is to block (as a minimum) the following paths:

  • C:\Windows\Temp\*.*
  • %USERPROFILE%\AppData\Local\*.*
    • Add exception for %USERPROFILE%\AppData\Local\Microsoft\WindowsApps
  • %USERPROFILE%\AppData\Roaming\*.*

For information about AppLocker at ML1, see the following articles:

Creating AppLocker policy to achieve ML1

Microsoft AppLocker policies can be created using several methods. Microsoft recommends using the Microsoft Open source project AaronLocker to assist with the creation of AppLocker policies. AaronLocker allows for the creation and maintenance of robust, strict, application control for AppLocker as easy and practical as possible as using service of PowerShell Scripts. AaronLocker is designed to restrict program and script execution by nonadministrative users.

For detailed information about Aaronlocker, see AaronLocker: Robust and practical application control for Windows.

Deploying AppLocker policy to achieve ML1

Microsoft AppLocker can be deployed using Microsoft Intune, Group Policy, or PowerShell. The deployment method would be dependent on the organization's current management solution.

For detailed information about deploying App locker, see the following articles:

Monitoring AppLocker policy events

Microsoft AppLocker related events are monitored by a Security Information and Event management solution such as Microsoft's Sentinel. Events are also be monitored using Microsoft Defender for Endpoint's Advanced hunting information.

Microsoft Defender for Endpoint: AppLocker reference

Microsoft Defender for Endpoint captures the following events in relation to Microsoft AppLocker.

ActionType name Event source ID
AppControlExecutableAudited 8003
AppControlExecutableBlocked 8004
AppControlPackagedAppAudited 8021
AppControlPackagedAppBlocked 8022
AppControlPackagedAppBlocked 8006
AppControlScriptBlocked 8007
AppControlCIScriptAudited 8001

For detailed information about Event Viewer and Advanced hunting, see the following articles:

Essential Eight application control using WDAC for ML2

Microsoft is outlining the design process, lifecycle management, deployment, and operational guidance to meet the Essential Eight application control ML2 and ML3 using WDAC.

Customers with the requirement for Essential Eight Application Control ML1 can be achieved by using Microsoft AppLocker.

The prerequisites for using this guidance are required:

  • Windows 11 22H2 Enterprise
  • Using Intune for management solution
  • Defender for Endpoint, for endpoint security solution
  • Microsoft Sentinel for Security information and event management; and
  • Appropriate permissions by administrators across the solutions used within this document

WDAC on Windows Server Operating Systems in not in scope for this guide. Guidance for Windows Server is to be provided on a future release.

Licensing requirements

M365-related service can be located within Microsoft 365 and Office 365 service descriptions to understand the necessary services required, value propositions and licensing requirements:

Microsoft 365 and Office 365 service descriptions

For information about products associated with WDAC, see the following articles:

Getting started with WDAC

Policy design

When an organization begins planning for WDAC, consideration of the design decisions shape how it affects policy deployment and application control policy maintenance.

WDAC should be used as part of your organization's application control policies if the following are true:

  • You have deployed or plan to deploy the supported versions of Windows in your organization
  • You need improved control over the access to your organization's applications and the data your user's access
  • Your organization has a well-defined process for application management and deployment
  • You have resources to test policies against the organization's requirements
  • You have resources to involve Help Desk or to build a self-help process for end-user application access issues
  • The group's requirements for productivity, manageability, and security can be controlled by restrictive policies

WDAC incorporates a concept of 'circle of trust.' Each organization has a different definition of 'circle of trust' unique to their business requirements. ACSC Essential 8 related definition is ISM control 1657 – 'Application control restricts the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organization-approved set.'

Microsoft provides several example policies within XML format located in Windows under %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies. Microsoft example policies can allow your organization to start from an existing base policy and add or remove rules to build custom policies, if necessary.

For more information about policy design, see the following articles:

Policy formats

WDAC supports two policy formats:

  • Single policy format: The original policy format that was released with Windows 10 RTM and Windows Server 2016. Single policy format only supports a single active policy on a system at any given time

  • Multiple policy format (recommended): This policy format is supported on Windows 10 1903+, Windows 11 and Windows Server 2022. A multiple policy format allows for more flexibility for deploying Windows Defender Application Control and supports up to 32 active policies on a device. In addition, it allows for the following scenarios:

    • Enforce and audit side by side: To validate policy changes before deploying enforcement. Users can deploy audit-mode base policy side by side with an existing enforcement-mode based policy
    • Multiple base policies: Users can enforce two or more base policies simultaneously
    • Supplemental policies: Users can deploy one or more supplemental policies to expand a base policy. You might use supplementary policies for different personas within your organization, for example, HR and IT

Microsoft recommends the usage of multiple policy formats and only using single policy format for well-defined scenarios or where multiple policy formats aren't possible such as Windows Server 2016 and Windows Server 2019.

For detailed information about WDAC control policies, see Use multiple Windows Defender Application Control Policies.```

Policy rules and file rules

WDAC contains two concepts that are:

  • WDAC policy rules: WDAC policy rules specify configurations such as Audit Mode, managed installer, Script Enforcement, Supplement Policies (Multiple Policy Format), Reputation-Based intelligence (ISG Authorization / Smart App Control) and maybe others. Policy Rules also determine if WDAC for both kernel-mode and user-mode binaries
  • WDAC file rules: WDAC file rules specify authorization and reauthorization for executing on Windows. File rules support Hash, File Name, File Path, and Publisher rules allow for a customer to define an organization-approved set of allowed applications. Rule first processes all explicit deny rules it finds, and then processes all explicit allow rules. If no deny or allow rule exists, WDAC checks for managed installer. Lastly, if none of these sets exist, WDAC falls back on Reputation-Based intelligence

For detailed information about policy rules and file rules, see the following article:

Policy creation

There are two primary ways to create a WDAC Policy using PowerShell or WDAC Wizard:

  • PowerShell: WDAC policies are created using Configurable Code Integrity Cmdlets in PowerShell. PowerShell allows for an IT Pro to automate the WDAC policy system scan, which generates a policy XML. PowerShell can be used to merge policy XMLs, set policy rules and add another policy file rules if necessary The Configurable Code Integrity Cmdlets can also be used to modify the WDAC example policies to meet your organization's requirements.
  • Windows Defender Application Control Wizard (recommended): The WDAC policy wizard is an open-source Windows desktop application written in C# and bundled as an MSIX package. It was built to provide security architects with security, and system administrators with a more user-friendly means to create, edit, and merge Application Control policies. This tool uses the Config CI PowerShell cmdlets in the backend, so the output policy of the tool and PowerShell cmdlets is identical

For detailed information about policy creation, see the following articles:

Microsoft recommends the usage of the Windows Defender Application Control Wizard for implementing Essential Eight for Application Control. Alternatively, PowerShell can be used by organizations with advanced requirements in a DevOps operating model using the example policies as a base or who wishes to create a policy for well-defined scenarios from a reference system.

Policy lifecycle

Before an organization begins implementing an application control solution, you must consider how your policies are managed and maintained over time. Most WDAC policies evolve over time and continue through a set of identifiable phases during their lifetime. These phases include:

  1. Define the policy and build an audit mode version of the policy XML. In audit mode, block events are generated but files aren't prevented from executing
  2. Deploy the audit mode policy to the intended systems
  3. Monitor audit block events from the intended systems and refine the rules as needed to address unexpected / unwanted blocks
  4. Repeat these steps until the remaining block events meet your expectations while within audit
  5. Generate the enforced mode version of the policy. In enforce mode, files that aren't defined as allowed by the policy are prevented from executing and corresponding block events are generated
  6. Deploy the enforce mode policy to the intended systems
  7. Repeat all these steps continuously to address any unexpected / unwanted block actions

To effectively manage the WDAC policies, you should store and maintain your policy XML documents in a central repository. Microsoft recommends a source control solution such as GitHub or document management solution such as SharePoint, which provides version control.

WDAC prerequirements for managed installer

This section is intended to provide customer's guidance on the requirements of configuring WDAC managed installer using PowerShell and Microsoft Intune.

  • Review Windows threat protection automatically allow apps deployed by a managed installer with Windows Defender Application Control (/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer)

Note

This sample script does not use AppLocker so benign DENY rules are not present from step 1. This configuration of the AppLocker would be created for all devices requiring managed installer.

  • Create a PowerShell Script that completes the following:
    • Store the AppLocker XML
    • Export the AppLocker XML
    • Set AppLocker Policy
    • Start the AppLocker Service

The following is an example of a script that can be deployed using Intune management extension – PowerShell scripts:

$ScriptDir = Split-Path $script:MyInvocation.MyCommand.Path

$AppLockerMIPolicy = 
@"
<AppLockerPolicy Version="1">
<RuleCollection Type="ManagedInstaller" EnforcementMode="Enabled">
  <FilePublisherRule Id="55932f09-04b8-44ec-8e2d-3fc736500c56" Name="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE version 1.39.200.2 or greater in MICROSOFT® INTUNE™ from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE">
          <BinaryVersionRange LowSection="1.39.200.2" HighSection="*" />
        </FilePublisherCondition>
  </Conditions>
  </FilePublisherRule>
  <FilePublisherRule Id="6ead5a35-5bac-4fe4-a0a4-be8885012f87" Name="CMM - CCMEXEC.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMEXEC.EXE">
        <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
      </FilePublisherCondition>
    </Conditions>
  </FilePublisherRule>
  <FilePublisherRule Id="8e23170d-e0b7-4711-b6d0-d208c960f30e" Name="CCM - CCMSETUP.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMSETUP.EXE">
        <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
  </RuleCollection> 
</AppLockerPolicy>
"@

$AppLockerMIPolicy | Out-File -FilePath $ScriptDir\AppLockerMIPolixy.xml
Set-AppLockerPolicy -XmlPolicy $ScriptDir\AppLockerMIPolixy.xml -Merge -ErrorAction SilentlyContinue
Start-Process -FilePath "$env:windir\System32\appidtel.exe" -ArgumentList "start -mionly" | Wait-Process
Remove-Item -Path $ScriptDir\AppLockerMIPolixy.xml

Important

The administrator needs to add the configuration script to the WDAC File Rule policy via Hash or Publisher.

WDAC managed installer

Overview

WDAC's feature called managed installer allows for an organization to balance security and manageability when enforcing application control policies. This allows applications to be installed by a software distribution solution such as Microsoft Configuration Manager or Intune.

A common misconception is configuring the "managed installer" rule within WDAC's policy is the only required steps. This is incorrect and another configuration of AppLocker is required for this feature to operate.

Managed installer uses a rule collection within AppLocker to designate binaries that are trusted by your organization for application installation. Windows monitors the configured binary's process and any child processes it launches while monitoring associated files being written to the disk. These files are tagged as originating from a managed installer therefore allowed to execute.

Deployment of managed installer

The AppLocker policy creation within GPO Edit and the AppLocker PowerShell cmdlets can't directly be used to create rules for the managed installer collection. You have to use VS Code or another editor tool to create a managed installer Rule collection.

The AppLocker Configuration Service Provider (CSP) currently doesn't support the managed installer rule collection type so the AppLocker policy must be ingress using PowerShell for Microsoft Intune.

Since Windows Defender Application Control's feature "Script Enforcement" is required to meet ISM-1657, Script enforcement is needed to control PowerShell, VBscript, cscript, cscript, HSMTA, and MSXML. The PowerShell script to configure 'managed installer' need to be within the WDAC file policy rule using Hash or Publisher.

Microsoft recommends the configuration of the managed installer for Microsoft Intune. Intune allows for robust management of Applications packaged using Microsoft Intune without the requirement to frequently update a Windows Defender Application Control policy.

Deployment of PowerShell script for managed installer

The deployment of this configuration script for the managed installer can be achieved in two ways using Microsoft Intune depending on scenario:

  • Hash: The script's hash would need to be known within the WDAC File Policy, packaged, and deployed using the Microsoft Win32 Content Prep Tool or PowerShell Script feature within Microsoft Intune.
  • Code-signed (Publisher): The PowerShell Script has been signed by a trusted authority and known with the WDAC File Policy, packaged, and deployed using the Microsoft Win32 Content Prep Tool or PowerShell Script feature within Microsoft Intune.

For detailed information about deployment of PowerShell scripts, see the following articles:

WDAC audit policy creation

Create an audit policy

With the options understood and design decisions made, the organization is able to create the first audit policy using the Windows Defender App Control Wizard:

  1. Open the Windows Defender App Control Wizard and select "Policy Creator".

  2. Within Policy Creator, select Multiple Policy Format and Base Policy then select Next.

  3. Within the Policy Template, you're presented with three options:

    • Default Windows Mode includes Windows OS, Store Apps, Microsoft 365 Apps for Enterprise (Office 365 Pro Plus) and WHQL signed kernel drivers.
    • Allow Microsoft Mode includes all sections within Default Windows Mode and All Microsoft signed applications.
    • Signed and Reputable Mode includes all previous sections and Reputation-Based intelligence.

Important

Reputation-Based Intelligence for Application Control does not meet the Essential Eight Application Control due to the requirement "Organization-approved set" (ISM 1657) and "Application control rulesets are validated on an annual or more frequent basis" (ISM 1582).This feature within WDAC won't meet the requirements for ML2 or ML3. Microsoft recommends the use of Reputation-Based Intelligence for organizational adopting WDAC outside the context of the Essential Eight Application Control.

  1. Select Default Windows Mode or Allow Microsoft Mode depending on your organization's requirements. For this document, Microsoft is using Allow Microsoft Mode.
  2. Modify the Policy Name and Location to your desired Policy Name and Policy File Location to store the file, and select Next.

Note

Detailed Information of the WDAC – Policy Rules can be found here.

  • Disable Script Enforcement set to "Disabled" is required for ISM 1657 and 1658 to control Scripts, Complied HTML and HTML Applications.
  • Intelligent Security Graph set to "Disabled" is required for ISM 1657, 1658 and 1582.
  • Managed installer is recommended to be "Enabled" to assist an organization with WDAC policy lifecycle.
  • User Mode Code Integrity is required for WDAC policies to apply for both kernel mode and user mode binaries.
  • Allow Supplement Policies is required to use multi-policy format to assist an organization with WDAC policy lifecycle.

Note

All other WDAC policy rules are dependent on the requirements within an organization.

  1. Within Signing Rules, the admin is able to see all Microsoft's certificates that have been added as Allow Publisher Rules. We cover Add Custom Rule later in this article.
  2. Select Next.

The Windows Defender App Control Wizard generates:

  • Policy XML
  • {GUID}.CIP

Detailed Information of the WDAC – Policy Rules can be found here.

Note

Each policy that is generated using the Windows Defender App Control Wizard procures a new Globally Unique Identifier (GUID).

The WDAC policy has been successfully created.

Policy XML

As the organization has created the WDAC policy using the WDAC Wizard, the organization is able to view the context of this file within a text editor. The XML is split into several different sections, for the context of Essential Eight make note of the PolicyID and BasePolicyID.

Note

While it is possible to directly edit the Policy XML. Microsoft recommends all additional changes to policy rules or signing files to be made using the Windows Defender App Control Wizard or Configurable Code Integrity Cmdlets in PowerShell.

WDAC Audit policy deployment

Deploy WDAC audit policy via Intune

Now that the organization has created an audit policy, it's time to deploy it out using Intune device management.

  1. Sign in to Intune admin center.
  2. Within Intune admin center, go to Devices and then Configuration Profiles.
  3. Next, create a Profile > Platform – Windows 10 or Later, Profile Type Templates and Custom.
  4. Create a name for the policy (for example, 'Application Control - Microsoft Allow – Audit') and select Next.
  5. Under OMA-URI Settings, select Add.

Note

This Information is dependent on the Policy ID generated from the Windows >Defender App Control Wizard for the policy XML created from "Create Audit Policy" from the section above:

- Name = Microsoft Allow Audit
- OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
- Data Type = Base64 (File)

  1. When the Windows Defender App Control Wizard generated the policy XML, it also created a (GUID).CIP file. The CIP file needs to be copied and rename the file extension to .BIN for example {CB46B243-C19C-4870-B098-A2080923755C}.bin.
  2. Upload the BIN under Base64 (File).
  3. Select Save.
  4. Follow the prompts to create the Configuration Profile.
  5. Deploy the policy you created, for example, 'Application Control - Microsoft Allow – Audit', Configuration Profile to the intended system.

WDAC – audit policy monitoring

Following the WDAC policy lifecycle, the organization needs to review the generated events from the 'Allow Microsoft Audit' policy. WDAC audit policy monitoring can be achieved with two methods:

  • Application Control event IDs: Application control Event IDs are the traditional method of reviewing audited events on a Windows Operating System. These event IDs could be forwarded to a centralized location using Windows Event Log Forwarding or third Party Security information and event management.

For information about event IDs, see Understanding Application Control event IDs - Windows security.

Microsoft recommends using the Microsoft Defender XDR (MDE) integration to Microsoft Sentinel. MDE and Sentinel allow for the Advanced Hunting telemetry data to be stored for longer than 30 days compare to the Microsoft Defender for Endpoint.

For detailed information about connections and monitoring, see the following articles:

Monitoring WDAC with Microsoft Defender for Endpoint

The following example demonstrates a user has several applications used for an organization's daily tasks. The example contains both Microsoft applications and various open source applications.

As the example is in enforcement audit mode, it can be seen by the administrator (but not affect the user) that events triggered for WinSCP, VLC, Putty, and FileZilla since these applications aren't a part of the initial audit policy.

Now using the Microsoft Defender portal, enter Advanced Hunting to narrow down audit events to understand what unexpected / unwanted blocks would be occurring if audit mode disabled, and thus made into enforce mode within this example.

Screenshot of advanced hunting.

Using the reference schema from the previous page, look for all Policy Audit events triggered by WDAC from the past seven days and presents relevant information using the example Keyboard Query Language (KQL) query:

DeviceEvents 
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| project DeviceId,                                  // The device ID where the audit block happened
    FileName,                                        // The audit blocked app's filename
    FolderPath,                                      // The audit blocked app's system path without the FileName
    InitiatingProcessFileName,                       // The file name of the parent process loading the executable
    InitiatingProcessVersionInfoCompanyName,         // The company name of the parent process loading the executable
    InitiatingProcessVersionInfoOriginalFileName,    // The original file name of the parent process loading the executable
    InitiatingProcessVersionInfoProductName,         // The product name of the parent process loading the executable
    InitiatingProcessSHA256,                         // The SHA256 flat hash of the parent process loading the executable
    Timestamp,                                       // The event creation timestamp
    ReportId,                                        // The report ID - randomly generated by MDE AH
    InitiatingProcessVersionInfoProductVersion,      // The product version of the parent process loading the executable
    InitiatingProcessVersionInfoFileDescription,     // The file description of the parent process loading the executable
    AdditionalFields                                 // Additional fields contains FQBN for signed binaries.  These contain the CN of the leaf certificate, product name, original filename and version of the audited binary

Here's an example of an output using the previous KQL query.

Screenshot of Advanced Hunting output.

Within the records, there's a detailed report of information such as the Process Tree, File Path, SHA Information, Signer, and Issuer Information.

The next step is to narrow down the results.

Using the same KQL query, add another field where the Initiating Process File Name is Windows Explorer. The KQL query displays the applications executed by users within the GUI.

 DeviceEvents 
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| where InitiatingProcessFileName startswith "explorer.exe" // Users starting an Application via File Explorer / GUI
| project DeviceId,                                  // The device ID where the audit block happened
    FileName,                                        // The audit blocked app's filename
    FolderPath,                                      // The audit blocked app's system path without the FileName
    InitiatingProcessFileName,                       // The file name of the parent process loading the executable
    InitiatingProcessVersionInfoCompanyName,         // The company name of the parent process loading the executable
    InitiatingProcessVersionInfoOriginalFileName,    // The original file name of the parent process loading the executable
    InitiatingProcessVersionInfoProductName,         // The product name of the parent process loading the executable
    InitiatingProcessSHA256,                         // The SHA256 flat hash of the parent process loading the executable
    Timestamp,                                       // The event creation timestamp
    ReportId,                                        // The report ID - randomly generated by MDE AH
    InitiatingProcessVersionInfoProductVersion,      // The product version of the parent process loading the executable
    InitiatingProcessVersionInfoFileDescription,     // The file description of the parent process loading the executable
    AdditionalFields                                 // Additional fields contains FQBN for signed binaries.  These contain the CN of the leaf certificate, product name, original filename and version of the audited binary

Here's an example of an output using the previous KQL query. Screenshot of output of query.

The KQL query action has now narrowed down the information to a more management dataset. What can be seen are the applications being used by intended systems. These applications need to be added to the organization's policy or be considered to be added via organizational change control.

Note

KQL is a powerful tool to display unstructured and structured datasets. This is just an example of using KQL and Microsoft would recommend reviewing the following documentation: Learn the advanced hunting query language in Microsoft Defender XDR

WDAC – Update audit policy

Update audit policy using Microsoft Defender for Endpoint and WDAC wizard

With a narrowed down our search results using KQL, the next step is to update the WDAC base policy or use a supplement policy. The next example uses supplement policies.

  1. Open the Windows Defender App Control Wizard and select Policy Creator.

  2. Within Policy Creator, select Multiple Policy Format, and Supplemental Policy, navigate to your base policy, update the location to save your Supplemental Policy and select Next.

  3. Select Next within Policy Rules.

  4. Within Policy Signing Rules , select Custom Rule.

  5. Within Custom Rule Conditions, many options are available:

    • Rule Scope User Mode Rule / Kernel Mode Rule
    • Rule Action: Allow / Deny
    • Rule Type
      • Publisher (recommended)
      • File
      • File Attribute
      • Packaged App
      • Hash
    • Reference File

Note

Microsoft recommends using Publisher based rules where appropriate and falling back to Hash based rules for unsigned reference files to implement the Essential Eight Application Control.

Using Microsoft Defender for Endpoint

  1. Search File Name in Search and navigate to the file Information and download the file. Screenshot of updating audit policy 2.
  2. Inspect the record directly from Advanced Hunting and download the file that then download the required binaries. Screenshot of updating audit policy 3.
  3. With the required binaries, next continue creating another policy for your organization's ISV applications.
  4. Within Windows Defender App Control Wizard, select the desired Rule Type and navigate to the reference binaries from the previous step. The next example demonstrates that VLC meets the required publisher information. Screenshot of updating audit policy 4.

Note

Microsoft recommends Issuing CA, Publisher to be selective at a minimum for creating a publisher-based rule. Product name can be included, and is recommended by the ACSC for publisher-based rules.

  1. Press Next and Create.
  2. Deploy this Supplement Policy using the steps previously described in section "Deploy Windows Defender Application Control Audit Policy via Microsoft Intune".

WDAC – Switch to enforce policy

To switch to enforce policy:

  1. Open the Windows Defender App Control Wizard and select Policy Editor.

  2. Navigate to the Policy XML that is to be changed to enforced.

  3. Disable Audit Mode switch within Policy Rules.

  4. Select Next within Policy Rules.

  5. An Update Policy is created with an amended version number and a new CIP file has been created.

  6. Within Microsoft Endpoint Manager Admin Center, go to Devices and then Configuration Profiles.

  7. Next, create a Profile, Platform – Windows 10 or Later, Profile Type Templates and Custom.

  8. Create a name for the policy, for example, Application Control – Enforce Policy and select Next.

  9. Under OMA-URI Settings, select Add.

    Note

    This Information is dependent on the Policy ID generated from the Windows Defender App Control Wizard for the policy XML created from the create audit section above.

    - Name = Microsoft Allow Enforce
    - OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
    - Data Type = Base64 (File)

  10. When the Windows Defender App Control Wizard generated the policy XML, it also created a (GUID).CIP File. The next step is to copy this CIP File and rename the file extension to .BIN for example {CB46B243-C19C-4870-B098-A2080923755C}.bin.

  11. Upload the BIN under Base64 (File).

  12. Select Save.

  13. Follow the prompts to create the Configuration Profile.

  14. Deploy Application Control – Enforce Policy Configuration Profile to intended system.

    Note

    The administrator needs to exclude the previously created Application – Audit Policy from the intended system that is being switched to enforce