Merge pull request #6691 from MicrosoftDocs/aljupudi-6027362-improperacronyms-04

Improper acronyms review update-04
This commit is contained in:
Aaron Czechowski 2022-06-10 20:36:08 -07:00 committed by GitHub
commit cd23a4f0ef
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
51 changed files with 208 additions and 208 deletions

View File

@ -25,7 +25,7 @@ The table below shows the applicability of Windows:
Windows Defender Application Control (WDAC) policies can be managed from an MDM server, or locally by using PowerShell via the WMI Bridge through the ApplicationControl configuration service provider (CSP). The ApplicationControl CSP was added in Windows 10, version 1903. This CSP provides expanded diagnostic capabilities and support for [multiple policies](/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies) (introduced in Windows 10, version 1903). It also provides support for rebootless policy deployment (introduced in Windows 10, version 1709). Unlike the [AppLocker CSP](applocker-csp.md), the ApplicationControl CSP correctly detects the presence of no-reboot option and consequently doesn't schedule a reboot. Windows Defender Application Control (WDAC) policies can be managed from an MDM server, or locally by using PowerShell via the WMI Bridge through the ApplicationControl configuration service provider (CSP). The ApplicationControl CSP was added in Windows 10, version 1903. This CSP provides expanded diagnostic capabilities and support for [multiple policies](/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies) (introduced in Windows 10, version 1903). It also provides support for rebootless policy deployment (introduced in Windows 10, version 1709). Unlike the [AppLocker CSP](applocker-csp.md), the ApplicationControl CSP correctly detects the presence of no-reboot option and consequently doesn't schedule a reboot.
Existing WDAC policies deployed using the AppLocker CSP's CodeIntegrity node can now be deployed using the ApplicationControl CSP URI. Although WDAC policy deployment via the AppLocker CSP will continue to be supported, all new feature work will be done in the ApplicationControl CSP only. Existing Windows Defender Application Control (WDAC) policies deployed using the AppLocker CSP's CodeIntegrity node can now be deployed using the ApplicationControl CSP URI. Although, WDAC policy deployment via the AppLocker CSP will continue to be supported, all new feature work will be done in the ApplicationControl CSP only.
The following example shows the ApplicationControl CSP in tree format. The following example shows the ApplicationControl CSP in tree format.

View File

@ -75,9 +75,10 @@ Set the following registry keys to enable HVCI. This provides exactly the same s
<!--This comment ensures that the Important above and the Warning below don't merge together. --> <!--This comment ensures that the Important above and the Warning below don't merge together. -->
> [!IMPORTANT] > [!IMPORTANT]
>
> - Among the commands that follow, you can choose settings for **Secure Boot** and **Secure Boot with DMA**. In most situations, we recommend that you choose **Secure Boot**. This option provides Secure Boot with as much protection as is supported by a given computers hardware. A computer with input/output memory management units (IOMMUs) will have Secure Boot with DMA protection. A computer without IOMMUs will simply have Secure Boot enabled. > - Among the commands that follow, you can choose settings for **Secure Boot** and **Secure Boot with DMA**. In most situations, we recommend that you choose **Secure Boot**. This option provides Secure Boot with as much protection as is supported by a given computers hardware. A computer with input/output memory management units (IOMMUs) will have Secure Boot with DMA protection. A computer without IOMMUs will simply have Secure Boot enabled.
> >
> In contrast, with **Secure Boot with DMA**, the setting will enable Secure Boot—and VBS itself—only on a computer that supports DMA, that is, a computer with IOMMUs. With this setting, any computer without IOMMUs will not have VBS or HVCI protection, although it can still have WDAC enabled. > - In contrast, with **Secure Boot with DMA**, the setting will enable Secure Boot—and VBS itself—only on a computer that supports DMA, that is, a computer with IOMMUs. With this setting, any computer without IOMMUs will not have VBS or HVCI protection, although it can still have Windows Defender Application Control enabled.
> >
> - All drivers on the system must be compatible with virtualization-based protection of code integrity; otherwise, your system may fail. We recommend that you enable these features on a group of test computers before you enable them on users' computers. > - All drivers on the system must be compatible with virtualization-based protection of code integrity; otherwise, your system may fail. We recommend that you enable these features on a group of test computers before you enable them on users' computers.
@ -312,7 +313,7 @@ C. If you experience a critical error during boot or your system is unstable aft
## HVCI deployment in virtual machines ## HVCI deployment in virtual machines
HVCI can protect a Hyper-V virtual machine, just as it would a physical machine. The steps to enable WDAC are the same from within the virtual machine. HVCI can protect a Hyper-V virtual machine, just as it would a physical machine. The steps to enable Windows Defender Application Control are the same from within the virtual machine.
WDAC protects against malware running in the guest virtual machine. It does not provide additional protection from the host administrator. From the host, you can disable WDAC for a virtual machine: WDAC protects against malware running in the guest virtual machine. It does not provide additional protection from the host administrator. From the host, you can disable WDAC for a virtual machine:

View File

@ -24,7 +24,7 @@ Windows 10 includes a set of hardware and OS technologies that, when configured
WDAC policies and HVCI are powerful protections that can be used separately. However, when these two technologies are configured to work together, they present a strong protection capability for Windows 10 devices. WDAC policies and HVCI are powerful protections that can be used separately. However, when these two technologies are configured to work together, they present a strong protection capability for Windows 10 devices.
Using WDAC to restrict devices to only authorized apps has these advantages over other solutions: Using Windows Defender Application Control to restrict devices to only authorized apps has these advantages over other solutions:
1. WDAC policy is enforced by the Windows kernel itself, and the policy takes effect early in the boot sequence before nearly all other OS code and before traditional antivirus solutions run. 1. WDAC policy is enforced by the Windows kernel itself, and the policy takes effect early in the boot sequence before nearly all other OS code and before traditional antivirus solutions run.
2. WDAC lets you set application control policy for code that runs in user mode, kernel mode hardware and software drivers, and even code that runs as part of Windows. 2. WDAC lets you set application control policy for code that runs in user mode, kernel mode hardware and software drivers, and even code that runs as part of Windows.
@ -37,7 +37,7 @@ When we originally promoted Device Guard, we did so with a specific security pro
WDAC has no specific hardware or software requirements other than running Windows 10, which means customers were denied the benefits of this powerful application control capability due to Device Guard confusion. WDAC has no specific hardware or software requirements other than running Windows 10, which means customers were denied the benefits of this powerful application control capability due to Device Guard confusion.
Since the initial release of Windows 10, the world has witnessed numerous hacking and malware attacks where application control alone could have prevented the attack altogether. With this in mind, we now discuss and document WDAC as an independent technology within our security stack and gave it a name of its own: [Windows Defender Application Control](../windows-defender-application-control/windows-defender-application-control.md). Since the initial release of Windows 10, the world has witnessed numerous hacking and malware attacks where application control alone could have prevented the attack altogether. With this in mind, we now discuss and document Windows Defender Application Control as an independent technology within our security stack and gave it a name of its own: [Windows Defender Application Control](../windows-defender-application-control/windows-defender-application-control.md).
We hope this change will help us better communicate options for adopting application control within your organizations. We hope this change will help us better communicate options for adopting application control within your organizations.
## Related articles ## Related articles

View File

@ -27,13 +27,13 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
> [!NOTE] > [!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](../feature-availability.md). > Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
After deployment of the WDAC AppId Tagging policy, WDAC will log a 3099 policy deployed event in the [Event Viewer logs](../event-id-explanations.md). You first should ensure that the policy has been successfully deployed onto the system by verifying the presence of the 3099 event. After deployment of the WDAC AppId Tagging policy, WDAC will log a 3099 policy deployed event in the [Event Viewer logs](../event-id-explanations.md). You first should ensure that the policy has been successfully deployed onto the system by verifying the presence of the 3099 event.
## Verifying Tags on Running Processes ## Verifying Tags on Running Processes
After verifying the policy has been deployed, the next step is to verify that the application processes you expect to pass the AppId Tagging policy have your tag set. Note that processes running at the time of policy deployment will need to be restarted since WDAC can only tag processes created after the policy has been deployed. After verifying the policy has been deployed, the next step is to verify that the application processes you expect to pass the AppId Tagging policy have your tag set. Note that processes running at the time of policy deployment will need to be restarted since Windows Defender Application Control (WDAC) can only tag processes created after the policy has been deployed.
1. Download and Install the Windows Debugger 1. Download and Install the Windows Debugger

View File

@ -29,7 +29,7 @@ ms.technology: windows-sec
> [!NOTE] > [!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](../feature-availability.md). > Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
Similar to WDAC Application Control policies, WDAC AppId Tagging policies can be deployed locally and to your managed endpoints several ways. Once you've created your AppId Tagging policy, use one of the following methods to deploy: Similar to Windows Defender Application Control (WDAC) policies, WDAC AppId Tagging policies can be deployed locally and to your managed endpoints several ways. Once you've created your AppId Tagging policy, use one of the following methods to deploy:
1. [Deploy AppId Tagging Policies with MDM](#deploy-appid-tagging-policies-with-mdm) 1. [Deploy AppId Tagging Policies with MDM](#deploy-appid-tagging-policies-with-mdm)
1. [Deploy policies with MEMCM](#deploy-appid-tagging-policies-with-memcm) 1. [Deploy policies with MEMCM](#deploy-appid-tagging-policies-with-memcm)
@ -46,7 +46,7 @@ Custom AppId Tagging policies can deployed via MEMCM using the [deployment task
### Deploy AppId Tagging Policies via Scripting ### Deploy AppId Tagging Policies via Scripting
Scripting hosts can be used to deploy AppId Tagging policies as well. This approach is often best suited for local deployment, but works for deployment to managed endpoints and users too. The [Deploy WDAC policies using script article](/deployment/deploy-wdac-policies-with-script.md) describes how to deploy WDAC AppId Tagging policies via scripting. Only the method for deploying to version 1903 and above is applicable for AppId Tagging policies. Scripting hosts can be used to deploy AppId Tagging policies as well. This approach is often best suited for local deployment, but works for deployment to managed endpoints and users too. The [Deploy Windows Defender Application Control policies using script article](/deployment/deploy-wdac-policies-with-script.md) describes how to deploy WDAC AppId Tagging policies via scripting. Only the method for deploying to version 1903 and above is applicable for AppId Tagging policies.
### Deploying policies via the ApplicationControl CSP ### Deploying policies via the ApplicationControl CSP
@ -57,4 +57,4 @@ However, when policies are unenrolled from an MDM server, the CSP will attempt t
For more information, see [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp) to deploy multiple policies, and optionally use MEM Intune's Custom OMA-URI capability. For more information, see [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp) to deploy multiple policies, and optionally use MEM Intune's Custom OMA-URI capability.
> [!NOTE] > [!NOTE]
> WMI and GP do not currently support multiple policies. Instead, customers who can't directly access the MDM stack should use the [ApplicationControl CSP via the MDM Bridge WMI Provider](/windows/client-management/mdm/applicationcontrol-csp#powershell-and-wmi-bridge-usage-guidance) to manage Multiple Policy Format WDAC policies. > WMI and GP do not currently support multiple policies. Instead, customers who can't directly access the MDM stack should use the [ApplicationControl CSP via the MDM Bridge WMI Provider](/windows/client-management/mdm/applicationcontrol-csp#powershell-and-wmi-bridge-usage-guidance) to manage Multiple Policy Format Windows Defender Application Control policies.

View File

@ -27,11 +27,11 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
> [!NOTE] > [!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](../feature-availability.md). > Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
## Create the policy using the WDAC Wizard ## Create the policy using the WDAC Wizard
You can use the WDAC Wizard and the PowerShell commands to create an application control policy and convert it to an AppIdTagging policy. The WDAC Wizard is available for download at the [WDAC Wizard Installer site](https://aka.ms/wdacwizard). These PowerShell commands are only available on the supported platforms listed in [AppId Tagging Guide](./windows-defender-application-control-appid-tagging-guide.md). You can use the Windows Defender Application Control (WDAC) Wizard and the PowerShell commands to create an application control policy and convert it to an AppIdTagging policy. The WDAC Wizard is available for download at the [WDAC Wizard Installer site](https://aka.ms/wdacwizard). These PowerShell commands are only available on the supported platforms listed in [AppId Tagging Guide](./windows-defender-application-control-appid-tagging-guide.md).
1. Create a new base policy using the templates: 1. Create a new base policy using the templates:

View File

@ -31,7 +31,7 @@ ms.technology: windows-sec
## AppId Tagging Feature Overview ## AppId Tagging Feature Overview
The Application ID (AppId) Tagging Policy feature, while based off WDAC, does not control whether applications will run. AppId Tagging policies can be used to mark the processes of the running application with a customizable tag defined in the policy. Application processes that pass the AppId policy will receive the tag while failing applications won't. The Application ID (AppId) Tagging Policy feature, while based off Windows Defender Application Control (WDAC), does not control whether applications will run. AppId Tagging policies can be used to mark the processes of the running application with a customizable tag defined in the policy. Application processes that pass the AppId policy will receive the tag while failing applications won't.
## AppId Tagging Feature Availability ## AppId Tagging Feature Availability

View File

@ -1,6 +1,6 @@
--- ---
title: Allow LOB Win32 Apps on Intune-Managed S Mode Devices (Windows) title: Allow LOB Win32 Apps on Intune-Managed S Mode Devices (Windows)
description: Using WDAC supplemental policies, you can expand the S mode base policy on your Intune-managed devices. description: Using Windows Defender Application Control (WDAC) supplemental policies, you can expand the S mode base policy on your Intune-managed devices.
keywords: security, malware keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security ms.prod: m365-security
@ -26,7 +26,7 @@ ms.technology: windows-sec
- Windows 11 - Windows 11
>[!NOTE] >[!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](feature-availability.md). >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
Beginning with the Windows 10 November 2019 update (build 18363), Microsoft Intune enables customers to deploy and run business critical Win32 applications and Windows components that are normally blocked in S mode (ex. PowerShell.exe) on their Intune-managed Windows in S mode devices. Beginning with the Windows 10 November 2019 update (build 18363), Microsoft Intune enables customers to deploy and run business critical Win32 applications and Windows components that are normally blocked in S mode (ex. PowerShell.exe) on their Intune-managed Windows in S mode devices.
@ -39,7 +39,7 @@ Refer to the below video for an overview and brief demo.
![Policy Authorization.](images/wdac-intune-policy-authorization.png) ![Policy Authorization.](images/wdac-intune-policy-authorization.png)
The general steps for expanding the S mode base policy on your Intune-managed devices are to generate a supplemental policy, sign that policy, and then upload the signed policy to Intune and assign it to user or device groups. Because you need access to WDAC PowerShell cmdlets to generate your supplemental policy, you should create and manage your policies on a non-S mode device. Once the policy has been uploaded to Intune, we recommend assigning it to a single test S-mode device to verify expected functioning before deploying the policy more broadly. The general steps for expanding the S mode base policy on your Intune-managed devices are to generate a supplemental policy, sign that policy, and then upload the signed policy to Intune and assign it to user or device groups. Because you need access to WDAC PowerShell cmdlets to generate your supplemental policy, you should create and manage your policies on a non-S mode device. Once the policy has been uploaded to Intune, we recommend assigning it to a single test S-mode device to verify expected functioning before deploying the policy more broadly.
1. Generate a supplemental policy with WDAC tooling 1. Generate a supplemental policy with Windows Defender Application Control tooling
This policy will expand the S mode base policy to authorize additional applications. Anything authorized by either the S mode base policy or your supplemental policy will be allowed to run. Your supplemental policies can specify filepath rules, trusted publishers, and more. This policy will expand the S mode base policy to authorize additional applications. Anything authorized by either the S mode base policy or your supplemental policy will be allowed to run. Your supplemental policies can specify filepath rules, trusted publishers, and more.
@ -63,7 +63,7 @@ The general steps for expanding the S mode base policy on your Intune-managed de
Set-RuleOption -FilePath "<path>\SupplementalPolicy.xml>" -Option 3 Delete Set-RuleOption -FilePath "<path>\SupplementalPolicy.xml>" -Option 3 Delete
``` ```
This deletes the 'audit mode' qualifier. This deletes the 'audit mode' qualifier.
- Since you'll be signing your policy, you must authorize the signing certificate you will use to sign the policy and optionally one or more additional signers that can be used to sign updates to the policy in the future. For more information, refer to Section 2, Sign policy. Use Add-SignerRule to add the signing certificate to the WDAC policy: - Since you'll be signing your policy, you must authorize the signing certificate you will use to sign the policy and optionally one or more additional signers that can be used to sign updates to the policy in the future. For more information, refer to Section 2, Sign policy. Use Add-SignerRule to add the signing certificate to the Windows Defender Application Control policy:
```powershell ```powershell
Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User -Update Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User -Update
@ -76,7 +76,7 @@ The general steps for expanding the S mode base policy on your Intune-managed de
2. Sign policy 2. Sign policy
Supplemental S mode policies must be digitally signed. To sign your policy, you can choose to use the Device Guard Signing Service (DGSS) or your organization's custom Public Key Infrastructure (PKI). Refer to [Use the Device Guard Signing Portal in the Microsoft Store for Business](use-device-guard-signing-portal-in-microsoft-store-for-business.md) for guidance on using DGSS and [Create a code signing cert for WDAC](create-code-signing-cert-for-windows-defender-application-control.md) for guidance on signing using an internal CA. Supplemental S mode policies must be digitally signed. To sign your policy, you can choose to use the Device Guard Signing Service (DGSS) or your organization's custom Public Key Infrastructure (PKI). Refer to [Use the Device Guard Signing Portal in the Microsoft Store for Business](use-device-guard-signing-portal-in-microsoft-store-for-business.md) for guidance on using DGSS and [Create a code signing cert for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md) for guidance on signing using an internal CA.
Rename your policy to "{PolicyID}.p7b" after you've signed it. PolicyID can be found by inspecting the Supplemental Policy XML. Rename your policy to "{PolicyID}.p7b" after you've signed it. PolicyID can be found by inspecting the Supplemental Policy XML.

View File

@ -29,7 +29,7 @@ ms.technology: windows-sec
>[!NOTE] >[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](feature-availability.md). >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](feature-availability.md).
Running Application Control in audit mode lets you discover applications, binaries, and scripts that are missing from your WDAC policy but should be included. Running Application Control in audit mode lets you discover applications, binaries, and scripts that are missing from your Windows Defender Application Control policy (WDAC) but should be included.
While a WDAC policy is running in audit mode, any binary that runs but would have been denied is logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log. Script and MSI are logged in the **Applications and Services Logs\\Microsoft\\Windows\\AppLocker\\MSI and Script** event log. These events can be used to generate a new WDAC policy that can be merged with the original Base policy or deployed as a separate Supplemental policy, if allowed. While a WDAC policy is running in audit mode, any binary that runs but would have been denied is logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log. Script and MSI are logged in the **Applications and Services Logs\\Microsoft\\Windows\\AppLocker\\MSI and Script** event log. These events can be used to generate a new WDAC policy that can be merged with the original Base policy or deployed as a separate Supplemental policy, if allowed.
@ -81,7 +81,7 @@ To familiarize yourself with creating WDAC rules from audit events, follow these
## Convert WDAC **BASE** policy from audit to enforced ## Convert WDAC **BASE** policy from audit to enforced
As described in [common WDAC deployment scenarios](types-of-devices.md), 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. As described in [common Windows Defender Application Control deployment scenarios](types-of-devices.md), 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 responsible for Lamna's WDAC rollout. **Alice Pena** is the IT team lead responsible for Lamna's WDAC rollout.

View File

@ -27,7 +27,7 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](feature-availability.md). >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Application Control feature availability](feature-availability.md).
Running Application Control in audit mode lets you discover applications, binaries, and scripts that are missing from your WDAC policy but should be included. Running Application Control in audit mode lets you discover applications, binaries, and scripts that are missing from your WDAC policy but should be included.

View File

@ -29,7 +29,7 @@ ms.technology: windows-sec
>[!NOTE] >[!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](feature-availability.md). >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
This section outlines the process to create a WDAC policy for fixed-workload devices within an organization. Fixed-workload devices tend to be dedicated to a specific functional purpose and share common configuration attributes with other devices servicing the same functional role. Examples of fixed-workload devices may include Active Directory Domain Controllers, Secure Admin Workstations, pharmaceutical drug-mixing equipment, manufacturing devices, cash registers, ATMs, etc. This section outlines the process to create a Windows Defender Application Control (WDAC) policy for fixed-workload devices within an organization. Fixed-workload devices tend to be dedicated to a specific functional purpose and share common configuration attributes with other devices servicing the same functional role. Examples of fixed-workload devices may include Active Directory Domain Controllers, Secure Admin Workstations, pharmaceutical drug-mixing equipment, manufacturing devices, cash registers, ATMs, etc.
For this example, you must initiate variables to be used during the creation process or use the full file paths in the command. For this example, you must initiate variables to be used during the creation process or use the full file paths in the command.
Then create the WDAC policy by scanning the system for installed applications. Then create the WDAC policy by scanning the system for installed applications.
@ -37,7 +37,7 @@ The policy file is converted to binary format when it gets created so that Windo
## Overview of the process of creating Windows Defender Application Control policies ## Overview of the process of creating Windows Defender Application Control policies
A common system imaging practice in todays IT organization is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone additional company assets. WDAC policies follow a similar methodology, that begins with the establishment of a golden computer. As with imaging, you can have multiple golden computers based on model, department, application set, and so on. Although the thought process around the creation of WDAC policies is similar to imaging, these policies should be maintained independently. Assess the necessity of additional WDAC policies based on what should be allowed to be installed and run and for whom. For more details on doing this assessment, see the [WDAC Design Guide](windows-defender-application-control-design-guide.md). A common system imaging practice in todays IT organization is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone additional company assets. Windows Defender Application Control policies follow a similar methodology, that begins with the establishment of a golden computer. As with imaging, you can have multiple golden computers based on model, department, application set, and so on. Although the thought process around the creation of WDAC policies is similar to imaging, these policies should be maintained independently. Assess the necessity of additional WDAC policies based on what should be allowed to be installed and run and for whom. For more details on doing this assessment, see the [WDAC Design Guide](windows-defender-application-control-design-guide.md).
Optionally, WDAC can align with your software catalog and any IT departmentapproved applications. One straightforward method to implement WDAC is to use existing images to create one master WDAC policy. You do so by creating a WDAC policy from each image, and then by merging the policies. This way, what is installed on all of those images will be allowed to run, if the applications are installed on a computer based on a different image. Alternatively, you may choose to create a base applications policy and add policies based on the computers role or department. Organizations have a choice of how their policies are created, merged, or serviced, and managed. Optionally, WDAC can align with your software catalog and any IT departmentapproved applications. One straightforward method to implement WDAC is to use existing images to create one master WDAC policy. You do so by creating a WDAC policy from each image, and then by merging the policies. This way, what is installed on all of those images will be allowed to run, if the applications are installed on a computer based on a different image. Alternatively, you may choose to create a base applications policy and add policies based on the computers role or department. Organizations have a choice of how their policies are created, merged, or serviced, and managed.
@ -51,9 +51,7 @@ We recommend that you review the reference computer for software that can load a
Examples include software aimed at development or scripting such as msbuild.exe (part of Visual Studio and the .NET Framework) which can be removed if you do not want to run scripts. Examples include software aimed at development or scripting such as msbuild.exe (part of Visual Studio and the .NET Framework) which can be removed if you do not want to run scripts.
You can remove or disable such software on the reference computer. You can remove or disable such software on the reference computer.
To create a Windows Defender Application Control policy, copy each of the following commands into an elevated Windows PowerShell session, in order:
To create a WDAC policy, copy each of the following commands into an elevated Windows PowerShell session, in order:
1. Initialize variables that you will use. 1. Initialize variables that you will use.

View File

@ -32,7 +32,7 @@ In this article we explain:
## File Rule Precedence Order ## File Rule Precedence Order
To create effective WDAC deny policies, it's crucial to understand how WDAC parses the policy. The WDAC engine evaluates files against the policy in the following order. To create effective Windows Defender Application Control deny policies, it's crucial to understand how WDAC parses the policy. The WDAC engine evaluates files against the policy in the following order.
1. Explicit deny rules - if any explicit deny rule exists for a file, it will not run even if other rules are created to try to allow it. Deny rules can use any [rule level](select-types-of-rules-to-create.md#windows-defender-application-control-file-rule-levels). Use the most specific rule level practical when creating deny rules to avoid blocking more than you intend. 1. Explicit deny rules - if any explicit deny rule exists for a file, it will not run even if other rules are created to try to allow it. Deny rules can use any [rule level](select-types-of-rules-to-create.md#windows-defender-application-control-file-rule-levels). Use the most specific rule level practical when creating deny rules to avoid blocking more than you intend.
@ -45,7 +45,7 @@ To create effective WDAC deny policies, it's crucial to understand how WDAC pars
5. If no rule exists for the file and it's not allowed based on ISG or MI, then the file is blocked implicitly. 5. If no rule exists for the file and it's not allowed based on ISG or MI, then the file is blocked implicitly.
> [!NOTE] > [!NOTE]
> If your WDAC policy does not have an explicit rule to allow or deny a binary to run, then WDAC will make a call to the cloud to determine whether the binary is familiar and safe. However, if your policy already authorizes or denies the binary, then WDAC will not make a call to the cloud. For more details, see [How does the integration between WDAC and the Intelligent Security Graph work?](use-windows-defender-application-control-with-intelligent-security-graph.md#how-does-the-integration-between-wdac-and-the-intelligent-security-graph-work). > If your Windows Defender Application Control policy does not have an explicit rule to allow or deny a binary to run, then WDAC will make a call to the cloud to determine whether the binary is familiar and safe. However, if your policy already authorizes or denies the binary, then WDAC will not make a call to the cloud. For more details, see [How does the integration between WDAC and the Intelligent Security Graph work?](use-windows-defender-application-control-with-intelligent-security-graph.md#how-does-the-integration-between-wdac-and-the-intelligent-security-graph-work).
## Interaction with Existing Policies ## Interaction with Existing Policies
@ -155,7 +155,7 @@ Merge-CIPolicy -PolicyPaths $DenyPolicy, $AllowAllPolicy -OutputFilePath $DenyPo
Policies should be thoroughly evaluated and first rolled out in audit mode before strict enforcement. Policies can be deployed via multiple options: Policies should be thoroughly evaluated and first rolled out in audit mode before strict enforcement. Policies can be deployed via multiple options:
1. Mobile Device Management (MDM): [Deploy WDAC policies using Mobile Device Management (MDM) (Windows)](deploy-windows-defender-application-control-policies-using-intune.md) 1. Mobile Device Management (MDM): [Deploy Windows Defender Application Control (WDAC) policies using Mobile Device Management (MDM) (Windows)](deploy-windows-defender-application-control-policies-using-intune.md)
2. Microsoft Endpoint Configuration Manager (MEMCM): [Deploy Windows Defender Application Control (WDAC) policies by using Microsoft Endpoint Configuration Manager (MEMCM) (Windows)](deployment/deploy-wdac-policies-with-memcm.md) 2. Microsoft Endpoint Configuration Manager (MEMCM): [Deploy Windows Defender Application Control (WDAC) policies by using Microsoft Endpoint Configuration Manager (MEMCM) (Windows)](deployment/deploy-wdac-policies-with-memcm.md)

View File

@ -30,12 +30,12 @@ ms.technology: windows-sec
>[!NOTE] >[!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](feature-availability.md). >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
This section outlines the process to create a WDAC policy for **fully managed devices** within an organization. The key difference between this scenario and [lightly managed devices](create-wdac-policy-for-lightly-managed-devices.md) is that all software deployed to a fully managed device is managed by IT and users of the device cannot install arbitrary apps. Ideally, all apps are deployed using a software distribution solution, such as Microsoft Endpoint Manager (MEM). Additionally, users on fully managed devices should ideally run as standard user and only authorized IT pros have administrative access. This section outlines the process to create a Windows Defender Application Control (WDAC) policy for **fully managed devices** within an organization. The key difference between this scenario and [lightly managed devices](create-wdac-policy-for-lightly-managed-devices.md) is that all software deployed to a fully managed device is managed by IT and users of the device cannot install arbitrary apps. Ideally, all apps are deployed using a software distribution solution, such as Microsoft Endpoint Manager (MEM). Additionally, users on fully managed devices should ideally run as standard user and only authorized IT pros have administrative access.
> [!NOTE] > [!NOTE]
> Some of the WDAC 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. > 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 described in [common WDAC deployment scenarios](types-of-devices.md), we will 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. As described in [common Windows Defender Application Control deployment scenarios](types-of-devices.md), we will 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. **Alice Pena** is the IT team lead tasked with the rollout of WDAC.
@ -79,7 +79,7 @@ Having defined the "circle-of-trust", Alice is ready to generate the initial pol
Alice follows these steps to complete this task: Alice follows these steps to complete this task:
> [!NOTE] > [!NOTE]
> If you do not use MEMCM or prefer to use a different [example WDAC base policy](example-wdac-base-policies.md) for your own policy, skip to step 2 and substitute the MEMCM policy path with your preferred example base policy. > If you do not use MEMCM or prefer to use a different [example Windows Defender Application Control base policy](example-wdac-base-policies.md) for your own policy, skip to step 2 and substitute the MEMCM policy path with your preferred example base policy.
1. [Use MEMCM to create and deploy an audit policy](/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager) to a client device running Windows 10 version 1903 or above, or Windows 11. 1. [Use MEMCM to create and deploy an audit policy](/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager) to a client device running Windows 10 version 1903 or above, or Windows 11.
@ -119,7 +119,7 @@ Alice follows these steps to complete this task:
6. If appropriate, add additional signer or file rules to further customize the policy for your organization. 6. If appropriate, add additional signer or file rules to further customize the policy for your organization.
7. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the WDAC policy to a binary format: 7. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the Windows Defender Application Control policy to a binary format:
> [!NOTE] > [!NOTE]
> In the sample commands below, replace the string "{InsertPolicyID}" with the actual PolicyID GUID (including braces **{ }**) found in your policy XML file. > In the sample commands below, replace the string "{InsertPolicyID}" with the actual PolicyID GUID (including braces **{ }**) found in your policy XML file.
@ -169,5 +169,5 @@ Alice has defined a policy for Lamna's fully managed devices that makes some tra
## Up next ## Up next
- [Create a WDAC policy for fixed-workload devices using a reference computer](create-initial-default-policy.md) - [Create a Windows Defender Application Control policy for fixed-workload devices using a reference computer](create-initial-default-policy.md)
- [Prepare to deploy WDAC policies](windows-defender-application-control-deployment-guide.md) - [Prepare to deploy Windows Defender Application Control policies](windows-defender-application-control-deployment-guide.md)

View File

@ -30,10 +30,10 @@ ms.technology: windows-sec
>[!NOTE] >[!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](feature-availability.md). >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
This section outlines the process to create a 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 topic. 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 topics. 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 topic. 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 topics.
> [!NOTE] > [!NOTE]
> Some of the WDAC 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. > 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 the [previous topic](types-of-devices.md), we will 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. As in the [previous topic](types-of-devices.md), we will 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.
@ -77,7 +77,7 @@ Having defined the "circle-of-trust", Alice is ready to generate the initial pol
Alice follows these steps to complete this task: Alice follows these steps to complete this task:
> [!NOTE] > [!NOTE]
> If you do not use MEMCM or prefer to use a different [example WDAC base policy](example-wdac-base-policies.md) for your own policy, skip to step 2 and substitute the MEMCM policy path with your preferred example base policy. > If you do not use MEMCM or prefer to use a different [example Windows Defender Application Control base policy](example-wdac-base-policies.md) for your own policy, skip to step 2 and substitute the MEMCM policy path with your preferred example base policy.
1. [Use MEMCM to create and deploy an audit policy](/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager) to a client device running Windows 10 version 1903 and above, or Windows 11. 1. [Use MEMCM to create and deploy an audit policy](/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager) to a client device running Windows 10 version 1903 and above, or Windows 11.
@ -185,5 +185,5 @@ In order to minimize user productivity impact, Alice has defined a policy that m
## Up next ## Up next
- [Create a WDAC policy for fully managed devices](create-wdac-policy-for-fully-managed-devices.md) - [Create a Windows Defender Application Control policy for fully managed devices](create-wdac-policy-for-fully-managed-devices.md)
- [Prepare to deploy WDAC policies](windows-defender-application-control-deployment-guide.md) - [Prepare to deploy Windows Defender Application Control policies](windows-defender-application-control-deployment-guide.md)

View File

@ -33,14 +33,14 @@ Catalog files can be important in your deployment of Windows Defender Applicatio
## Create catalog files ## Create catalog files
The creation of a catalog file simplifies the steps to run unsigned applications in the presence of a WDAC policy. The creation of a catalog file simplifies the steps to run unsigned applications in the presence of a Windows Defender Application Control policy.
To create a catalog file, you use a tool called **Package Inspector**. You must also have a WDAC policy deployed in audit mode on the computer on which you run Package Inspector, so that Package Inspector can include any temporary installation files that are added and then removed from the computer during the installation process. To create a catalog file, you use a tool called **Package Inspector**. You must also have a WDAC policy deployed in audit mode on the computer on which you run Package Inspector, so that Package Inspector can include any temporary installation files that are added and then removed from the computer during the installation process.
> [!NOTE] > [!NOTE]
> When you establish a naming convention it makes it easier to detect deployed catalog files in the future. In this guide, *\*-Contoso.cat* is used as the example naming convention. > When you establish a naming convention it makes it easier to detect deployed catalog files in the future. In this guide, *\*-Contoso.cat* is used as the example naming convention.
1. Be sure that a WDAC policy is currently deployed in audit mode on the computer on which you will run Package Inspector. 1. Be sure that a Windows Defender Application Control policy is currently deployed in audit mode on the computer on which you will run Package Inspector.
Package Inspector does not always detect temporary installation files that are added and then removed from the computer during the installation process. To ensure that these binaries are also included in your catalog file, deploy a WDAC policy in audit mode. Package Inspector does not always detect temporary installation files that are added and then removed from the computer during the installation process. To ensure that these binaries are also included in your catalog file, deploy a WDAC policy in audit mode.
@ -108,7 +108,7 @@ Packages can fail for the following reasons:
- Package Inspector is completely incompatible if files in the package (temporary or otherwise) change hash each time the package is installed. You can diagnose this by looking at the hash field in the 3077 block events when the package is failing in enforcement. If each time you attempt to run the package you get a new block event with a different hash, the package will not work with Package Inspector - Package Inspector is completely incompatible if files in the package (temporary or otherwise) change hash each time the package is installed. You can diagnose this by looking at the hash field in the 3077 block events when the package is failing in enforcement. If each time you attempt to run the package you get a new block event with a different hash, the package will not work with Package Inspector
- Files with an invalid signature blob or otherwise "unhashable" files - Files with an invalid signature blob or otherwise "unhashable" files
- This issue arises when a file that has been signed is modified post signing in a way that invalidates the PE header and renders the file unable to be hashed by the Authenticode Spec. - This issue arises when a file that has been signed is modified post signing in a way that invalidates the PE header and renders the file unable to be hashed by the Authenticode Spec.
- WDAC uses Authenticode Hashes to validate files when they are running. If the file is unhashable via the authenticode SIP, there is no way to identify the file to allow it, regardless of if you attempt to add the file to the policy directly, or re-sign the file with a Package Inspector catalog (the signature is invalidated due to file being edited, file can't be allowed by hash due to authenticode hashing algorithm rejecting it) - Windows Defender Application Control uses Authenticode Hashes to validate files when they are running. If the file is unhashable via the authenticode SIP, there is no way to identify the file to allow it, regardless of if you attempt to add the file to the policy directly, or re-sign the file with a Package Inspector catalog (the signature is invalidated due to file being edited, file can't be allowed by hash due to authenticode hashing algorithm rejecting it)
- Recent versions of InstallShield packages that use custom actions can hit this. If the DLL input to the custom action was signed before being put through InstallShield, InstallShield adds tracking markers to the file (editing it post signature) which leaves the file in this "unhashable" state and renders the file unable to be allowed by Windows Defender (regardless of if you try to allow directly by policy or resign with Package Inspector) - Recent versions of InstallShield packages that use custom actions can hit this. If the DLL input to the custom action was signed before being put through InstallShield, InstallShield adds tracking markers to the file (editing it post signature) which leaves the file in this "unhashable" state and renders the file unable to be allowed by Windows Defender (regardless of if you try to allow directly by policy or resign with Package Inspector)
## Catalog signing with SignTool.exe ## Catalog signing with SignTool.exe
@ -156,7 +156,7 @@ After the catalog file is signed, add the signing certificate to a WDAC policy,
1. If you have not already verified the catalog file digital signature, right-click the catalog file, and then click **Properties**. On the **Digital Signatures** tab, verify that your signing certificate exists with the algorithm you expect. 1. If you have not already verified the catalog file digital signature, right-click the catalog file, and then click **Properties**. On the **Digital Signatures** tab, verify that your signing certificate exists with the algorithm you expect.
2. If you already have an XML policy file that you want to add the signing certificate to, skip to the next step. Otherwise, use [New-CIPolicy](/powershell/module/configci/new-cipolicy) to create a WDAC policy that you will later merge into another policy (not deploy as-is). This example creates a policy called **CatalogSignatureOnly.xml** in the location **C:\\PolicyFolder**: 2. If you already have an XML policy file that you want to add the signing certificate to, skip to the next step. Otherwise, use [New-CIPolicy](/powershell/module/configci/new-cipolicy) to create a Windows Defender Application Control policy that you will later merge into another policy (not deploy as-is). This example creates a policy called **CatalogSignatureOnly.xml** in the location **C:\\PolicyFolder**:
`New-CIPolicy -Level PcaCertificate -FilePath C:\PolicyFolder\CatalogSignatureOnly.xml UserPEs` `New-CIPolicy -Level PcaCertificate -FilePath C:\PolicyFolder\CatalogSignatureOnly.xml UserPEs`

View File

@ -27,9 +27,9 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!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](feature-availability.md). >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
Prior to Windows 10 1903, WDAC only supported a single active policy on a system at any given time. This significantly limited customers in situations where multiple policies with different intents would be useful. Beginning with Windows 10 version 1903, WDAC supports up to 32 active policies on a device at once in order to enable the following scenarios: Prior to Windows 10 1903, Windows Defender Application Control only supported a single active policy on a system at any given time. This significantly limited customers in situations where multiple policies with different intents would be useful. Beginning with Windows 10 version 1903, WDAC supports up to 32 active policies on a device at once in order to enable the following scenarios:
1. Enforce and Audit Side-by-Side 1. Enforce and Audit Side-by-Side
- To validate policy changes before deploying in enforcement mode, users can now deploy an audit-mode base policy side by side with an existing enforcement-mode base policy - To validate policy changes before deploying in enforcement mode, users can now deploy an audit-mode base policy side by side with an existing enforcement-mode base policy
@ -91,7 +91,7 @@ When merging, the policy type and ID of the leftmost/first policy specified is u
## Deploying multiple policies ## Deploying multiple policies
In order to deploy multiple WDAC policies, you must either deploy them locally by copying the `*.cip` policy files into the proper folder or by using the ApplicationControl CSP, which is supported by MEM Intune's Custom OMA-URI feature. In order to deploy multiple Windows Defender Application Control policies, you must either deploy them locally by copying the `*.cip` policy files into the proper folder or by using the ApplicationControl CSP, which is supported by MEM Intune's Custom OMA-URI feature.
### Deploying multiple policies locally ### Deploying multiple policies locally
@ -105,11 +105,11 @@ To deploy policies locally using the new multiple policy format, follow these st
### Deploying multiple policies via ApplicationControl CSP ### Deploying multiple policies via ApplicationControl CSP
Multiple WDAC policies can be managed from an MDM server through ApplicationControl configuration service provider (CSP). The CSP also provides support for rebootless policy deployment.<br> Multiple Windows Defender Application Control policies can be managed from an MDM server through ApplicationControl configuration service provider (CSP). The CSP also provides support for rebootless policy deployment.<br>
However, when policies are un-enrolled from an MDM server, the CSP will attempt to remove every policy from devices, not just the policies added by the CSP. The reason for this is that the ApplicationControl CSP doesn't track enrollment sources for individual policies, even though it will query all policies on a device, regardless if they were deployed by the CSP. However, when policies are un-enrolled from an MDM server, the CSP will attempt to remove every policy from devices, not just the policies added by the CSP. The reason for this is that the ApplicationControl CSP doesn't track enrollment sources for individual policies, even though it will query all policies on a device, regardless if they were deployed by the CSP.
See [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp) for more information on deploying multiple policies, optionally using MEM Intune's Custom OMA-URI capability. See [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp) for more information on deploying multiple policies, optionally using MEM Intune's Custom OMA-URI capability.
> [!NOTE] > [!NOTE]
> WMI and GP do not currently support multiple policies. Instead, customers who cannot directly access the MDM stack should use the [ApplicationControl CSP via the MDM Bridge WMI Provider](/windows/client-management/mdm/applicationcontrol-csp#powershell-and-wmi-bridge-usage-guidance) to manage Multiple Policy Format WDAC policies. > WMI and GP do not currently support multiple policies. Instead, customers who cannot directly access the MDM stack should use the [ApplicationControl CSP via the MDM Bridge WMI Provider](/windows/client-management/mdm/applicationcontrol-csp#powershell-and-wmi-bridge-usage-guidance) to manage Multiple Policy Format Windows Defender Application Control policies.

View File

@ -27,14 +27,14 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!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](feature-availability.md). >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
> [!NOTE] > [!NOTE]
> Group Policy-based deployment of WDAC policies only supports single-policy format WDAC policies. To use WDAC on devices running Windows 10 1903 and greater, or Windows 11, we recommend using an alternative method for policy deployment. > Group Policy-based deployment of Windows Defender Application Control policies only supports single-policy format WDAC policies. To use WDAC on devices running Windows 10 1903 and greater, or Windows 11, we recommend using an alternative method for policy deployment.
Single-policy format WDAC policies (pre-1903 policy schema) can be easily deployed and managed with Group Policy. The following procedure walks you through how to deploy a WDAC policy called **ContosoPolicy.bin** to a test OU called *WDAC Enabled PCs* by using a GPO called **Contoso GPO Test**. Single-policy format Windows Defender Application Control policies (pre-1903 policy schema) can be easily deployed and managed with Group Policy. The following procedure walks you through how to deploy a WDAC policy called **ContosoPolicy.bin** to a test OU called *WDAC Enabled PCs* by using a GPO called **Contoso GPO Test**.
To deploy and manage a WDAC policy with Group Policy: To deploy and manage a Windows Defender Application Control policy with Group Policy:
1. On a client computer on which RSAT is installed, open the GPMC by running **GPMC.MSC** 1. On a client computer on which RSAT is installed, open the GPMC by running **GPMC.MSC**

View File

@ -27,13 +27,13 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!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](feature-availability.md). >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
You can use a Mobile Device Management (MDM) solution, like Microsoft Endpoint Manager (MEM) Intune, to configure Windows Defender Application Control (WDAC) on client machines. Intune includes native support for WDAC which can be a helpful starting point, but customers may find the available circle-of-trust options too limiting. To deploy a custom policy through Intune and define your own circle of trust, you can configure a profile using Custom OMA-URI. If your organization uses another MDM solution, check with your solution provider for WDAC policy deployment steps. You can use a Mobile Device Management (MDM) solution, like Microsoft Endpoint Manager (MEM) Intune, to configure Windows Defender Application Control (WDAC) on client machines. Intune includes native support for WDAC which can be a helpful starting point, but customers may find the available circle-of-trust options too limiting. To deploy a custom policy through Intune and define your own circle of trust, you can configure a profile using Custom OMA-URI. If your organization uses another MDM solution, check with your solution provider for WDAC policy deployment steps.
## Use Intune's built-in policies ## Use Intune's built-in policies
Intune's built-in WDAC support allows you to configure Windows client computers to only run: Intune's built-in Windows Defender Application Control support allows you to configure Windows client computers to only run:
- Windows components - Windows components
- 3rd party hardware and software kernel drivers - 3rd party hardware and software kernel drivers
@ -51,7 +51,7 @@ To use Intune's built-in WDAC policies, configure [Endpoint Protection for Windo
## Deploy WDAC policies with custom OMA-URI ## Deploy WDAC policies with custom OMA-URI
> [!NOTE] > [!NOTE]
> Policies deployed through Intune custom OMA-URI are subject to a 350,000 byte limit. Customers should create WDAC policies that use signature-based rules, the Intelligent Security Graph, and managed installers where practical. Customers whose devices are running 1903+ builds of Windows are also encouraged to use [multiple policies](deploy-multiple-windows-defender-application-control-policies.md) which allow more granular policy. > Policies deployed through Intune custom OMA-URI are subject to a 350,000 byte limit. Customers should create Windows Defender Application Control policies that use signature-based rules, the Intelligent Security Graph, and managed installers where practical. Customers whose devices are running 1903+ builds of Windows are also encouraged to use [multiple policies](deploy-multiple-windows-defender-application-control-policies.md) which allow more granular policy.
### Deploy custom WDAC policies on Windows 10 1903+ ### Deploy custom WDAC policies on Windows 10 1903+
@ -78,7 +78,7 @@ The steps to use Intune's custom OMA-URI functionality are:
### Remove WDAC policies on Windows 10 1903+ ### Remove WDAC policies on Windows 10 1903+
Upon deletion, policies deployed through Intune via the ApplicationControl CSP are removed from the system but stay in effect until the next reboot. In order to disable WDAC enforcement, first replace the existing policy with a new version of the policy that will "Allow *", like the rules in the example policy at %windir%\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml. Once the updated policy is deployed, you can then delete the policy from the Intune portal. This will prevent anything from being blocked and fully remove the WDAC policy on the next reboot. Upon deletion, policies deployed through Intune via the ApplicationControl CSP are removed from the system but stay in effect until the next reboot. In order to disable Windows Defender Application Control enforcement, first replace the existing policy with a new version of the policy that will "Allow *", like the rules in the example policy at %windir%\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml. Once the updated policy is deployed, you can then delete the policy from the Intune portal. This will prevent anything from being blocked and fully remove the WDAC policy on the next reboot.
### For pre-1903 systems ### For pre-1903 systems
@ -100,4 +100,4 @@ The steps to use Intune's Custom OMA-URI functionality to leverage the [AppLocke
#### Removing policies #### Removing policies
Policies deployed through Intune via the AppLocker CSP cannot be deleted through the Intune console. In order to disable WDAC policy enforcement, either deploy an audit-mode policy or use a script to delete the existing policy. Policies deployed through Intune via the AppLocker CSP cannot be deleted through the Intune console. In order to disable Windows Defender Application Control policy enforcement, either deploy an audit-mode policy or use a script to delete the existing policy.

View File

@ -25,7 +25,7 @@ ms.localizationpriority: medium
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability). >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
You can use Microsoft Endpoint Configuration Manager (MEMCM) to configure Windows Defender Application Control (WDAC) on client machines. You can use Microsoft Endpoint Configuration Manager (MEMCM) to configure Windows Defender Application Control (WDAC) on client machines.
@ -39,7 +39,7 @@ MEMCM includes native support for WDAC, which allows you to configure Windows 10
- [Optional] Reputable apps as defined by the Intelligent Security Graph (ISG) - [Optional] Reputable apps as defined by the Intelligent Security Graph (ISG)
- [Optional] Apps and executables already installed in admin-definable folder locations that MEMCM will allow through a one-time scan during policy creation on managed endpoints. - [Optional] Apps and executables already installed in admin-definable folder locations that MEMCM will allow through a one-time scan during policy creation on managed endpoints.
Note that MEMCM does not remove policies once deployed. To stop enforcement, you should switch the policy to audit mode, which will produce the same effect. If you want to disable WDAC altogether (including audit mode), you can deploy a script to delete the policy file from disk, and either trigger a reboot or wait for the next reboot. Note that MEMCM does not remove policies once deployed. To stop enforcement, you should switch the policy to audit mode, which will produce the same effect. If you want to disable Windows Defender Application Control (WDAC) altogether (including audit mode), you can deploy a script to delete the policy file from disk, and either trigger a reboot or wait for the next reboot.
For more information on using MEMCM's native WDAC policies, see [Windows Defender Application Control management with Configuration Manager](/mem/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager). For more information on using MEMCM's native WDAC policies, see [Windows Defender Application Control management with Configuration Manager](/mem/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager).

View File

@ -25,7 +25,7 @@ ms.localizationpriority: medium
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability). >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic describes how to deploy Windows Defender Application Control (WDAC) policies using script. The instructions below use PowerShell but can work with any scripting host. This topic describes how to deploy Windows Defender Application Control (WDAC) policies using script. The instructions below use PowerShell but can work with any scripting host.
@ -43,7 +43,7 @@ This topic describes how to deploy Windows Defender Application Control (WDAC) p
$RefreshPolicyTool = "<Path where RefreshPolicy.exe can be found from managed endpoints>" $RefreshPolicyTool = "<Path where RefreshPolicy.exe can be found from managed endpoints>"
``` ```
2. Copy WDAC policy binary to the destination folder. 2. Copy Windows Defender Application Control (WDAC) policy binary to the destination folder.
```powershell ```powershell
Copy-Item -Path $PolicyBinary -Destination $DestinationFolder -Force Copy-Item -Path $PolicyBinary -Destination $DestinationFolder -Force
@ -66,7 +66,7 @@ This topic describes how to deploy Windows Defender Application Control (WDAC) p
$DestinationBinary = $env:windir+"\System32\CodeIntegrity\SiPolicy.p7b" $DestinationBinary = $env:windir+"\System32\CodeIntegrity\SiPolicy.p7b"
``` ```
2. Copy WDAC policy binary to the destination. 2. Copy Windows Defender Application Control (WDAC) policy binary to the destination.
```powershell ```powershell
Copy-Item -Path $PolicyBinary -Destination $DestinationBinary -Force Copy-Item -Path $PolicyBinary -Destination $DestinationBinary -Force

View File

@ -27,22 +27,23 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!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](feature-availability.md). >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
This topic covers how to disable unsigned or signed WDAC policies. This topic covers how to disable unsigned or signed WDAC policies.
## Disable unsigned Windows Defender Application Control policies ## Disable unsigned Windows Defender Application Control policies
There may come a time when an administrator wants to disable a WDAC policy. For unsigned WDAC policies, this process is simple. The method used to deploy the policy (such as Group Policy) must first be disabled, then simply delete the SIPolicy.p7b policy file from the following locations, and the WDAC policy will be disabled on the next computer restart: There may come a time when an administrator wants to disable a Windows Defender Application Control policy. For unsigned WDAC policies, this process is simple. The method used to deploy the policy (such as Group Policy) must first be disabled, then simply delete the SIPolicy.p7b policy file from the following locations, and the WDAC policy will be disabled on the next computer restart:
- &lt;EFI System Partition&gt;\\Microsoft\\Boot\\ - &lt;EFI System Partition&gt;\\Microsoft\\Boot\\
- &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\ - &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\
Note that as of the Windows 10 May 2019 Update (1903), WDAC allows multiple policies to be deployed to a device. To fully disable WDAC when multiple policies are in effect, you must first disable each method being used to deploy a policy. Then delete the {Policy GUID}.cip policy files found in the \CIPolicies\Active subfolder under each of the paths listed above in addition to any SIPolicy.p7b file found in the root directory. >[!NOTE]
> As of the Windows 10 May 2019 Update (1903), Windows Defender Application Control allows multiple policies to be deployed to a device. To fully disable WDAC when multiple policies are in effect, you must first disable each method being used to deploy a policy. Then delete the {Policy GUID}.cip policy files found in the \CIPolicies\Active subfolder under each of the paths listed above in addition to any SIPolicy.p7b file found in the root directory.
## Disable signed Windows Defender Application Control policies within Windows ## Disable signed Windows Defender Application Control policies within Windows
Signed policies protect Windows from administrative manipulation as well as malware that has gained administrative-level access to the system. For this reason, signed WDAC policies are intentionally more difficult to remove than unsigned policies. They inherently protect themselves from modification or removal and therefore are difficult even for administrators to remove successfully. If the signed WDAC policy is manually enabled and copied to the CodeIntegrity folder, to remove the policy, you must complete the following steps. Signed policies protect Windows from administrative manipulation as well as malware that has gained administrative-level access to the system. For this reason, signed Windows Defender Application Control policies are intentionally more difficult to remove than unsigned policies. They inherently protect themselves from modification or removal and therefore are difficult even for administrators to remove successfully. If the signed WDAC policy is manually enabled and copied to the CodeIntegrity folder, to remove the policy, you must complete the following steps.
> [!NOTE] > [!NOTE]
> For reference, signed WDAC policies should be replaced and removed from the following locations: > For reference, signed WDAC policies should be replaced and removed from the following locations:
@ -67,7 +68,7 @@ Signed policies protect Windows from administrative manipulation as well as malw
5. Restart the client computer. 5. Restart the client computer.
If the signed WDAC policy has been deployed using by using Group Policy, you must complete the following steps: If the signed Windows Defender Application Control policy has been deployed using by using Group Policy, you must complete the following steps:
1. Replace the existing policy in the GPO with another signed policy that has the **6 Enabled: Unsigned System Integrity Policy** rule option enabled. 1. Replace the existing policy in the GPO with another signed policy that has the **6 Enabled: Unsigned System Integrity Policy** rule option enabled.
@ -89,7 +90,7 @@ If the signed WDAC policy has been deployed using by using Group Policy, you mus
## Disable signed Windows Defender Application Control policies within the BIOS ## Disable signed Windows Defender Application Control policies within the BIOS
There may be a time when signed WDAC policies cause a boot failure. Because WDAC policies enforce kernel mode drivers, it is important that they be thoroughly tested on each software and hardware configuration before being enforced and signed. Signed WDAC policies are validated in the pre-boot sequence by using Secure Boot. When you disable the Secure Boot feature in the BIOS, and then delete the file from the following locations on the operating system disk, it allows the system to boot into Windows: There may be a time when signed Windows Defender Application Control policies cause a boot failure. Because WDAC policies enforce kernel mode drivers, it is important that they be thoroughly tested on each software and hardware configuration before being enforced and signed. Signed WDAC policies are validated in the pre-boot sequence by using Secure Boot. When you disable the Secure Boot feature in the BIOS, and then delete the file from the following locations on the operating system disk, it allows the system to boot into Windows:
- &lt;EFI System Partition&gt;\\Microsoft\\Boot\\ - &lt;EFI System Partition&gt;\\Microsoft\\Boot\\
- &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\ - &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\

View File

@ -25,16 +25,16 @@ ms.localizationpriority: medium
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!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](feature-availability.md). >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
You should now have one or more WDAC policies broadly deployed in audit mode. You have analyzed events collected from the devices with those policies and you're ready to enforce. Use this procedure to prepare and deploy your WDAC policies in enforcement mode. You should now have one or more Windows Defender Application Control policies broadly deployed in audit mode. You have analyzed events collected from the devices with those policies and you're ready to enforce. Use this procedure to prepare and deploy your WDAC policies in enforcement mode.
> [!NOTE] > [!NOTE]
> Some of the steps described in this article only apply to 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. Evaluate the impact for any features that may be unavailable on your clients running earlier versions of Windows 10 and Windows Server. You may need to adapt this guidance to meet your specific organization's needs. > Some of the steps described in this article only apply to 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. Evaluate the impact for any features that may be unavailable on your clients running earlier versions of Windows 10 and Windows Server. You may need to adapt this guidance to meet your specific organization's needs.
## Convert WDAC **base** policy from audit to enforced ## Convert WDAC **base** policy from audit to enforced
As described in [common WDAC deployment scenarios](types-of-devices.md), 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. As described in [common Windows Defender Application Control deployment scenarios](types-of-devices.md), 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 responsible for Lamna's WDAC rollout. **Alice Pena** is the IT team lead responsible for Lamna's WDAC rollout.
@ -102,7 +102,7 @@ Since the enforced policy was given a unique PolicyID in the previous procedure,
> [!NOTE] > [!NOTE]
> If Set-CIPolicyIdInfo does not output the new PolicyID value on your Windows 10 version, you will need to obtain the *PolicyId* value from the XML directly. > If Set-CIPolicyIdInfo does not output the new PolicyID value on your Windows 10 version, you will need to obtain the *PolicyId* value from the XML directly.
3. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the new WDAC supplemental policy to binary: 3. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the new Windows Defender Application Control supplemental policy to binary:
```powershell ```powershell
$EnforcedSuppPolicyBinary = $env:USERPROFILE+"\Desktop\"+$SupplementalPolicyName+"_"+$SupplementalPolicyID+".xml" $EnforcedSuppPolicyBinary = $env:USERPROFILE+"\Desktop\"+$SupplementalPolicyName+"_"+$SupplementalPolicyID+".xml"

View File

@ -20,7 +20,7 @@ ms.technology: windows-sec
# Understanding Application Control event tags # Understanding Application Control event tags
Windows Defender Application Control (WDAC) events include a number of fields which provide helpful troubleshooting information to figure out exactly what an event means. Below, we have documented the values and meanings for a few useful event tags. Windows Defender Application Control (WDAC) events include many fields, which provide helpful troubleshooting information to figure out exactly what an event means. Below, we've documented the values and meanings for a few useful event tags.
## SignatureType ## SignatureType
@ -28,12 +28,12 @@ Represents the type of signature which verified the image.
| SignatureType Value | Explanation | | SignatureType Value | Explanation |
|---|----------| |---|----------|
| 0 | Unsigned or verification has not been attempted | | 0 | Unsigned or verification hasn't been attempted |
| 1 | Embedded signature | | 1 | Embedded signature |
| 2 | Cached signature; presence of CI EA shows that file had been previously verified | | 2 | Cached signature; presence of CI EA shows that file had been previously verified |
| 3 | Cached catalog verified via Catalog Database or searching catalog directly | | 3 | Cached catalog verified via Catalog Database or searching catalog directly |
| 4 | Un-cached catalog verified via Catalog Database or searching catalog directly | | 4 | Uncached catalog verified via Catalog Database or searching catalog directly |
| 5 | Successfully verified using an EA that informs CI which catalog to try first | | 5 | Successfully verified using an EA that informs CI that catalog to try first |
| 6 | AppX / MSIX package catalog verified | | 6 | AppX / MSIX package catalog verified |
| 7 | File was verified | | 7 | File was verified |
@ -43,9 +43,9 @@ Represents the signature level at which the code was verified.
| ValidatedSigningLevel Value | Explanation | | ValidatedSigningLevel Value | Explanation |
|---|----------| |---|----------|
| 0 | Signing level has not yet been checked | | 0 | Signing level hasn't yet been checked |
| 1 | File is unsigned | | 1 | File is unsigned |
| 2 | Trusted by WDAC policy | | 2 | Trusted by Windows Defender Application Control policy |
| 3 | Developer signed code | | 3 | Developer signed code |
| 4 | Authenticode signed | | 4 | Authenticode signed |
| 5 | Microsoft Store signed app PPL (Protected Process Light) | | 5 | Microsoft Store signed app PPL (Protected Process Light) |
@ -65,10 +65,10 @@ Represents why verification failed, or if it succeeded.
| 0 | Successfully verified signature | | 0 | Successfully verified signature |
| 1 | File has an invalid hash | | 1 | File has an invalid hash |
| 2 | File contains shared writable sections | | 2 | File contains shared writable sections |
| 3 | File is not signed| | 3 | File isn't signed|
| 4 | Revoked signature | | 4 | Revoked signature |
| 5 | Expired signature | | 5 | Expired signature |
| 6 | File is signed using a weak hashing algorithm which does not meet the minimum policy | | 6 | File is signed using a weak hashing algorithm, which doesn't meet the minimum policy |
| 7 | Invalid root certificate | | 7 | Invalid root certificate |
| 8 | Signature was unable to be validated; generic error | | 8 | Signature was unable to be validated; generic error |
| 9 | Signing time not trusted | | 9 | Signing time not trusted |
@ -83,7 +83,7 @@ Represents why verification failed, or if it succeeded.
| 18 | Custom signing level not met; returned if signature fails to match CISigners in UMCI | | 18 | Custom signing level not met; returned if signature fails to match CISigners in UMCI |
| 19 | Binary is revoked by file hash | | 19 | Binary is revoked by file hash |
| 20 | SHA1 cert hash's timestamp is missing or after valid cutoff as defined by Weak Crypto Policy | | 20 | SHA1 cert hash's timestamp is missing or after valid cutoff as defined by Weak Crypto Policy |
| 21 | Failed to pass WDAC policy | | 21 | Failed to pass Windows Defender Application Control policy |
| 22 | Not IUM (Isolated User Mode) signed; indicates trying to load a non-trustlet binary into a trustlet | | 22 | Not IUM (Isolated User Mode) signed; indicates trying to load a non-trustlet binary into a trustlet |
| 23 | Invalid image hash | | 23 | Invalid image hash |
| 24 | Flight root not allowed; indicates trying to run flight-signed code on production OS | | 24 | Flight root not allowed; indicates trying to run flight-signed code on production OS |
@ -119,7 +119,7 @@ The rule means trust anything signed by a certificate that chains to this root C
| 18 | Microsoft ECC Product Root CA 2018 | | 18 | Microsoft ECC Product Root CA 2018 |
| 19 | Microsoft ECC Devices Root CA 2017 | | 19 | Microsoft ECC Devices Root CA 2017 |
For well-known roots, the TBS hashes for the certificates are baked into the code for WDAC. For example, they dont need to be listed as TBS hashes in the policy file. For well-known roots, the TBS hashes for the certificates are baked into the code for Windows Defender Application Control. For example, they dont need to be listed as TBS hashes in the policy file.
## Status values ## Status values

View File

@ -28,7 +28,7 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!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](feature-availability.md). >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
When you create policies for use with Windows Defender Application Control (WDAC), start from an existing base policy and then add or remove rules to build your own custom policy. Windows includes several example policies that can be used, or organizations that use the Device Guard Signing Service can download a starter policy from that service. When you create policies for use with Windows Defender Application Control (WDAC), start from an existing base policy and then add or remove rules to build your own custom policy. Windows includes several example policies that can be used, or organizations that use the Device Guard Signing Service can download a starter policy from that service.
@ -39,7 +39,7 @@ When you create policies for use with Windows Defender Application Control (WDAC
| **DefaultWindows.xml** | This example policy is available in both audit and enforced mode. It includes rules to allow Windows, third-party hardware and software kernel drivers, and Windows Store apps. Used as the basis for all [Microsoft Endpoint Manager(MEM)](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager) policies. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies | | **DefaultWindows.xml** | This example policy is available in both audit and enforced mode. It includes rules to allow Windows, third-party hardware and software kernel drivers, and Windows Store apps. Used as the basis for all [Microsoft Endpoint Manager(MEM)](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager) policies. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
| **AllowMicrosoft.xml** | This example policy is available in audit mode. It includes the rules from DefaultWindows and adds rules to trust apps signed by the Microsoft product root certificate. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies | | **AllowMicrosoft.xml** | This example policy is available in audit mode. It includes the rules from DefaultWindows and adds rules to trust apps signed by the Microsoft product root certificate. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
| **AllowAll.xml** | This example policy is useful when creating a blocklist. All block policies should include rules allowing all other code to run and then add the DENY rules for your organization's needs. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies | | **AllowAll.xml** | This example policy is useful when creating a blocklist. All block policies should include rules allowing all other code to run and then add the DENY rules for your organization's needs. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
| **AllowAll_EnableHVCI.xml** | This example policy can be used to enable [memory integrity](/windows/security/threat-protection/device-guard/memory-integrity) (also known as hypervisor-protected code integrity) using WDAC. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies | | **AllowAll_EnableHVCI.xml** | This example policy can be used to enable [memory integrity](/windows/security/threat-protection/device-guard/memory-integrity) (also known as hypervisor-protected code integrity) using Windows Defender Application Control. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
| **DenyAllAudit.xml** | ***Warning: May cause long boot time on Windows Server 2019.*** Only deploy this example policy in audit mode to track all binaries running on critical systems or to meet regulatory requirements. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies | | **DenyAllAudit.xml** | ***Warning: May cause long boot time on Windows Server 2019.*** Only deploy this example policy in audit mode to track all binaries running on critical systems or to meet regulatory requirements. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
| **Device Guard Signing Service (DGSS) DefaultPolicy.xml** | This example policy is available in audit mode. It includes the rules from DefaultWindows and adds rules to trust apps signed with your organization-specific certificates issued by the DGSS. | [Device Guard Signing Service NuGet Package](https://www.nuget.org/packages/Microsoft.Acs.Dgss.Client) | | **Device Guard Signing Service (DGSS) DefaultPolicy.xml** | This example policy is available in audit mode. It includes the rules from DefaultWindows and adds rules to trust apps signed with your organization-specific certificates issued by the DGSS. | [Device Guard Signing Service NuGet Package](https://www.nuget.org/packages/Microsoft.Acs.Dgss.Client) |
| **MEM Configuration Manager** | Customers who use MEM Configuration Manager (MEMCM) can deploy a policy with MEMCM's built-in WDAC integration, and then use the generated policy XML as an example base policy. | %OSDrive%\Windows\CCM\DeviceGuard on a managed endpoint | | **MEM Configuration Manager** | Customers who use MEM Configuration Manager (MEMCM) can deploy a policy with MEMCM's built-in WDAC integration, and then use the generated policy XML as an example base policy. | %OSDrive%\Windows\CCM\DeviceGuard on a managed endpoint |

View File

@ -1,6 +1,6 @@
--- ---
title: Windows Defender Application Control Feature Availability title: Windows Defender Application Control Feature Availability
description: Compare WDAC and AppLocker feature availability. description: Compare Windows Defender Application Control (WDAC) and AppLocker feature availability.
keywords: security, malware keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security ms.prod: m365-security
@ -30,7 +30,7 @@ ms.technology: windows-sec
>[!NOTE] >[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. See below to learn more. >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. See below to learn more.
| Capability | WDAC | AppLocker | | Capability | Windows Defender Application Control | AppLocker |
|-------------|------|-------------| |-------------|------|-------------|
| Platform support | Available on Windows 10, Windows 11, and Windows Server 2016 or later | Available on Windows 8 or later | | Platform support | Available on Windows 10, Windows 11, and Windows Server 2016 or later | Available on Windows 8 or later |
| SKU availability | Cmdlets are available on all SKUs on 1909+ builds.<br>For pre-1909 builds, cmdlets are only available on Enterprise but policies are effective on all SKUs. | Policies deployed through GP are only effective on Enterprise devices.<br>Policies deployed through MDM are effective on all SKUs. | | SKU availability | Cmdlets are available on all SKUs on 1909+ builds.<br>For pre-1909 builds, cmdlets are only available on Enterprise but policies are effective on all SKUs. | Policies deployed through GP are only effective on Enterprise devices.<br>Policies deployed through MDM are effective on all SKUs. |

View File

@ -27,27 +27,27 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!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](feature-availability.md). >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
This topic for IT professionals describes concepts and lists procedures to help you manage packaged apps with Windows Defender Application Control (WDAC) as part of your overall application control strategy. This topic for IT professionals describes concepts and lists procedures to help you manage packaged apps with Windows Defender Application Control (WDAC) as part of your overall application control strategy.
## Understanding Packaged Apps and Packaged App Installers ## Understanding Packaged Apps and Packaged App Installers
Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an app package share the same identity. With classic Windows apps, each file within the app could have a unique identity. Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an app package share the same identity. With classic Windows apps, each file within the app could have a unique identity.
With packaged apps, it is possible to control the entire app by using a single WDAC rule. With packaged apps, it is possible to control the entire app by using a single Windows Defender Application Control rule.
Typically, an app consists of multiple components: the installer that is used to install the app, and one or more exes, dlls, or scripts. With classic Windows apps, these components don't always share common attributes such as the softwares publisher name, product name, and product version. Therefore, WDAC controls each of these components separately through different rule collections, such as exe, dll, script, and Windows Installer rules. In contrast, all the components of a packaged app share the same publisher name, package name, and package version attributes. Therefore, you can control an entire app with a single rule. Typically, an app consists of multiple components: the installer that is used to install the app, and one or more exes, dlls, or scripts. With classic Windows apps, these components don't always share common attributes such as the softwares publisher name, product name, and product version. Therefore, Windows Defender Application Control controls each of these components separately through different rule collections, such as exe, dll, script, and Windows Installer rules. In contrast, all the components of a packaged app share the same publisher name, package name, and package version attributes. Therefore, you can control an entire app with a single rule.
### <a href="" id="bkmk-compareclassicmetro"></a>Comparing classic Windows Apps and Packaged Apps ### <a href="" id="bkmk-compareclassicmetro"></a>Comparing classic Windows Apps and Packaged Apps
WDAC policies for packaged apps can only be applied to apps installed on computers running at least Windows Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least Windows Server Windows Defender Application Control policies for packaged apps can only be applied to apps installed on computers running at least Windows Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least Windows Server
2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be enforced in tandem. The differences between packaged apps and classic Windows apps that you should consider include: 2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be enforced in tandem. The differences between packaged apps and classic Windows apps that you should consider include:
- **Installing the apps**   All packaged apps can be installed by a standard user, whereas a number of classic Windows apps require administrative privileges to install. In an environment where most of the users are standard users, you might not have numerous exe rules (because classic Windows apps require administrative privileges to install), but you might want to have more explicit policies for packaged apps. - **Installing the apps**   All packaged apps can be installed by a standard user, whereas a number of classic Windows apps require administrative privileges to install. In an environment where most of the users are standard users, you might not have numerous exe rules (because classic Windows apps require administrative privileges to install), but you might want to have more explicit policies for packaged apps.
- **Changing the system state**   Classic Windows apps can be written to change the system state if they are run with administrative privileges. Most packaged apps cannot change the system state because they run with limited privileges. When you design your WDAC policies, it is important to understand whether an app that you are allowing can make system-wide changes. - **Changing the system state**   Classic Windows apps can be written to change the system state if they are run with administrative privileges. Most packaged apps cannot change the system state because they run with limited privileges. When you design your Windows Defender Application Control policies, it is important to understand whether an app that you are allowing can make system-wide changes.
- **Acquiring the apps**   Packaged apps can be acquired through the Store, or by loading using Windows PowerShell cmdlets (which requires a special enterprise license). Classic Windows apps can be acquired through traditional means. - **Acquiring the apps**   Packaged apps can be acquired through the Store, or by loading using Windows PowerShell cmdlets (which requires a special enterprise license). Classic Windows apps can be acquired through traditional means.
WDAC uses different rule collections to control packaged apps and classic Windows apps. You have the choice to control one type, the other type, or both. Windows Defender Application Control uses different rule collections to control packaged apps and classic Windows apps. You have the choice to control one type, the other type, or both.
## Using WDAC to Manage Packaged Apps ## Using WDAC to Manage Packaged Apps
@ -55,7 +55,7 @@ Just as there are differences in managing each rule collection, you need to mana
1. Gather information about which packaged apps are running in your environment. 1. Gather information about which packaged apps are running in your environment.
2. Create WDAC rules for specific packaged apps based on your policy strategies. For more information, see [Deploy WDAC policy rules and file rules](select-types-of-rules-to-create.md). 2. Create WDAC rules for specific packaged apps based on your policy strategies. For more information, see [Deploy Windows Defender Application Control policy (WDAC) rules and file rules](select-types-of-rules-to-create.md).
3. Continue to update the WDAC policies as new package apps are introduced into your environment. To do this, see [Merge WDAC policies](merge-windows-defender-application-control-policies.md). 3. Continue to update the WDAC policies as new package apps are introduced into your environment. To do this, see [Merge WDAC policies](merge-windows-defender-application-control-policies.md).

View File

@ -25,16 +25,16 @@ ms.localizationpriority: medium
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!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](feature-availability.md). >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
This article shows how to merge multiple policy XML files together and how to merge rules directly into a policy. WDAC deployments often include a few base policies and optional supplemental policies for specific use cases. This article shows how to merge multiple policy XML files together and how to merge rules directly into a policy. Windows Defender Application Control deployments often include a few base policies and optional supplemental policies for specific use cases.
> [!NOTE] > [!NOTE]
> Prior to Windows version 1903, including Windows Server 2019 and earlier, only one WDAC policy can be active on a system at a time. If you need to use WDAC on systems running these earlier versions of Windows, you must merge all policies before deploying. > Prior to Windows version 1903, including Windows Server 2019 and earlier, only one Windows Defender Application Control policy can be active on a system at a time. If you need to use WDAC on systems running these earlier versions of Windows, you must merge all policies before deploying.
## Merge multiple WDAC policy XML files together ## Merge multiple WDAC policy XML files together
There are many scenarios where you may want to merge two or more policy files together. For example, if you [use audit events to create WDAC policy rules](audit-windows-defender-application-control-policies.md), you can merge those rules with your existing WDAC base policy. To merge the two WDAC policies referenced in that article, complete the following steps in an elevated Windows PowerShell session. There are many scenarios where you may want to merge two or more policy files together. For example, if you [use audit events to create Windows Defender Application Control policy rules](audit-windows-defender-application-control-policies.md), you can merge those rules with your existing WDAC base policy. To merge the two WDAC policies referenced in that article, complete the following steps in an elevated Windows PowerShell session.
1. Initialize the variables that will be used: 1. Initialize the variables that will be used:
@ -45,7 +45,7 @@ There are many scenarios where you may want to merge two or more policy files to
$MergedPolicy=$env:userprofile+"\Desktop\"+$PolicyName+"_Merged.xml" $MergedPolicy=$env:userprofile+"\Desktop\"+$PolicyName+"_Merged.xml"
``` ```
2. Use [Merge-CIPolicy](/powershell/module/configci/merge-cipolicy) to merge two policies and create a new WDAC policy: 2. Use [Merge-CIPolicy](/powershell/module/configci/merge-cipolicy) to merge two policies and create a new Windows Defender Application Control policy:
```powershell ```powershell
Merge-CIPolicy -PolicyPaths $LamnaPolicy,$EventsPolicy -OutputFilePath $MergedPolicy Merge-CIPolicy -PolicyPaths $LamnaPolicy,$EventsPolicy -OutputFilePath $MergedPolicy
@ -93,6 +93,6 @@ Now that you have your new, merged policy, you can convert and deploy the policy
> [!NOTE] > [!NOTE]
> In the sample commands above, for policies targeting Windows 10 version 1903+ or Windows 11, replace the string "{InsertPolicyID}" with the actual PolicyID GUID (including braces **{ }**) found in your policy XML file. For Windows 10 versions prior to 1903, use the name SiPolicy.p7b for the binary file name. > In the sample commands above, for policies targeting Windows 10 version 1903+ or Windows 11, replace the string "{InsertPolicyID}" with the actual PolicyID GUID (including braces **{ }**) found in your policy XML file. For Windows 10 versions prior to 1903, use the name SiPolicy.p7b for the binary file name.
2. Upload your merged policy XML and the associated binary to the source control solution you are using for your WDAC policies. such as [GitHub](https://github.com/) or a document management solution such as [Office 365 SharePoint](https://products.office.com/sharepoint/collaboration). 2. Upload your merged policy XML and the associated binary to the source control solution you are using for your Windows Defender Application Control policies. such as [GitHub](https://github.com/) or a document management solution such as [Office 365 SharePoint](https://products.office.com/sharepoint/collaboration).
3. Deploy the merged policy using your preferred deployment solution. See [Deploying Windows Defender Application Control (WDAC) policies](windows-defender-application-control-deployment-guide.md) 3. Deploy the merged policy using your preferred deployment solution. See [Deploying Windows Defender Application Control (WDAC) policies](windows-defender-application-control-deployment-guide.md)

View File

@ -28,12 +28,11 @@ ms.localizationpriority: medium
>[!NOTE] >[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability). >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic covers tips and tricks for admins as well as known issues with WDAC. This topic covers tips and tricks for admins as well as known issues with Windows Defender Application Control (WDAC). Test this configuration in your lab before enabling it in production.
Test this configuration in your lab before enabling it in production.
## .NET native images may generate false positive block events ## .NET native images may generate false positive block events
In some cases, the code integrity logs where WDAC errors and warnings are written will contain error events for native images generated for .NET assemblies. Typically, native image blocks are functionally benign as a blocked native image will fallback to its corresponding assembly and .NET will regenerate the native image at its next scheduled maintenance window. In some cases, the code integrity logs where Windows Defender Application Control errors and warnings are written will contain error events for native images generated for .NET assemblies. Typically, native image blocks are functionally benign as a blocked native image will fallback to its corresponding assembly and .NET will regenerate the native image at its next scheduled maintenance window.
## MSI Installations launched directly from the internet are blocked by WDAC ## MSI Installations launched directly from the internet are blocked by WDAC

View File

@ -27,15 +27,15 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!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](feature-availability.md). >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
This topic describes the decisions you need to make to establish the processes for managing and maintaining Windows Defender Application Control (WDAC) policies. This topic describes the decisions you need to make to establish the processes for managing and maintaining Windows Defender Application Control (WDAC) policies.
## Policy XML lifecycle management ## Policy XML lifecycle management
The first step in implementing application control is to consider how your policies will be managed and maintained over time. Developing a process for managing WDAC policies helps ensure that WDAC continues to effectively control how applications are allowed to run in your organization. The first step in implementing application control is to consider how your policies will be managed and maintained over time. Developing a process for managing Windows Defender Application Control policies helps ensure that WDAC continues to effectively control how applications are allowed to run in your organization.
Most WDAC policies will evolve over time and proceed through a set of identifiable phases during their lifetime. Typically, these phases include: Most Windows Defender Application Control policies will evolve over time and proceed through a set of identifiable phases during their lifetime. Typically, these phases include:
1. [Define (or refine) the "circle-of-trust"](understand-windows-defender-application-control-policy-design-decisions.md) for the policy and build an audit mode version of the policy XML. In audit mode, block events are generated but files are not prevented from executing. 1. [Define (or refine) the "circle-of-trust"](understand-windows-defender-application-control-policy-design-decisions.md) for the policy and build an audit mode version of the policy XML. In audit mode, block events are generated but files are not prevented from executing.
2. Deploy the audit mode policy to intended devices. 2. Deploy the audit mode policy to intended devices.
@ -49,11 +49,11 @@ Most WDAC policies will evolve over time and proceed through a set of identifiab
### Keep WDAC policies in a source control or document management solution ### Keep WDAC policies in a source control or document management solution
To effectively manage WDAC policies, you should store and maintain your policy XML documents in a central repository that is accessible to everyone responsible for WDAC policy management. We recommend a source control solution such as [GitHub](https://github.com/) or a document management solution such as [Office 365 SharePoint](https://products.office.com/sharepoint/collaboration), which provide version control and allow you to specify metadata about the XML documents. To effectively manage Windows Defender Application Control policies, you should store and maintain your policy XML documents in a central repository that is accessible to everyone responsible for WDAC policy management. We recommend a source control solution such as [GitHub](https://github.com/) or a document management solution such as [Office 365 SharePoint](https://products.office.com/sharepoint/collaboration), which provide version control and allow you to specify metadata about the XML documents.
### Set PolicyName, PolicyID, and Version metadata for each policy ### Set PolicyName, PolicyID, and Version metadata for each policy
Use the [Set-CIPolicyIDInfo](/powershell/module/configci/set-cipolicyidinfo) cmdlet to give each policy a descriptive name and set a unique ID in order to differentiate each policy when reviewing WDAC events or when viewing the policy XML document. Although you can specify a string value for PolicyId, for policies using the multiple policy format we recommend using the -ResetPolicyId switch to let the system autogenerate a unique ID for the policy. Use the [Set-CIPolicyIDInfo](/powershell/module/configci/set-cipolicyidinfo) cmdlet to give each policy a descriptive name and set a unique ID in order to differentiate each policy when reviewing Windows Defender Application Control events or when viewing the policy XML document. Although you can specify a string value for PolicyId, for policies using the multiple policy format we recommend using the -ResetPolicyId switch to let the system autogenerate a unique ID for the policy.
> [!NOTE] > [!NOTE]
> PolicyID only applies to policies using the [multiple policy format](deploy-multiple-windows-defender-application-control-policies.md) on computers running Windows 10, version 1903 and above, or Windows 11. Running -ResetPolicyId on a policy created for pre-1903 computers will convert it to multiple policy format and prevent it from running on those earlier versions of Windows 10. > PolicyID only applies to policies using the [multiple policy format](deploy-multiple-windows-defender-application-control-policies.md) on computers running Windows 10, version 1903 and above, or Windows 11. Running -ResetPolicyId on a policy created for pre-1903 computers will convert it to multiple policy format and prevent it from running on those earlier versions of Windows 10.
@ -67,11 +67,11 @@ As new apps are deployed or existing apps are updated by the software publisher,
## WDAC event management ## WDAC event management
Each time that a process is blocked by WDAC, events will be written to either the CodeIntegrity\Operational or the AppLocker\MSI and Script Windows event logs. The event details which file tried to run, the attributes of that file and its signatures, and the process that attempted to run the blocked file. Each time that a process is blocked by Windows Defender Application Control, events will be written to either the CodeIntegrity\Operational or the AppLocker\MSI and Script Windows event logs. The event details which file tried to run, the attributes of that file and its signatures, and the process that attempted to run the blocked file.
Collecting these events in a central location can help you maintain your WDAC policy and troubleshoot rule configuration problems. Event collection technologies such as those available in Windows allow administrators to subscribe to specific event channels and have the events from source computers aggregated into a forwarded event log on a Windows Server operating system collector. For more info about setting up an event subscription, see [Configure Computers to Collect and Forward Events](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc748890(v=ws.11)). Collecting these events in a central location can help you maintain your Windows Defender Application Control policy and troubleshoot rule configuration problems. Event collection technologies such as those available in Windows allow administrators to subscribe to specific event channels and have the events from source computers aggregated into a forwarded event log on a Windows Server operating system collector. For more info about setting up an event subscription, see [Configure Computers to Collect and Forward Events](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc748890(v=ws.11)).
Additionally, WDAC events are collected by [Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint) and can be queried using the [advanced hunting](querying-application-control-events-centrally-using-advanced-hunting.md) feature. Additionally, Windows Defender Application Control events are collected by [Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint) and can be queried using the [advanced hunting](querying-application-control-events-centrally-using-advanced-hunting.md) feature.
## Application and user support policy ## Application and user support policy
@ -84,24 +84,24 @@ Considerations include:
### Help desk support ### Help desk support
If your organization has an established help desk support department in place, consider the following when deploying WDAC policies: If your organization has an established help desk support department in place, consider the following when deploying Windows Defender Application Control policies:
- What documentation does your support department require for new policy deployments? - What documentation does your support department require for new policy deployments?
- What are the critical processes in each business group both in work flow and timing that will be affected by application control policies and how could they affect your support department's workload? - What are the critical processes in each business group both in work flow and timing that will be affected by application control policies and how could they affect your support department's workload?
- Who are the contacts in the support department? - Who are the contacts in the support department?
- How will the support department resolve application control issues between the end user and those who maintain the WDAC rules? - How will the support department resolve application control issues between the end user and those who maintain the Windows Defender Application Control rules?
### End-user support ### End-user support
Because WDAC is preventing unapproved apps from running, it is important that your organization carefully plan how to provide end-user support. Considerations include: Because Windows Defender Application Control is preventing unapproved apps from running, it is important that your organization carefully plan how to provide end-user support. Considerations include:
- Do you want to use an intranet site as a first line of support for users who have tried to run a blocked app? - Do you want to use an intranet site as a first line of support for users who have tried to run a blocked app?
- How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily allow access to a blocked app? - How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily allow access to a blocked app?
## Document your plan ## Document your plan
After deciding how your organization will manage your WDAC policy, record your findings. After deciding how your organization will manage your Windows Defender Application Control policy, record your findings.
- **End-user support policy.** Document the process that you will use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel have clear escalation steps so that the administrator can update the WDAC policy, if necessary. - **End-user support policy.** Document the process that you will use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel have clear escalation steps so that the administrator can update the Windows Defender Application Control policy, if necessary.
- **Event processing.** Document whether events will be collected in a central location called a store, how that store will be archived, and whether the events will be processed for analysis. - **Event processing.** Document whether events will be collected in a central location called a store, how that store will be archived, and whether the events will be processed for analysis.
- **Policy management.** Detail what policies are planned, how they will be managed, and how rules will be maintained over time. - **Policy management.** Detail what policies are planned, how they will be managed, and how rules will be maintained over time.

View File

@ -34,8 +34,8 @@ This capability is supported beginning with Windows version 1607.
| - | - | - | | - | - | - |
| AppControlCodeIntegrityDriverRevoked | 3023 | The driver file under validation didn't meet the requirements to pass the application control policy. | | AppControlCodeIntegrityDriverRevoked | 3023 | The driver file under validation didn't meet the requirements to pass the application control policy. |
| AppControlCodeIntegrityImageRevoked | 3036 | The signed file under validation is signed by a code signing certificate that has been revoked by Microsoft or the certificate issuing authority. | | AppControlCodeIntegrityImageRevoked | 3036 | The signed file under validation is signed by a code signing certificate that has been revoked by Microsoft or the certificate issuing authority. |
| AppControlCodeIntegrityPolicyAudited | 3076 | This event is the main WDAC block event for audit mode policies. It indicates the file would have been blocked if the WDAC policy was enforced. | | AppControlCodeIntegrityPolicyAudited | 3076 | This event is the main Windows Defender Application Control block event for audit mode policies. It indicates the file would have been blocked if the WDAC policy was enforced. |
| AppControlCodeIntegrityPolicyBlocked | 3077 | This event is the main WDAC block event for enforced policies. It indicates the file didn't pass your WDAC policy and was blocked. | | AppControlCodeIntegrityPolicyBlocked | 3077 | This event is the main Windows Defender Application Control block event for enforced policies. It indicates the file didn't pass your WDAC policy and was blocked. |
| AppControlExecutableAudited | 8003 | Applied only when the Audit only enforcement mode is enabled. Specifies the .exe or .dll file would be blocked if the Enforce rules enforcement mode were enabled. | | AppControlExecutableAudited | 8003 | Applied only when the Audit only enforcement mode is enabled. Specifies the .exe or .dll file would be blocked if the Enforce rules enforcement mode were enabled. |
| AppControlExecutableBlocked | 8004 | The .exe or .dll file can't run. | | AppControlExecutableBlocked | 8004 | The .exe or .dll file can't run. |
| AppControlPackagedAppAudited | 8021 | Applied only when the Audit only enforcement mode is enabled. Specifies the packaged app would be blocked if the Enforce rules enforcement mode were enabled. | | AppControlPackagedAppAudited | 8021 | Applied only when the Audit only enforcement mode is enabled. Specifies the packaged app would be blocked if the Enforce rules enforcement mode were enabled. |
@ -57,7 +57,7 @@ Learn more about the [Understanding Application Control event IDs (Windows)](eve
Query Example 1: Query the application control action types summarized by type for past seven days Query Example 1: Query the application control action types summarized by type for past seven days
Here's a simple example query that shows all the WDAC events generated in the last seven days from machines being monitored by Microsoft Defender for Endpoint: Here's a simple example query that shows all the Windows Defender Application Control events generated in the last seven days from machines being monitored by Microsoft Defender for Endpoint:
``` ```
DeviceEvents DeviceEvents
@ -67,7 +67,7 @@ ActionType startswith "AppControl"
| order by Machines desc | order by Machines desc
``` ```
The query results can be used for several important functions related to managing WDAC including: The query results can be used for several important functions related to managing Windows Defender Application Control including:
- Assessing the impact of deploying policies in audit mode - Assessing the impact of deploying policies in audit mode
Since applications still run in audit mode, it's an ideal way to see the impact and correctness of the rules included in the policy. Integrating the generated events with Advanced Hunting makes it much easier to have broad deployments of audit mode policies and see how the included rules would influence those systems in real world usage. This audit mode data will help streamline the transition to using policies in enforced mode. Since applications still run in audit mode, it's an ideal way to see the impact and correctness of the rules included in the policy. Integrating the generated events with Advanced Hunting makes it much easier to have broad deployments of audit mode policies and see how the included rules would influence those systems in real world usage. This audit mode data will help streamline the transition to using policies in enforced mode.

View File

@ -31,11 +31,11 @@ ms.technology: windows-sec
Windows Defender Application Control (WDAC) can control what runs on Windows 10 and Windows 11, by setting policies that specify whether a driver or application is trusted. A policy includes *policy rules* that control options such as audit mode, and *file rules* (or *file rule levels*) that specify how applications are identified and trusted. Windows Defender Application Control (WDAC) can control what runs on Windows 10 and Windows 11, by setting policies that specify whether a driver or application is trusted. A policy includes *policy rules* that control options such as audit mode, and *file rules* (or *file rule levels*) that specify how applications are identified and trusted.
WDAC is used to restrict devices to run only approved apps, while the operating system is hardened against kernel memory attacks using [hypervisor-protected code integrity (HVCI)](/windows/security/threat-protection/device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control). Windows Defender Application Control is used to restrict devices to run only approved apps, while the operating system is hardened against kernel memory attacks using [hypervisor-protected code integrity (HVCI)](/windows/security/threat-protection/device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control).
## Windows Defender Application Control policy rules ## Windows Defender Application Control policy rules
To modify the policy rule options of an existing WDAC policy XML, use [Set-RuleOption](/powershell/module/configci/set-ruleoption). The following examples show how to use this cmdlet to add and remove a rule option on an existing WDAC policy: To modify the policy rule options of an existing Windows Defender Application Control policy XML, use [Set-RuleOption](/powershell/module/configci/set-ruleoption). The following examples show how to use this cmdlet to add and remove a rule option on an existing WDAC policy:
- To ensure that UMCI is enabled for a WDAC policy that was created with the `-UserPEs` (user mode) option, add rule option 0 to an existing policy, by running the following command: - To ensure that UMCI is enabled for a WDAC policy that was created with the `-UserPEs` (user mode) option, add rule option 0 to an existing policy, by running the following command:
@ -50,7 +50,7 @@ To modify the policy rule options of an existing WDAC policy XML, use [Set-RuleO
You can set several rule options within a WDAC policy. Table 1 describes each rule option, and whether they have supplemental policies. However, option 5 isn't implemented as it's reserved for future work, and option 7 isn't supported. You can set several rule options within a WDAC policy. Table 1 describes each rule option, and whether they have supplemental policies. However, option 5 isn't implemented as it's reserved for future work, and option 7 isn't supported.
> [!NOTE] > [!NOTE]
> We recommend that you use **Enabled:Audit Mode** initially because it allows you to test new WDAC policies before you enforce them. With audit mode, no application is blocked—instead the policy logs an event whenever an application outside the policy is started. To allow these applications, you can capture the policy information from the event log, and then merge that information into the existing policy. When the **Enabled:Audit Mode** is deleted, the policy runs in enforced mode. > We recommend that you use **Enabled:Audit Mode** initially because it allows you to test new Windows Defender Application Control policies before you enforce them. With audit mode, no application is blocked—instead the policy logs an event whenever an application outside the policy is started. To allow these applications, you can capture the policy information from the event log, and then merge that information into the existing policy. When the **Enabled:Audit Mode** is deleted, the policy runs in enforced mode.
### Table 1. Windows Defender Application Control policy - policy rule options ### Table 1. Windows Defender Application Control policy - policy rule options
@ -94,7 +94,7 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
| **SignedVersion** | This level combines the publisher rule with a version number. It allows anything to run from the specified publisher with a version at or above the specified version number. | | **SignedVersion** | This level combines the publisher rule with a version number. It allows anything to run from the specified publisher with a version at or above the specified version number. |
| **Publisher** | This level combines the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. You can use this rule level to trust a certificate issued by a particular CA and issued to a specific company you trust (such as Intel, for device drivers). | | **Publisher** | This level combines the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. You can use this rule level to trust a certificate issued by a particular CA and issued to a specific company you trust (such as Intel, for device drivers). |
| **FilePublisher** | This level combines the “FileName” attribute of the signed file, plus “Publisher” (PCA certificate with CN of leaf), plus a minimum version number. This option trusts specific files from the specified publisher, with a version at or above the specified version number. | | **FilePublisher** | This level combines the “FileName” attribute of the signed file, plus “Publisher” (PCA certificate with CN of leaf), plus a minimum version number. This option trusts specific files from the specified publisher, with a version at or above the specified version number. |
| **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. Using this level, no policy update would be needed to run the new version of the application. However, leaf certificates have much shorter validity periods than other certificate levels, so the WDAC policy must be updated whenever these certificates change. | | **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. Using this level, no policy update would be needed to run the new version of the application. However, leaf certificates have much shorter validity periods than other certificate levels, so the Windows Defender Application Control policy must be updated whenever these certificates change. |
| **PcaCertificate** | Adds the highest available certificate in the provided certificate chain to signers. This level is typically one certificate below the root certificate because the scan doesn't validate anything beyond the certificates included in the provided signature (it doesn't go online or check local root stores). | | **PcaCertificate** | Adds the highest available certificate in the provided certificate chain to signers. This level is typically one certificate below the root certificate because the scan doesn't validate anything beyond the certificates included in the provided signature (it doesn't go online or check local root stores). |
| **RootCertificate** | Currently unsupported. | | **RootCertificate** | Currently unsupported. |
| **WHQL** | Trusts binaries if they've been validated and signed by WHQL. This level is primarily for kernel binaries. | | **WHQL** | Trusts binaries if they've been validated and signed by WHQL. This level is primarily for kernel binaries. |
@ -102,7 +102,7 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
| **WHQLFilePublisher** | Specifies that the binaries are validated and signed by WHQL, with a specific publisher (WHQLPublisher), and that the binary is the specified version or newer. This level is primarily for kernel binaries. | | **WHQLFilePublisher** | Specifies that the binaries are validated and signed by WHQL, with a specific publisher (WHQLPublisher), and that the binary is the specified version or newer. This level is primarily for kernel binaries. |
> [!NOTE] > [!NOTE]
> When you create WDAC policies with [New-CIPolicy](/powershell/module/configci/new-cipolicy), you can specify a primary file rule level, by including the **-Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **-Fallback** parameter. For example, if the primary file rule level is PCACertificate, but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate. > When you create Windows Defender Application Control policies with [New-CIPolicy](/powershell/module/configci/new-cipolicy), you can specify a primary file rule level, by including the **-Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **-Fallback** parameter. For example, if the primary file rule level is PCACertificate, but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate.
> [!NOTE] > [!NOTE]
> - WDAC only supports signer rules for RSA certificate signing keys with a maximum of 4096 bits. > - WDAC only supports signer rules for RSA certificate signing keys with a maximum of 4096 bits.
@ -112,19 +112,19 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
For example, consider an IT professional in a department that runs many servers. They only want to run software signed by the companies that provide their hardware, operating system, antivirus, and other important software. They know that their servers also run an internally written application that is unsigned but is rarely updated. They want to allow this application to run. For example, consider an IT professional in a department that runs many servers. They only want to run software signed by the companies that provide their hardware, operating system, antivirus, and other important software. They know that their servers also run an internally written application that is unsigned but is rarely updated. They want to allow this application to run.
To create the WDAC policy, they build a reference server on their standard hardware, and install all of the software that their servers are known to run. Then they run [New-CIPolicy](/powershell/module/configci/new-cipolicy) with **-Level Publisher** (to allow software from their software providers, the "Publishers") and **-Fallback Hash** (to allow the internal, unsigned application). They deploy the policy in auditing mode to determine the potential impact from enforcing the policy. Using the audit data, they update their WDAC policies to include any additional software they want to run. Then they enable the WDAC policy in enforced mode for their servers. To create the Windows Defender Application Control policy, they build a reference server on their standard hardware, and install all of the software that their servers are known to run. Then they run [New-CIPolicy](/powershell/module/configci/new-cipolicy) with **-Level Publisher** (to allow software from their software providers, the "Publishers") and **-Fallback Hash** (to allow the internal, unsigned application). They deploy the policy in auditing mode to determine the potential impact from enforcing the policy. Using the audit data, they update their WDAC policies to include any additional software they want to run. Then they enable the WDAC policy in enforced mode for their servers.
As part of normal operations, they'll eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they won't need to update their WDAC policy. If the unsigned, internal application is updated, they must also update the WDAC policy to allow the new version. As part of normal operations, they'll eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they won't need to update their WDAC policy. If the unsigned, internal application is updated, they must also update the WDAC policy to allow the new version.
## File rule precedence order ## File rule precedence order
WDAC has a built-in file rule conflict logic that translates to precedence order. It will first process all explicit deny rules it finds. Then, it will process all explicit allow rules. If no deny or allow rule exists, WDAC will check for [Managed Installer EA](deployment/deploy-wdac-policies-with-memcm.md). Lastly, if none of these exist, WDAC will fall back on [ISG](use-windows-defender-application-control-with-intelligent-security-graph.md). Windows Defender Application Control has a built-in file rule conflict logic that translates to precedence order. It will first process all explicit deny rules it finds. Then, it will process all explicit allow rules. If no deny or allow rule exists, WDAC will check for [Managed Installer EA](deployment/deploy-wdac-policies-with-memcm.md). Lastly, if none of these exist, WDAC will fall back on [ISG](use-windows-defender-application-control-with-intelligent-security-graph.md).
## More information about filepath rules ## More information about filepath rules
Filepath rules don't provide the same security guarantees that explicit signer rules do, since they're based on mutable access permissions. Filepath rules are best suited for environments where most users are running as standard rather than admin. Path rules are best suited to allow paths that you expect will remain admin-writeable only. You may want to avoid path rules for directories where standard users can modify ACLs on the folder. Filepath rules don't provide the same security guarantees that explicit signer rules do, since they're based on mutable access permissions. Filepath rules are best suited for environments where most users are running as standard rather than admin. Path rules are best suited to allow paths that you expect will remain admin-writeable only. You may want to avoid path rules for directories where standard users can modify ACLs on the folder.
By default, WDAC performs a user-writeability check at runtime that ensures that the current permissions on the specified filepath and its parent directories (recursively) don't allow standard users write access. By default, Windows Defender Application Control performs a user-writeability check at runtime that ensures that the current permissions on the specified filepath and its parent directories (recursively) don't allow standard users write access.
There's a defined list of SIDs that WDAC recognizes as admins. If a filepath allows write permissions for any SID not in this list, the filepath is considered to be user-writeable, even if the SID is associated to a custom admin user. To handle these special cases, you can override WDAC's runtime admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option described above. There's a defined list of SIDs that WDAC recognizes as admins. If a filepath allows write permissions for any SID not in this list, the filepath is considered to be user-writeable, even if the SID is associated to a custom admin user. To handle these special cases, you can override WDAC's runtime admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option described above.

View File

@ -27,7 +27,7 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
> [!NOTE] > [!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](feature-availability.md). > Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
Typically, deployment of Windows Defender Application Control (WDAC) happens best in phases, rather than being a feature that you simply “turn on.” The choice and sequence of phases depends on the way various computers and other devices are used in your organization, and to what degree IT manages those devices. The following table can help you begin to develop a plan for deploying WDAC in your organization. It is common for organizations to have device use cases across each of the categories described. Typically, deployment of Windows Defender Application Control (WDAC) happens best in phases, rather than being a feature that you simply “turn on.” The choice and sequence of phases depends on the way various computers and other devices are used in your organization, and to what degree IT manages those devices. The following table can help you begin to develop a plan for deploying WDAC in your organization. It is common for organizations to have device use cases across each of the categories described.
@ -35,10 +35,10 @@ Typically, deployment of Windows Defender Application Control (WDAC) happens bes
| **Type of device** | **How WDAC relates to this type of device** | | **Type of device** | **How WDAC relates to this type of device** |
|------------------------------------|------------------------------------------------------| |------------------------------------|------------------------------------------------------|
| **Lightly managed devices**: Company-owned, but users are free to install software.<br>Devices are required to run organization's antivirus solution and client management tools. | WDAC can be used to help protect the kernel, and to monitor (audit) for problem applications rather than limiting the applications that can be run. | | **Lightly managed devices**: Company-owned, but users are free to install software.<br>Devices are required to run organization's antivirus solution and client management tools. | Windows Defender Application Control can be used to help protect the kernel, and to monitor (audit) for problem applications rather than limiting the applications that can be run. |
| **Fully managed devices**: Allowed software is restricted by IT department.<br>Users can request additional software, or install from a list of applications provided by IT department.<br>Examples: locked-down, company-owned desktops and laptops. | An initial baseline WDAC policy can be established and enforced. Whenever the IT department approves additional applications, it will update the WDAC policy and (for unsigned LOB applications) the catalog.<br>WDAC policies are supported by the HVCI service. | | **Fully managed devices**: Allowed software is restricted by IT department.<br>Users can request additional software, or install from a list of applications provided by IT department.<br>Examples: locked-down, company-owned desktops and laptops. | An initial baseline Windows Defender Application Control policy can be established and enforced. Whenever the IT department approves additional applications, it will update the WDAC policy and (for unsigned LOB applications) the catalog.<br>WDAC policies are supported by the HVCI service. |
| **Fixed-workload devices**: Perform same tasks every day.<br>Lists of approved applications rarely change.<br>Examples: kiosks, point-of-sale systems, call center computers. | WDAC can be deployed fully, and deployment and ongoing administration are relatively straightforward.<br>After WDAC deployment, only approved applications can run. This is because of protections offered by WDAC. | | **Fixed-workload devices**: Perform same tasks every day.<br>Lists of approved applications rarely change.<br>Examples: kiosks, point-of-sale systems, call center computers. | Windows Defender Application Control can be deployed fully, and deployment and ongoing administration are relatively straightforward.<br>After Windows Defender Application Control deployment, only approved applications can run. This is because of protections offered by WDAC. |
| **Bring Your Own Device**: Employees are allowed to bring their own devices, and also use those devices away from work. | In most cases, WDAC does not apply. Instead, you can explore other hardening and security features with MDM-based conditional access solutions, such as Microsoft Intune. However, you may choose to deploy an audit-mode policy to these devices or employ a blocklist only policy to prevent specific apps or binaries that are considered malicious or vulnerable by your organization. | | **Bring Your Own Device**: Employees are allowed to bring their own devices, and also use those devices away from work. | In most cases, Windows Defender Application Control does not apply. Instead, you can explore other hardening and security features with MDM-based conditional access solutions, such as Microsoft Intune. However, you may choose to deploy an audit-mode policy to these devices or employ a blocklist only policy to prevent specific apps or binaries that are considered malicious or vulnerable by your organization. |
## An introduction to Lamna Healthcare Company ## An introduction to Lamna Healthcare Company
@ -55,4 +55,4 @@ Recently, Lamna experienced a ransomware event that required an expensive recove
## Up next ## Up next
- [Create a WDAC policy for lightly-managed devices](create-wdac-policy-for-lightly-managed-devices.md) - [Create a Windows Defender Application Control policy for lightly-managed devices](create-wdac-policy-for-lightly-managed-devices.md)

View File

@ -27,13 +27,13 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
> [!NOTE] > [!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](feature-availability.md). > Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
This topic is for the IT professional. It lists the design questions, possible answers, and ramifications for decisions made, when planning application control policies deployment using Windows Defender Application Control (WDAC), within a Windows operating system environment. This topic is for the IT professional. It lists the design questions, possible answers, and ramifications for decisions made, when planning application control policies deployment using Windows Defender Application Control (WDAC), within a Windows operating system environment.
When you begin the design and planning process, you should consider the ramifications of your design choices. The resulting decisions will affect your policy deployment scheme and subsequent application control policy maintenance. When you begin the design and planning process, you should consider the ramifications of your design choices. The resulting decisions will affect your policy deployment scheme and subsequent application control policy maintenance.
You should consider using WDAC as part of your organization's application control policies if the following are true: You should consider using Windows Defender Application Control 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 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 users access. - You need improved control over the access to your organization's applications and the data your users access.
@ -44,7 +44,7 @@ You should consider using WDAC as part of your organization's application contro
## Decide what policies to create ## Decide what policies to create
Beginning with Windows 10, version 1903, WDAC allows [multiple simultaneous policies](deploy-multiple-windows-defender-application-control-policies.md) to be applied to each device. This opens up many new use cases for organizations, but your policy management can easily become unwieldy without a well-thought-out plan for the number and types of policies to create. Beginning with Windows 10, version 1903, Windows Defender Application Control allows [multiple simultaneous policies](deploy-multiple-windows-defender-application-control-policies.md) to be applied to each device. This opens up many new use cases for organizations, but your policy management can easily become unwieldy without a well-thought-out plan for the number and types of policies to create.
The first step is to define the desired "circle-of-trust" for your WDAC policies. By "circle-of-trust," we mean a description of the business intent of the policy expressed in natural language. This "circle-of-trust" definition will guide you as you create the actual policy rules for your policy XML. The first step is to define the desired "circle-of-trust" for your WDAC policies. By "circle-of-trust," we mean a description of the business intent of the policy expressed in natural language. This "circle-of-trust" definition will guide you as you create the actual policy rules for your policy XML.
@ -52,20 +52,20 @@ For example, the DefaultWindows policy, which can be found under %OSDrive%\Windo
Microsoft Endpoint Configuration Manager, previously known as System Center Configuration Manager, uses the DefaultWindows policy as the basis for its policy but then modifies the policy rules to allow Configuration Manager and its dependencies, sets the managed installer policy rule, and additionally configures Configuration Manager as a managed installer. It also can optionally authorize apps with positive reputation and perform a one-time scan of folder paths specified by the Configuration Manager administrator, which adds rules for any apps found in the specified paths on the managed endpoint. This establishes the "circle-of-trust" for Configuration Manager's native WDAC integration. Microsoft Endpoint Configuration Manager, previously known as System Center Configuration Manager, uses the DefaultWindows policy as the basis for its policy but then modifies the policy rules to allow Configuration Manager and its dependencies, sets the managed installer policy rule, and additionally configures Configuration Manager as a managed installer. It also can optionally authorize apps with positive reputation and perform a one-time scan of folder paths specified by the Configuration Manager administrator, which adds rules for any apps found in the specified paths on the managed endpoint. This establishes the "circle-of-trust" for Configuration Manager's native WDAC integration.
The following questions can help you plan your WDAC deployment and determine the right "circle-of-trust" for your policies. They are not in priority or sequential order, and are not meant to be an exhaustive set of design considerations. The following questions can help you plan your Windows Defender Application Control deployment and determine the right "circle-of-trust" for your policies. They are not in priority or sequential order, and are not meant to be an exhaustive set of design considerations.
## WDAC design considerations ## WDAC design considerations
### How are apps managed and deployed in your organization? ### How are apps managed and deployed in your organization?
Organizations with well-defined, centrally managed app management and deployment processes can create more restrictive, more secure policies. Other organizations may be able to deploy WDAC with more relaxed rules, or may choose to deploy WDAC in audit mode to gain better visibility to the apps being used in their organization. Organizations with well-defined, centrally managed app management and deployment processes can create more restrictive, more secure policies. Other organizations may be able to deploy Windows Defender Application Control with more relaxed rules, or may choose to deploy WDAC in audit mode to gain better visibility to the apps being used in their organization.
| Possible answers | Design considerations| | Possible answers | Design considerations|
| - | - | | - | - |
| All apps are centrally managed and deployed using endpoint management tools like [Microsoft Endpoint Manager](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager). | Organizations that centrally manage all apps are best-suited for application control. WDAC options like [managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) can make it easy to authorize apps that are deployed by the organization's app distribution management solution. | | All apps are centrally managed and deployed using endpoint management tools like [Microsoft Endpoint Manager](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager). | Organizations that centrally manage all apps are best-suited for application control. Windows Defender Application Control options like [managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) can make it easy to authorize apps that are deployed by the organization's app distribution management solution. |
| Some apps are centrally managed and deployed, but teams can install other apps for their members. | [Supplemental policies](deploy-multiple-windows-defender-application-control-policies.md) can be used to allow team-specific exceptions to your core organization-wide WDAC policy. Alternatively, teams can use managed installers to install their team-specific apps, or admin-only file path rules can be used to allow apps installed by admin users. | | Some apps are centrally managed and deployed, but teams can install other apps for their members. | [Supplemental policies](deploy-multiple-windows-defender-application-control-policies.md) can be used to allow team-specific exceptions to your core organization-wide Windows Defender Application Control policy. Alternatively, teams can use managed installers to install their team-specific apps, or admin-only file path rules can be used to allow apps installed by admin users. |
| Users and teams are free to download and install apps but the organization wants to restrict that right to prevalent and reputable apps only. | WDAC can integrate with Microsoft's [Intelligent Security Graph](use-windows-defender-application-control-with-intelligent-security-graph.md) (the same source of intelligence that powers Microsoft Defender Antivirus and Windows Defender SmartScreen) to allow only apps and binaries that have positive reputation. | | Users and teams are free to download and install apps but the organization wants to restrict that right to prevalent and reputable apps only. | Windows Defender Application Control can integrate with Microsoft's [Intelligent Security Graph](use-windows-defender-application-control-with-intelligent-security-graph.md) (the same source of intelligence that powers Microsoft Defender Antivirus and Windows Defender SmartScreen) to allow only apps and binaries that have positive reputation. |
| Users and teams are free to download and install apps without restriction. | WDAC policies can be deployed in audit mode to gain insight into the apps and binaries running in your organization without impacting user and team productivity.| | Users and teams are free to download and install apps without restriction. | Windows Defender Application Control policies can be deployed in audit mode to gain insight into the apps and binaries running in your organization without impacting user and team productivity.|
### Are internally developed line-of-business (LOB) apps and apps developed by third-party companies digitally signed? ### Are internally developed line-of-business (LOB) apps and apps developed by third-party companies digitally signed?
@ -73,7 +73,7 @@ Traditional Win32 apps on Windows can run without being digitally signed. This p
| Possible answers | Design considerations | | Possible answers | Design considerations |
| - | - | | - | - |
| All apps used in your organization must be signed. | Organizations that enforce [codesigning](use-code-signing-to-simplify-application-control-for-classic-windows-applications.md) for all executable code are best-positioned to protect their Windows computers from malicious code execution. WDAC rules can be created to authorize apps and binaries from the organization's internal development teams and from trusted independent software vendors (ISV). | | All apps used in your organization must be signed. | Organizations that enforce [codesigning](use-code-signing-to-simplify-application-control-for-classic-windows-applications.md) for all executable code are best-positioned to protect their Windows computers from malicious code execution. Windows Defender Application Control rules can be created to authorize apps and binaries from the organization's internal development teams and from trusted independent software vendors (ISV). |
| Apps used in your organization do not need to meet any codesigning requirements. | Organizations can [use built-in Windows tools](deploy-catalog-files-to-support-windows-defender-application-control.md) to add organization-specific App Catalog signatures to existing apps as a part of the app deployment process, which can be used to authorize code execution. Solutions like Microsoft Endpoint Manager offer multiple ways to distribute signed App Catalogs. | | Apps used in your organization do not need to meet any codesigning requirements. | Organizations can [use built-in Windows tools](deploy-catalog-files-to-support-windows-defender-application-control.md) to add organization-specific App Catalog signatures to existing apps as a part of the app deployment process, which can be used to authorize code execution. Solutions like Microsoft Endpoint Manager offer multiple ways to distribute signed App Catalogs. |
### Are there specific groups in your organization that need customized application control policies? ### Are there specific groups in your organization that need customized application control policies?

View File

@ -21,7 +21,7 @@ ms.technology: mde
# Understanding WDAC Policy Settings # Understanding WDAC Policy Settings
Windows Defender Application Control (WDAC) Policies expose a Settings section where policy authors can define arbitrary secure settings. Secure Settings provide local admin tamper-free settings for secure boot enabled systems, with policy signing enabled. Settings consist of a Provider, Key, and ValueName, as well as a setting value. Setting values can be of type boolean, ulong, binary, and string. Applications can query for policy settings using WldpQuerySecurityPolicy. <br/> Windows Defender Application Control (WDAC) Policies expose a Settings section where policy authors can define arbitrary secure settings. Secure Settings provide local admin tamper-free settings for secure boot enabled systems, with policy signing enabled. Settings consist of a Provider, Key, and ValueName, as well as a setting value. Setting values can be of type boolean, ulong, binary, and string. Applications can query for policy settings using WldpQuerySecurityPolicy. <br/>
An example settings section of a WDAC Policy: An example settings section of a Windows Defender Application Control Policy:
```xml ```xml
<Settings> <Settings>
<Setting Provider="Contoso" Key="FooApplication" ValueName="DisableMacroExecution"> <Setting Provider="Contoso" Key="FooApplication" ValueName="DisableMacroExecution">
@ -33,11 +33,11 @@ An example settings section of a WDAC Policy:
``` ```
### Example Scenario ### Example Scenario
An application that may want to restrict its capabilities, when used on a system with an active WDAC policy. Application authors can define a WDAC policy, setting their application queries, in order to disable certain features. For example, if Contosos Foo Application wants to disable a risky feature, such as macro execution, they can define a WDAC policy setting, and query for it at runtime. Contoso can then instruct IT administrators to configure the setting in their WDAC policy, if they dont want Foo Application to execute macros on a system with a WDAC policy.<br/> An application that may want to restrict its capabilities, when used on a system with an active Windows Defender Application Control policy. Application authors can define a WDAC policy, setting their application queries, in order to disable certain features. For example, if Contosos Foo Application wants to disable a risky feature, such as macro execution, they can define a WDAC policy setting, and query for it at runtime. Contoso can then instruct IT administrators to configure the setting in their WDAC policy, if they dont want Foo Application to execute macros on a system with a WDAC policy.<br/>
### WldpQuerySecurityPolicy ### WldpQuerySecurityPolicy
API that queries the secure settings of a WDAC policy. API that queries the secure settings of a Windows Defender Application Control policy.
### Syntax ### Syntax
``` C++ ``` C++

View File

@ -33,9 +33,9 @@ This topic covers guidelines for using code signing control classic Windows apps
## Reviewing your applications: application signing and catalog files ## Reviewing your applications: application signing and catalog files
Typically, WDAC policies are configured to use the application's signing certificate as part or all of what identifies the application as trusted. This means that applications must either use embedded signing—where the signature is part of the binary—or catalog signing, where you generate a "catalog file" from the applications, sign it, and through the signed catalog file, configure the WDAC policy to recognize the applications as signed. Typically, Windows Defender Application Control (WDAC) policies are configured to use the application's signing certificate as part or all of what identifies the application as trusted. This means that applications must either use embedded signing—where the signature is part of the binary—or catalog signing, where you generate a "catalog file" from the applications, sign it, and through the signed catalog file, configure the WDAC policy to recognize the applications as signed.
Catalog files can be very useful for unsigned LOB applications that cannot easily be given an embedded signature. However, catalogs need to be updated each time an application is updated. In contrast, with embedded signing, your WDAC policies typically do not have to be updated when an application is updated. For this reason, if code-signing is or can be included in your in-house application development process, it can simplify the management of WDAC (compared to using catalog signing). Catalog files can be very useful for unsigned LOB applications that cannot easily be given an embedded signature. However, catalogs need to be updated each time an application is updated. In contrast, with embedded signing, your Windows Defender Application Control policies typically do not have to be updated when an application is updated. For this reason, if code-signing is or can be included in your in-house application development process, it can simplify the management of WDAC (compared to using catalog signing).
To obtain signed applications or embed signatures in your in-house applications, you can choose from a variety of methods: To obtain signed applications or embed signatures in your in-house applications, you can choose from a variety of methods:
@ -53,7 +53,7 @@ To use catalog signing, you can choose from the following options:
### Catalog files ### Catalog files
Catalog files (which you can create in Windows 10 and Windows 11 with a tool called Package Inspector) contain information about all deployed and executed binary files associated with your trusted but unsigned applications. When you create catalog files, you can also include signed applications for which you do not want to trust the signer but rather the specific application. After creating a catalog, you must sign the catalog file itself by using enterprise public key infrastructure (PKI), or a purchased code signing certificate. Then you can distribute the catalog, so that your trusted applications can be handled by WDAC in the same way as any other signed application. Catalog files (which you can create in Windows 10 and Windows 11 with a tool called Package Inspector) contain information about all deployed and executed binary files associated with your trusted but unsigned applications. When you create catalog files, you can also include signed applications for which you do not want to trust the signer but rather the specific application. After creating a catalog, you must sign the catalog file itself by using enterprise public key infrastructure (PKI), or a purchased code signing certificate. Then you can distribute the catalog, so that your trusted applications can be handled by Windows Defender Application Control in the same way as any other signed application.
Catalog files are simply Secure Hash Algorithm 2 (SHA2) hash lists of discovered binaries. These binaries' hash values are updated each time an application is updated, which requires the catalog file to be updated also. Catalog files are simply Secure Hash Algorithm 2 (SHA2) hash lists of discovered binaries. These binaries' hash values are updated each time an application is updated, which requires the catalog file to be updated also.
@ -66,8 +66,8 @@ For procedures for working with catalog files, see [Deploy catalog files to supp
## Windows Defender Application Control policy formats and signing ## Windows Defender Application Control policy formats and signing
When you generate a WDAC policy, you are generating a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10 and Windows 11 Enterprise, along with restrictions on Windows 10 and Windows 11 script hosts. You can view your original XML document in a text editor, for example if you want to check the rule options that are present in the **&lt;Rules&gt;** section of the file. When you generate a Windows Defender Application Control policy, you are generating a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10 and Windows 11 Enterprise, along with restrictions on Windows 10 and Windows 11 script hosts. You can view your original XML document in a text editor, for example if you want to check the rule options that are present in the **&lt;Rules&gt;** section of the file.
We recommend that you keep the original XML file for use when you need to merge the WDAC policy with another policy or update its rule options. For deployment purposes, the file is converted to a binary format, which can be done using a simple Windows PowerShell command. We recommend that you keep the original XML file for use when you need to merge the WDAC policy with another policy or update its rule options. For deployment purposes, the file is converted to a binary format, which can be done using a simple Windows PowerShell command.
When the WDAC policy is deployed, it restricts the software that can run on a device. The XML document can be signed, helping to add additional protection against administrative users changing or removing the policy. When the Windows Defender Application Control policy is deployed, it restricts the software that can run on a device. The XML document can be signed, helping to add additional protection against administrative users changing or removing the policy.

View File

@ -29,7 +29,7 @@ ms.technology: windows-sec
> [!NOTE] > [!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](feature-availability.md). > Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
Signed WDAC policies give organizations the highest level of malware protection available in Windows—must be signed with [PKCS #7](https://datatracker.ietf.org/doc/html/rfc5652). In addition to their enforced policy rules, signed policies cannot be modified or deleted by a user or administrator on the computer. These policies are designed to prevent administrative tampering and kernel mode exploit access. With this in mind, it is much more difficult to remove signed WDAC policies. Note that SecureBoot must be enabled in order to restrict users from updating or removing signed WDAC policies. Signed Windows Defender Application Control (WDAC) policies give organizations the highest level of malware protection available in Windows—must be signed with [PKCS #7](https://datatracker.ietf.org/doc/html/rfc5652). In addition to their enforced policy rules, signed policies cannot be modified or deleted by a user or administrator on the computer. These policies are designed to prevent administrative tampering and kernel mode exploit access. With this in mind, it is much more difficult to remove signed WDAC policies. Note that SecureBoot must be enabled in order to restrict users from updating or removing signed WDAC policies.
Before you sign with PKCS #7 and deploy a signed WDAC policy, we recommend that you [audit the policy](audit-windows-defender-application-control-policies.md) to discover any blocked applications that should be allowed to run. Before you sign with PKCS #7 and deploy a signed WDAC policy, we recommend that you [audit the policy](audit-windows-defender-application-control-policies.md) to discover any blocked applications that should be allowed to run.
@ -38,7 +38,7 @@ If you do not currently have a code signing certificate exported in .pfx format
Before PKCS #7-signing WDAC policies for the first time, be sure to enable rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath <PathAndFilename> -Option 9`, even if you're not sure whether the option is already enabled. If so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Windows Defender Application Control policy rules](select-types-of-rules-to-create.md). Before PKCS #7-signing WDAC policies for the first time, be sure to enable rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath <PathAndFilename> -Option 9`, even if you're not sure whether the option is already enabled. If so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Windows Defender Application Control policy rules](select-types-of-rules-to-create.md).
To sign a WDAC policy with SignTool.exe, you need the following components: To sign a Windows Defender Application Control policy with SignTool.exe, you need the following components:
- SignTool.exe, found in the [Windows SDK](https://developer.microsoft.com/windows/downloads/windows-10-sdk/) (Windows 7 or later) - SignTool.exe, found in the [Windows SDK](https://developer.microsoft.com/windows/downloads/windows-10-sdk/) (Windows 7 or later)
@ -49,7 +49,7 @@ To sign a WDAC policy with SignTool.exe, you need the following components:
> [!NOTE] > [!NOTE]
> All policies (base and supplemental and single-policy format) must be pkcs7 signed. [PKCS 7 Standard](https://datatracker.ietf.org/doc/html/rfc5652) > All policies (base and supplemental and single-policy format) must be pkcs7 signed. [PKCS 7 Standard](https://datatracker.ietf.org/doc/html/rfc5652)
If you do not have a code signing certificate, see [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md) for instructions on how to create one. If you use an alternate certificate or WDAC policy, be sure to update the following steps with the appropriate variables and certificate so that the commands will function properly. To sign the existing WDAC policy, copy each of the following commands into an elevated Windows PowerShell session: If you do not have a code signing certificate, see [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md) for instructions on how to create one. If you use an alternate certificate or Windows Defender Application Control (WDAC) policy, be sure to update the following steps with the appropriate variables and certificate so that the commands will function properly. To sign the existing WDAC policy, copy each of the following commands into an elevated Windows PowerShell session:
1. Initialize the variables that will be used: 1. Initialize the variables that will be used:

View File

@ -29,7 +29,7 @@ ms.technology: windows-sec
> [!NOTE] > [!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](feature-availability.md). > Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
As of Windows 10, version 1703, you can use WDAC policies not only to control applications, but also to control whether specific plug-ins, add-ins, and modules can run from specific apps (such as a line-of-business application or a browser): As of Windows 10, version 1703, you can use Windows Defender Application Control (WDAC) policies not only to control applications, but also to control whether specific plug-ins, add-ins, and modules can run from specific apps (such as a line-of-business application or a browser):
| Approach (as of Windows 10, version 1703) | Guideline | | Approach (as of Windows 10, version 1703) | Guideline |
|---|---| |---|---|
@ -38,7 +38,7 @@ As of Windows 10, version 1703, you can use WDAC policies not only to control ap
To work with these options, the typical method is to create a policy that only affects plug-ins, add-ins, and modules, then merge it into your 'master' policy (merging is described in the next section). To work with these options, the typical method is to create a policy that only affects plug-ins, add-ins, and modules, then merge it into your 'master' policy (merging is described in the next section).
For example, to create a WDAC policy allowing **addin1.dll** and **addin2.dll** to run in **ERP1.exe**, your organization's enterprise resource planning (ERP) application, run the following commands. Note that in the second command, **+=** is used to add a second rule to the **$rule** variable: For example, to create a Windows Defender Application Control policy allowing **addin1.dll** and **addin2.dll** to run in **ERP1.exe**, your organization's enterprise resource planning (ERP) application, run the following commands. Note that in the second command, **+=** is used to add a second rule to the **$rule** variable:
```powershell ```powershell
$rule = New-CIPolicyRule -DriverFilePath '.\temp\addin1.dll' -Level FileName -AppID '.\ERP1.exe' $rule = New-CIPolicyRule -DriverFilePath '.\temp\addin1.dll' -Level FileName -AppID '.\ERP1.exe'
@ -46,7 +46,7 @@ $rule += New-CIPolicyRule -DriverFilePath '.\temp\addin2.dll' -Level FileName -A
New-CIPolicy -Rules $rule -FilePath ".\AllowERPAddins.xml" -UserPEs New-CIPolicy -Rules $rule -FilePath ".\AllowERPAddins.xml" -UserPEs
``` ```
As another example, to create a WDAC policy that blocks **addin3.dll** from running in Microsoft Word, run the following command. You must include the `-Deny` option to block the specified add-ins in the specified application: As another example, to create a Windows Defender Application Control policy that blocks **addin3.dll** from running in Microsoft Word, run the following command. You must include the `-Deny` option to block the specified add-ins in the specified application:
```powershell ```powershell
$rule = New-CIPolicyRule -DriverFilePath '.\temp\addin3.dll' -Level FileName -Deny -AppID '.\winword.exe' $rule = New-CIPolicyRule -DriverFilePath '.\temp\addin3.dll' -Level FileName -Deny -AppID '.\winword.exe'

View File

@ -22,9 +22,9 @@ ms.technology: windows-sec
Historically, Windows Defender Application Control (WDAC) has restricted the set of applications, libraries, and scripts that are allowed to run to those approved by an organization. Historically, Windows Defender Application Control (WDAC) has restricted the set of applications, libraries, and scripts that are allowed to run to those approved by an organization.
Security researchers have found that some .NET applications may be used to circumvent those controls by using .NETs capabilities to load libraries from external sources or generate new code on the fly. Security researchers have found that some .NET applications may be used to circumvent those controls by using .NETs capabilities to load libraries from external sources or generate new code on the fly.
Beginning with Windows 10, version 1803, or Windows 11, WDAC features a new capability, called *Dynamic Code Security* to verify code loaded by .NET at runtime. Beginning with Windows 10, version 1803, or Windows 11, Windows Defender Application Control features a new capability, called *Dynamic Code Security* to verify code loaded by .NET at runtime.
When the Dynamic Code Security option is enabled, WDAC policy is applied to libraries that .NET loads from external sources. When the Dynamic Code Security option is enabled, Windows Defender Application Control policy is applied to libraries that .NET loads from external sources.
Additionally, it detects tampering in code generated to disk by .NET and blocks loading code that has been tampered with. Additionally, it detects tampering in code generated to disk by .NET and blocks loading code that has been tampered with.
Dynamic Code Security is not enabled by default because existing policies may not account for externally loaded libraries. Dynamic Code Security is not enabled by default because existing policies may not account for externally loaded libraries.

View File

@ -34,7 +34,7 @@ Beginning with Windows 10, version 1709, you can set an option to automatically
## How does the integration between WDAC and the Intelligent Security Graph work? ## How does the integration between WDAC and the Intelligent Security Graph work?
The ISG uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having "known good," "known bad," or "unknown" reputation. When a binary runs on a system, with WDAC enabled with the ISG option, WDAC checks the file's reputation, by sending its hash and signing information to the cloud. If the ISG reports that the file has a "known good" reputation, the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) is written to the file. The ISG uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having "known good," "known bad," or "unknown" reputation. When a binary runs on a system, with Windows Defender Application Control (WDAC) enabled with the ISG option, WDAC checks the file's reputation, by sending its hash and signing information to the cloud. If the ISG reports that the file has a "known good" reputation, the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) is written to the file.
If your WDAC policy does not have an explicit rule to allow or deny a binary to run, then WDAC will make a call to the cloud to determine whether the binary is familiar and safe. However, if your policy already authorizes or denies the binary, then WDAC will not make a call to the cloud. If your WDAC policy does not have an explicit rule to allow or deny a binary to run, then WDAC will make a call to the cloud to determine whether the binary is familiar and safe. However, if your policy already authorizes or denies the binary, then WDAC will not make a call to the cloud.
@ -43,7 +43,7 @@ If the file with good reputation is an application installer, its reputation wil
WDAC periodically re-queries the reputation data on a file. Additionally, enterprises can specify that any cached reputation results are flushed on reboot by using the **Enabled:Invalidate EAs on Reboot** option. WDAC periodically re-queries the reputation data on a file. Additionally, enterprises can specify that any cached reputation results are flushed on reboot by using the **Enabled:Invalidate EAs on Reboot** option.
>[!NOTE] >[!NOTE]
>Admins should make sure there is a WDAC policy in place to allow the system to boot and run any other authorized applications that may not be classified as being known good by the Intelligent Security Graph, such as custom line-of-business (LOB) apps. Since the Intelligent Security Graph is powered by global prevalence data, internal LOB apps may not be recognized as being known good. Other mechanisms like managed installer and explicit rules will help cover internal applications. Both Microsoft Endpoint Manager Configuration Manager (MEMCM) and Microsoft Endpoint Manager Intune (MEM Intune) can be used to create and push a WDAC policy to your client machines. >Admins should make sure there is a Windows Defender Application Control policy in place to allow the system to boot and run any other authorized applications that may not be classified as being known good by the Intelligent Security Graph, such as custom line-of-business (LOB) apps. Since the Intelligent Security Graph is powered by global prevalence data, internal LOB apps may not be recognized as being known good. Other mechanisms like managed installer and explicit rules will help cover internal applications. Both Microsoft Endpoint Manager Configuration Manager (MEMCM) and Microsoft Endpoint Manager Intune (MEM Intune) can be used to create and push a WDAC policy to your client machines.
## Configuring Intelligent Security Graph authorization for Windows Defender Application Control ## Configuring Intelligent Security Graph authorization for Windows Defender Application Control
@ -54,7 +54,7 @@ Setting up the ISG is easy using any management solution you wish. Configuring t
### Ensure that the Intelligent Security Graph option is enabled in the WDAC policy XML ### Ensure that the Intelligent Security Graph option is enabled in the WDAC policy XML
To allow apps and binaries based on the Microsoft Intelligent Security Graph, the **Enabled:Intelligent Security Graph authorization** option must be specified in the WDAC policy. This step can be done with the Set-RuleOption cmdlet. You should also enable the **Enabled:Invalidate EAs on Reboot** option so that ISG results are verified again after each reboot. The ISG option is not recommended for devices that don't have regular access to the internet. The following example shows both options being set. To allow apps and binaries based on the Microsoft Intelligent Security Graph, the **Enabled:Intelligent Security Graph authorization** option must be specified in the Windows Defender Application Control policy. This step can be done with the Set-RuleOption cmdlet. You should also enable the **Enabled:Invalidate EAs on Reboot** option so that ISG results are verified again after each reboot. The ISG option is not recommended for devices that don't have regular access to the internet. The following example shows both options being set.
```xml ```xml
<Rules> <Rules>
@ -90,7 +90,7 @@ In order for the heuristics used by the ISG to function properly, a number of co
appidtel start appidtel start
``` ```
This step isn't required for WDAC policies deployed over MDM, as the CSP will enable the necessary components. This step is also not required when the ISG is configured using MEMCM's WDAC integration. This step isn't required for Windows Defender Application Control policies deployed over MDM, as the CSP will enable the necessary components. This step is also not required when the ISG is configured using MEMCM's WDAC integration.
## Security considerations with the Intelligent Security Graph ## Security considerations with the Intelligent Security Graph
@ -123,11 +123,11 @@ Ea Value Length: 7e
## Known limitations with using the Intelligent Security Graph ## Known limitations with using the Intelligent Security Graph
Since the ISG only allows binaries that are known good, there are cases where legitimate software may be unknown to the ISG and will be blocked by WDAC. In this case, you need to allow the software with a rule in your WDAC policy, deploy a catalog signed by a certificate trusted in the WDAC policy, or install the software from a WDAC managed installer. Installers or applications that dynamically create binaries at runtime, as well as self-updating applications, may exhibit this symptom. Since the ISG only allows binaries that are known good, there are cases where legitimate software may be unknown to the ISG and will be blocked by Windows Defender Application Control (WDAC). In this case, you need to allow the software with a rule in your WDAC policy, deploy a catalog signed by a certificate trusted in the WDAC policy, or install the software from a WDAC managed installer. Installers or applications that dynamically create binaries at runtime, as well as self-updating applications, may exhibit this symptom.
Packaged apps are not supported with the Microsoft Intelligent Security Graph heuristics and will need to be separately authorized in your WDAC policy. Since packaged apps have a strong app identity and must be signed, it is straightforward to authorize these apps with your WDAC policy. Packaged apps are not supported with the Microsoft Intelligent Security Graph heuristics and will need to be separately authorized in your WDAC policy. Since packaged apps have a strong app identity and must be signed, it is straightforward to authorize these apps with your WDAC policy.
The ISG doesn't authorize kernel mode drivers. The WDAC policy must have rules that allow the necessary drivers to run. The ISG doesn't authorize kernel mode drivers. The WDAC policy must have rules that allow the necessary drivers to run.
>[!NOTE] >[!NOTE]
> A rule that explicitly denies or allows a file will take precedence over that file's reputation data. MEM Intune's built-in WDAC support includes the option to trust apps with good reputation via the Microsoft Intelligent Security Graph, but it has no option to add explicit allow or deny rules. In most circumstances, customers enforcing application control need to deploy a custom WDAC policy (which can include the Microsoft Intelligent Security Graph option if desired) using [Intune's OMA-URI functionality](deploy-windows-defender-application-control-policies-using-intune.md#deploy-wdac-policies-with-custom-oma-uri). > A rule that explicitly denies or allows a file will take precedence over that file's reputation data. MEM Intune's built-in Windows Defender Application Control support includes the option to trust apps with good reputation via the Microsoft Intelligent Security Graph, but it has no option to add explicit allow or deny rules. In most circumstances, customers enforcing application control need to deploy a custom WDAC policy (which can include the Microsoft Intelligent Security Graph option if desired) using [Intune's OMA-URI functionality](deploy-windows-defender-application-control-policies-using-intune.md#deploy-wdac-policies-with-custom-oma-uri).

View File

@ -28,15 +28,15 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
> [!NOTE] > [!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](feature-availability.md). > Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
Windows 10 and Windows 11 include two technologies that can be used for application control, depending on your organization's specific scenarios and requirements: Windows Defender Application Control (WDAC) and AppLocker. Windows 10 and Windows 11 include two technologies that can be used for application control, depending on your organization's specific scenarios and requirements: Windows Defender Application Control (WDAC) and AppLocker.
## Windows Defender Application Control ## Windows Defender Application Control
WDAC was introduced with Windows 10 and allows organizations to control which drivers and applications are allowed to run on their Windows clients. It was designed as a security feature under the [servicing criteria](https://www.microsoft.com/msrc/windows-security-servicing-criteria), defined by the Microsoft Security Response Center (MSRC). Windows Defender Application Control was introduced with Windows 10 and allows organizations to control which drivers and applications are allowed to run on their Windows clients. It was designed as a security feature under the [servicing criteria](https://www.microsoft.com/msrc/windows-security-servicing-criteria), defined by the Microsoft Security Response Center (MSRC).
WDAC policies apply to the managed computer as a whole and affects all users of the device. WDAC rules can be defined based on: Windows Defender Application Control policies apply to the managed computer as a whole and affects all users of the device. WDAC rules can be defined based on:
- Attributes of the codesigning certificate(s) used to sign an app and its binaries - Attributes of the codesigning certificate(s) used to sign an app and its binaries
- Attributes of the app's binaries that come from the signed metadata for the files, such as Original Filename and version, or the hash of the file - Attributes of the app's binaries that come from the signed metadata for the files, such as Original Filename and version, or the hash of the file
@ -49,7 +49,7 @@ Note that prior to Windows 10 version 1709, Windows Defender Application Control
### WDAC System Requirements ### WDAC System Requirements
WDAC policies can be created on any client edition of Windows 10 build 1903+, or Windows 11, or on Windows Server 2016 and above. Windows Defender Application Control (WDAC) policies can be created on any client edition of Windows 10 build 1903+, or Windows 11, or on Windows Server 2016 and above.
WDAC policies can be applied to devices running any edition of Windows 10, Windows 11, or Windows Server 2016 and above, via a Mobile Device Management (MDM) solution, for example, Intune; a management interface such as Configuration Manager; or a script host such as PowerShell. Group Policy can also be used to deploy WDAC policies to Windows 10 and Windows 11 Enterprise edition, or Windows Server 2016 and above, but cannot deploy policies to devices running non-Enterprise SKUs of Windows 10. WDAC policies can be applied to devices running any edition of Windows 10, Windows 11, or Windows Server 2016 and above, via a Mobile Device Management (MDM) solution, for example, Intune; a management interface such as Configuration Manager; or a script host such as PowerShell. Group Policy can also be used to deploy WDAC policies to Windows 10 and Windows 11 Enterprise edition, or Windows Server 2016 and above, but cannot deploy policies to devices running non-Enterprise SKUs of Windows 10.
@ -72,7 +72,7 @@ AppLocker policies can be deployed using Group Policy or MDM.
## Choose when to use WDAC or AppLocker ## Choose when to use WDAC or AppLocker
Generally, it is recommended that customers, who are able to implement application control using WDAC rather than AppLocker, do so. WDAC is undergoing continual improvements, and will be getting added support from Microsoft management platforms. Although AppLocker will continue to receive security fixes, it will not undergo new feature improvements. Generally, it is recommended that customers, who are able to implement application control using Windows Defender Application Control rather than AppLocker, do so. WDAC is undergoing continual improvements, and will be getting added support from Microsoft management platforms. Although AppLocker will continue to receive security fixes, it will not undergo new feature improvements.
However, in some cases, AppLocker may be the more appropriate technology for your organization. AppLocker is best when: However, in some cases, AppLocker may be the more appropriate technology for your organization. AppLocker is best when:
@ -80,5 +80,5 @@ However, in some cases, AppLocker may be the more appropriate technology for you
- You need to apply different policies for different users or groups on shared computers. - You need to apply different policies for different users or groups on shared computers.
- You do not want to enforce application control on application files such as DLLs or drivers. - You do not want to enforce application control on application files such as DLLs or drivers.
AppLocker can also be deployed as a complement to WDAC to add user or group-specific rules for shared device scenarios, where it is important to prevent some users from running specific apps. AppLocker can also be deployed as a complement to Windows Defender Application Control (WDAC) to add user or group-specific rules for shared device scenarios, where it is important to prevent some users from running specific apps.
As a best practice, you should enforce WDAC at the most restrictive level possible for your organization, and then you can use AppLocker to further fine-tune the restrictions. As a best practice, you should enforce WDAC at the most restrictive level possible for your organization, and then you can use AppLocker to further fine-tune the restrictions.

View File

@ -46,7 +46,7 @@ Each of the template policies has a unique set of policy allow list rules that w
*Italicized content denotes the changes in the current policy with respect to the policy prior.* *Italicized content denotes the changes in the current policy with respect to the policy prior.*
More information about the Default Windows Mode and Allow Microsoft Mode policies can be accessed through the [Example WDAC base policies article](example-wdac-base-policies.md). More information about the Default Windows Mode and Allow Microsoft Mode policies can be accessed through the [Example Windows Defender Application Control base policies article](example-wdac-base-policies.md).
![Selecting a base template for the policy.](images/wdac-wizard-template-selection.png) ![Selecting a base template for the policy.](images/wdac-wizard-template-selection.png)
@ -62,16 +62,16 @@ A description of each policy rule, beginning with the left-most column, is provi
| Rule option | Description | | Rule option | Description |
|------------ | ----------- | |------------ | ----------- |
| **Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all WDAC policies. Setting this rule option allows the F8 menu to appear to physically present users. | | **Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all Windows Defender Application Control policies. Setting this rule option allows the F8 menu to appear to physically present users. |
| **Allow Supplemental Policies** | Use this option on a base policy to allow supplemental policies to expand it. | | **Allow Supplemental Policies** | Use this option on a base policy to allow supplemental policies to expand it. |
| **Disable Script Enforcement** | This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). NOTE: This option is required to run HTA files, and is only supported with the Windows 10 May 2019 Update (1903) and higher. Using it on earlier versions of Windows 10 is not supported and may have unintended results. | | **Disable Script Enforcement** | This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). NOTE: This option is required to run HTA files, and is only supported with the Windows 10 May 2019 Update (1903) and higher. Using it on earlier versions of Windows 10 is not supported and may have unintended results. |
|**[Hypervisor-protected code integrity (HVCI)](../device-guard/enable-virtualization-based-protection-of-code-integrity.md)**| When enabled, policy enforcement uses virtualization-based security to run the code integrity service inside a secure environment. HVCI provides stronger protections against kernel malware.| |**[Hypervisor-protected code integrity (HVCI)](../device-guard/enable-virtualization-based-protection-of-code-integrity.md)**| When enabled, policy enforcement uses virtualization-based security to run the code integrity service inside a secure environment. HVCI provides stronger protections against kernel malware.|
| **Intelligent Security Graph Authorization** | Use this option to automatically allow applications with "known good" reputation as defined by the Microsoft Intelligent Security Graph (ISG). | | **Intelligent Security Graph Authorization** | Use this option to automatically allow applications with "known good" reputation as defined by the Microsoft Intelligent Security Graph (ISG). |
| **Managed Installer** | Use this option to automatically allow applications installed by a software distribution solution, such as Microsoft Endpoint Configuration Manager, that has been defined as a managed installer. | | **Managed Installer** | Use this option to automatically allow applications installed by a software distribution solution, such as Microsoft Endpoint Configuration Manager, that has been defined as a managed installer. |
| **Require WHQL** | By default, legacy drivers that are not Windows Hardware Quality Labs (WHQL) signed are allowed to execute. Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. Going forward, every new Windowscompatible driver must be WHQL certified. | | **Require WHQL** | By default, legacy drivers that are not Windows Hardware Quality Labs (WHQL) signed are allowed to execute. Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. Going forward, every new Windowscompatible driver must be WHQL certified. |
| **Update Policy without Rebooting** | Use this option to allow future WDAC policy updates to apply without requiring a system reboot. | | **Update Policy without Rebooting** | Use this option to allow future Windows Defender Application Control policy updates to apply without requiring a system reboot. |
| **Unsigned System Integrity Policy** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed and have UpdatePolicySigners added to the policy to enable future policy modifications. | | **Unsigned System Integrity Policy** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed and have UpdatePolicySigners added to the policy to enable future policy modifications. |
| **User Mode Code Integrity** | WDAC policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts. | | **User Mode Code Integrity** | Windows Defender Application Control policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts. |
> [!div class="mx-imgBorder"] > [!div class="mx-imgBorder"]
> ![Rule options UI for Windows Allowed mode policy.](images/wdac-wizard-rule-options-UI-advanced-collapsed.png) > ![Rule options UI for Windows Allowed mode policy.](images/wdac-wizard-rule-options-UI-advanced-collapsed.png)
@ -82,7 +82,7 @@ Selecting the **+ Advanced Options** label will show another column of policy ru
| Rule option | Description | | Rule option | Description |
|------------ | ----------- | |------------ | ----------- |
| **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. Administrators can validate the reason for the failure in the CodeIntegrity event log. | | **Boot Audit on Failure** | Used when the Windows Defender Application Control (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. Administrators can validate the reason for the failure in the CodeIntegrity event log. |
| **Disable Flight Signing** | If enabled, WDAC policies will not trust flightroot-signed binaries. This would be used in the scenario in which organizations only want to run released binaries, not flight/preview-signed builds. | | **Disable Flight Signing** | If enabled, WDAC policies will not trust flightroot-signed binaries. This would be used in the scenario in which organizations only want to run released binaries, not flight/preview-signed builds. |
| **Disable Runtime FilePath Rule Protection** | Disable default FilePath rule protection (apps and executables allowed based on file path rules must come from a file path that's only writable by an administrator) for any FileRule that allows a file based on FilePath. | | **Disable Runtime FilePath Rule Protection** | Disable default FilePath rule protection (apps and executables allowed based on file path rules must come from a file path that's only writable by an administrator) for any FileRule that allows a file based on FilePath. |
| **Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically loaded libraries (DLLs). | | **Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically loaded libraries (DLLs). |
@ -92,7 +92,7 @@ Selecting the **+ Advanced Options** label will show another column of policy ru
![Rule options UI for Windows Allowed mode.](images/wdac-wizard-rule-options-UI.png) ![Rule options UI for Windows Allowed mode.](images/wdac-wizard-rule-options-UI.png)
> [!NOTE] > [!NOTE]
> We recommend that you **enable Audit Mode** initially because it allows you to test new WDAC policies before you enforce them. With audit mode, no application is blocked—instead the policy logs an event whenever an application outside the policy is started. For this reason, all templates have Audit Mode enabled by default. > We recommend that you **enable Audit Mode** initially because it allows you to test new Windows Defender Application Control policies before you enforce them. With audit mode, no application is blocked—instead the policy logs an event whenever an application outside the policy is started. For this reason, all templates have Audit Mode enabled by default.
## Creating custom file rules ## Creating custom file rules
@ -100,7 +100,7 @@ Selecting the **+ Advanced Options** label will show another column of policy ru
### Publisher Rules ### Publisher Rules
The Publisher file rule type uses properties in the code signing certificate chain to base file rules. Once the file to base the rule off of, called the *reference file*, is selected, use the slider to indicate the specificity of the rule. The table below shows the relationship between the slider placement, the corresponding WDAC rule level and its description. The lower the placement on the table and the UI slider, the greater the specificity of the rule. The Publisher file rule type uses properties in the code signing certificate chain to base file rules. Once the file to base the rule off of, called the *reference file*, is selected, use the slider to indicate the specificity of the rule. The table below shows the relationship between the slider placement, the corresponding Windows Defender Application Control (WDAC) rule level and its description. The lower the placement on the table and the UI slider, the greater the specificity of the rule.
| Rule Condition | WDAC Rule Level | Description | | Rule Condition | WDAC Rule Level | Description |
|------------ | ----------- | ----------- | |------------ | ----------- | ----------- |
@ -140,4 +140,4 @@ The policy signing rules list table on the left of the page will document the al
## Up next ## Up next
- [Editing a WDAC policy using the Wizard](wdac-wizard-editing-policy.md) - [Editing a Windows Defender Application Control (WDAC) policy using the Wizard](wdac-wizard-editing-policy.md)

View File

@ -30,7 +30,7 @@ ms.technology: windows-sec
> [!NOTE] > [!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](feature-availability.md). > Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
Beginning in Windows 10 version 1903, WDAC supports the creation of multiple active policies on a device. One or more supplemental policies allow customers to expand a [WDAC base policy](wdac-wizard-create-base-policy.md) to increase the circle of trust of the policy. A supplemental policy can expand only one base policy, but multiple supplementals can expand the same base policy. When using supplemental policies, applications allowed by the base or its supplemental policy/policies will be allowed to execute. Beginning in Windows 10 version 1903, Windows Defender Application Control (WDAC) supports the creation of multiple active policies on a device. One or more supplemental policies allow customers to expand a [WDAC base policy](wdac-wizard-create-base-policy.md) to increase the circle of trust of the policy. A supplemental policy can expand only one base policy, but multiple supplementals can expand the same base policy. When using supplemental policies, applications allowed by the base or its supplemental policy/policies will be allowed to execute.
Prerequisite information about application control can be accessed through the [WDAC design guide](windows-defender-application-control-design-guide.md). This page outlines the steps to create a supplemental application control policy, configure the policy options, and the signer and file rules. Prerequisite information about application control can be accessed through the [WDAC design guide](windows-defender-application-control-design-guide.md). This page outlines the steps to create a supplemental application control policy, configure the policy options, and the signer and file rules.
@ -73,7 +73,7 @@ File rules in an application control policy will specify the level at which appl
### Publisher Rules ### Publisher Rules
The Publisher file rule type uses properties in the code signing certificate chain to base file rules. Once the file to base the rule off of, called the *reference file*, is selected, use the slider to indicate the specificity of the rule. The table below shows the relationship between the slider placement, the corresponding WDAC rule level, and its description. The lower the placement on the table and the UI slider, the greater the specificity of the rule. The Publisher file rule type uses properties in the code signing certificate chain to base file rules. Once the file to base the rule off of, called the *reference file*, is selected, use the slider to indicate the specificity of the rule. The table below shows the relationship between the slider placement, the corresponding Windows Defender Application Control (WDAC) rule level, and its description. The lower the placement on the table and the UI slider, the greater the specificity of the rule.
| Rule Condition | WDAC Rule Level | Description | | Rule Condition | WDAC Rule Level | Description |
|------------ | ----------- | ----------- | |------------ | ----------- | ----------- |
@ -114,4 +114,4 @@ The table on the left of the page will document the allow and deny rules in the
## Up next ## Up next
- [Editing a WDAC policy using the Wizard](wdac-wizard-editing-policy.md) - [Editing a Windows Defender Application Control (WDAC) policy using the Wizard](wdac-wizard-editing-policy.md)

View File

@ -28,9 +28,9 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
> [!NOTE] > [!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](feature-availability.md). > Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
The WDAC Wizard makes editing and viewing WDAC policies easier than the PowerShell cmdlets or manually. The Wizard currently supports the following editing capabilities: The Windows Defender Application Control Wizard makes editing and viewing WDAC policies easier than the PowerShell cmdlets or manually. The Wizard currently supports the following editing capabilities:
<ul> <ul>
<li><a href="#configuring-policy-rules">Configuring policy rules</a></li> <li><a href="#configuring-policy-rules">Configuring policy rules</a></li>
<li><a href="#adding-file-rules">Adding new allow or block file rules to existing policies</a></li> <li><a href="#adding-file-rules">Adding new allow or block file rules to existing policies</a></li>
@ -47,7 +47,7 @@ A description of the policy rule is shown at the bottom of the page when the cur
## Adding File Rules ## Adding File Rules
The WDAC Wizard allows users to add rules to their existing policy seamlessly. Previously, this would have involved creating a new policy with the new rules and merging it with the existing policy. The Windows Defender Application Control Wizard allows users to add rules to their existing policy seamlessly. Previously, this would have involved creating a new policy with the new rules and merging it with the existing policy.
Selecting the `+ Custom Rules` button will open the Custom Rules panel. For more information on creating new policy file rules, see the guidelines provided in the [creating policy file rules section](wdac-wizard-create-base-policy.md#creating-custom-file-rules). Selecting the `+ Custom Rules` button will open the Custom Rules panel. For more information on creating new policy file rules, see the guidelines provided in the [creating policy file rules section](wdac-wizard-create-base-policy.md#creating-custom-file-rules).
@ -75,4 +75,4 @@ Once the policy is created, the new policy will be written to the same path as t
## Up next ## Up next
- [Merging WDAC policies using the Wizard](wdac-wizard-merging-policies.md) - [Merging Windows Defender Application Control (WDAC) policies using the Wizard](wdac-wizard-merging-policies.md)

View File

@ -21,12 +21,12 @@ ms.technology: windows-sec
# Merging existing policies with the WDAC Wizard # Merging existing policies with the WDAC Wizard
Beginning in Windows 10 version 1903, WDAC supports multiple policies. Before version 1903, however, Windows 10 could only have one WDAC policy. Consequently, users were required to merge multiple WDAC policies into one. The WDAC Wizard has a simple to use user interface to allow users to merge multiple WDAC policies. The Wizard can support up to 15 policy files as input during the merge workflow. Beginning in Windows 10 version 1903, Windows Defender Application Control (WDAC)supports multiple policies. Before version 1903, however, Windows 10 could only have one WDAC policy. Consequently, users were required to merge multiple WDAC policies into one. The WDAC Wizard has a simple to use user interface to allow users to merge multiple WDAC policies. The Wizard can support up to 15 policy files as input during the merge workflow.
Select the policies you wish to merge into one policy using the `+ Add Policy` button under the table. Once added, policies will be enumerated within the table. To remove a policy from the table, if accidentally added, highlight the policy row and select the `- Remove Policy` button. Confirmation will be required before the policy is withdrawn from the table. Select the policies you wish to merge into one policy using the `+ Add Policy` button under the table. Once added, policies will be enumerated within the table. To remove a policy from the table, if accidentally added, highlight the policy row and select the `- Remove Policy` button. Confirmation will be required before the policy is withdrawn from the table.
> [!NOTE] > [!NOTE]
> The policy type and ID of the final output policy will be determined based on the type and ID of the **first policy** in the policy list table. For instance, if a legacy policy format policy and a multi-policy format policy are merged together, the output format of the policy will be whichever policy is specified first in the table. For more information on policy formats, visit the [Multiple WDAC Policies page](deploy-multiple-windows-defender-application-control-policies.md). > The policy type and ID of the final output policy will be determined based on the type and ID of the **first policy** in the policy list table. For instance, if a legacy policy format policy and a multi-policy format policy are merged together, the output format of the policy will be whichever policy is specified first in the table. For more information on policy formats, visit the [Multiple Windows Defender Application Control (WDAC) Policies page](deploy-multiple-windows-defender-application-control-policies.md).
Lastly, select a filepath save location for the final merged policy using the `Browse` button. If a minimum of two policies are selected, and the save location is specified, select the `Next` button to build the policy. Lastly, select a filepath save location for the final merged policy using the `Browse` button. If a minimum of two policies are selected, and the save location is specified, select the `Next` button to build the policy.

View File

@ -28,7 +28,7 @@ The Windows Defender Application Control policy wizard is an open-source Windows
## Downloading the application ## Downloading the application
Download the tool from the official [Windows Defender Application Control Policy Wizard website](https://webapp-wdac-wizard.azurewebsites.net/) as an MSIX packaged application. The tool's source code is available as part of Microsoft's Open Source Software offerings on GitHub at the [WDAC Policy Wizard repository](https://github.com/MicrosoftDocs/WDAC-Toolkit). Download the tool from the official [Windows Defender Application Control Policy Wizard website](https://webapp-wdac-wizard.azurewebsites.net/) as an MSIX packaged application. The tool's source code is available as part of Microsoft's Open Source Software offerings on GitHub at the [Windows Defender Application Control (WDAC) Policy Wizard repository](https://github.com/MicrosoftDocs/WDAC-Toolkit).
### Supported clients ### Supported clients

View File

@ -29,17 +29,17 @@ ms.technology: windows-sec
> [!NOTE] > [!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](feature-availability.md). > Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
You should now have one or more WDAC policies ready to deploy. If you haven't yet completed the steps described in the [WDAC Design Guide](windows-defender-application-control-design-guide.md), do so now before proceeding. You should now have one or more Windows Defender Application Control (WDAC) policies ready to deploy. If you haven't yet completed the steps described in the [WDAC Design Guide](windows-defender-application-control-design-guide.md), do so now before proceeding.
## Plan your deployment ## Plan your deployment
As with any significant change to your environment, implementing application control can have unintended consequences. To ensure the best chance for success, you should follow safe deployment practices and plan your deployment carefully. Decide what devices you will manage with WDAC and split them into deployment rings so you can control the scale of the deployment and respond if anything goes wrong. Define the success criteria that will determine when it's safe to continue from one ring to the next. As with any significant change to your environment, implementing application control can have unintended consequences. To ensure the best chance for success, you should follow safe deployment practices and plan your deployment carefully. Decide what devices you will manage with Windows Defender Application Control and split them into deployment rings so you can control the scale of the deployment and respond if anything goes wrong. Define the success criteria that will determine when it's safe to continue from one ring to the next.
All WDAC policy changes should be deployed in audit mode before proceeding to enforcement. Carefully monitor events from devices where the policy has been deployed to ensure the block events you observe match your expectation before broadening the deployment to other deployment rings. If your organization uses Microsoft Defender for Endpoint, you can use the Advanced Hunting feature to centrally monitor WDAC-related events. Otherwise, we recommend using an event log forwarding solution to collect relevant events from your managed endpoints. All Windows Defender Application Control policy changes should be deployed in audit mode before proceeding to enforcement. Carefully monitor events from devices where the policy has been deployed to ensure the block events you observe match your expectation before broadening the deployment to other deployment rings. If your organization uses Microsoft Defender for Endpoint, you can use the Advanced Hunting feature to centrally monitor WDAC-related events. Otherwise, we recommend using an event log forwarding solution to collect relevant events from your managed endpoints.
## Choose how to deploy WDAC policies ## Choose how to deploy WDAC policies
There are several options to deploy WDAC policies to managed endpoints, including: There are several options to deploy Windows Defender Application Control policies to managed endpoints, including:
1. [Deploy using a Mobile Device Management (MDM) solution](deploy-windows-defender-application-control-policies-using-intune.md), such as Microsoft Intune 1. [Deploy using a Mobile Device Management (MDM) solution](deploy-windows-defender-application-control-policies-using-intune.md), such as Microsoft Intune
2. [Deploy using Microsoft Endpoint Configuration Manager (MEMCM)](deployment/deploy-wdac-policies-with-memcm.md) 2. [Deploy using Microsoft Endpoint Configuration Manager (MEMCM)](deployment/deploy-wdac-policies-with-memcm.md)

View File

@ -41,7 +41,7 @@ A common refrain you may hear about application control is that it is "too hard.
- The organization has a plan to handle potential helpdesk support requests for users who are blocked from running some apps. - The organization has a plan to handle potential helpdesk support requests for users who are blocked from running some apps.
- The organization has considered where application control can be most useful (for example, securing sensitive workloads or business functions) and also where it may be difficult to achieve (for example, developer workstations). - The organization has considered where application control can be most useful (for example, securing sensitive workloads or business functions) and also where it may be difficult to achieve (for example, developer workstations).
Once these business factors are in place, you are ready to begin planning your WDAC deployment. The following topics can help guide you through your planning process. Once these business factors are in place, you are ready to begin planning your Windows Defender Application Control (WDAC) deployment. The following topics can help guide you through your planning process.
## In this section ## In this section

View File

@ -33,7 +33,7 @@ After designing and deploying your Windows Defender Application Control (WDAC) p
## WDAC Events Overview ## WDAC Events Overview
WDAC generates and logs events when a policy is loaded as well as when a binary attempts to execute and is blocked. These events include information that identifies the policy and gives more details about the block. Generally, WDAC does not generate events when a binary is allowed; however, there is the option to enable events when Managed Installer and/or the Intelligent Security Graph (ISG) is configured. Windows Defender Application Control generates and logs events when a policy is loaded as well as when a binary attempts to execute and is blocked. These events include information that identifies the policy and gives more details about the block. Generally, WDAC does not generate events when a binary is allowed; however, there is the option to enable events when Managed Installer and/or the Intelligent Security Graph (ISG) is configured.
WDAC events are generated under two locations: WDAC events are generated under two locations:

View File

@ -43,7 +43,7 @@ Application control is a crucial line of defense for protecting enterprises give
Windows 10 and Windows 11 include two technologies that can be used for application control depending on your organization's specific scenarios and requirements: Windows 10 and Windows 11 include two technologies that can be used for application control depending on your organization's specific scenarios and requirements:
- **Windows Defender Application Control**; and - **Windows Defender Application Control (WDAC)**; and
- **AppLocker** - **AppLocker**
## In this section ## In this section

View File

@ -125,11 +125,12 @@ Application Guard performance is improved with optimized document opening times:
### Application Control ### Application Control
[Application Control for Windows](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control): In Windows 10, version 1903 WDAC added a number of new features that light up key scenarios and provide feature parity with AppLocker. [Application Control for Windows](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control): In Windows 10, version 1903, Windows Defender Application Control (WDAC) added a number of new features that light up key scenarios and provide feature parity with AppLocker.
- [Multiple Policies](/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies): WDAC now supports multiple simultaneous code integrity policies for one device in order to enable the following scenarios: 1) enforce and audit side by side, 2) simpler targeting for policies with different scope/intent, 3) expanding a policy using a new supplemental policy.
- [Multiple Policies](/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies): Windows Defender Application Control now supports multiple simultaneous code integrity policies for one device in order to enable the following scenarios: 1) enforce and audit side by side, 2) simpler targeting for policies with different scope/intent, 3) expanding a policy using a new supplemental policy.
- [Path-Based Rules](/windows/security/threat-protection/windows-defender-application-control/create-path-based-rules): The path condition identifies an app by its location in the file system of the computer or on the network instead of a signer or hash identifier. Additionally, WDAC has an option that allows admins to enforce at runtime that only code from paths that are not user-writeable is executed. When code tries to execute at runtime, the directory is scanned and files will be checked for write permissions for non-known admins. If a file is found to be user writeable, the executable is blocked from running unless it is authorized by something other than a path rule like a signer or hash rule.<br> - [Path-Based Rules](/windows/security/threat-protection/windows-defender-application-control/create-path-based-rules): The path condition identifies an app by its location in the file system of the computer or on the network instead of a signer or hash identifier. Additionally, WDAC has an option that allows admins to enforce at runtime that only code from paths that are not user-writeable is executed. When code tries to execute at runtime, the directory is scanned and files will be checked for write permissions for non-known admins. If a file is found to be user writeable, the executable is blocked from running unless it is authorized by something other than a path rule like a signer or hash rule.<br>
This brings WDAC to functionality parity with AppLocker in terms of support for file path rules. WDAC improves upon the security of policies based on file path rules with the availability of the user-writability permission checks at runtime time, which is a capability that is not available with AppLocker. This brings Windows Defender Application Control (WDAC) to functionality parity with AppLocker in terms of support for file path rules. WDAC improves upon the security of policies based on file path rules with the availability of the user-writability permission checks at runtime time, which is a capability that is not available with AppLocker.
- [Allow COM Object Registration](/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy): Previously, WDAC enforced a built-in allow list for COM object registration. While this mechanism works for most common application usage scenarios, customers have provided feedback that there are cases where additional COM objects need to be allowed. The 1903 update to Windows 10 introduces the ability to specify allowed COM objects via their GUID in the WDAC policy. - [Allow COM Object Registration](/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy): Previously, Windows Defender Application Control (WDAC) enforced a built-in allow list for COM object registration. While this mechanism works for most common application usage scenarios, customers have provided feedback that there are cases where additional COM objects need to be allowed. The 1903 update to Windows 10 introduces the ability to specify allowed COM objects via their GUID in the WDAC policy.
## Identity and privacy ## Identity and privacy

View File

@ -102,11 +102,11 @@ The draft release of the [security configuration baseline settings](/archive/blo
- WDAG allows dynamic navigation: Application Guard now allows users to navigate back to their default host browser from the WDAG Microsoft Edge. Previously, users browsing in WDAG Edge would see an error page when they try to go to a trusted site within the container browser. With this new feature, users will automatically be redirected to their host default browser when they enter or click on a trusted site in WDAG Edge. This feature is also available in Windows 10, version 1803 or later with the latest updates. - WDAG allows dynamic navigation: Application Guard now allows users to navigate back to their default host browser from the WDAG Microsoft Edge. Previously, users browsing in WDAG Edge would see an error page when they try to go to a trusted site within the container browser. With this new feature, users will automatically be redirected to their host default browser when they enter or click on a trusted site in WDAG Edge. This feature is also available in Windows 10, version 1803 or later with the latest updates.
- [Windows Defender Application Control (WDAC)](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control): In Windows 10, version 1903 WDAC has a number of new features that light up key scenarios and provide feature parity with AppLocker. - [Windows Defender Application Control (WDAC)](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control): In Windows 10, version 1903, Windows Defender Application Control has a number of new features that light up key scenarios and provide feature parity with AppLocker.
- [Multiple Policies](/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies): WDAC now supports multiple simultaneous code integrity policies for one device in order to enable the following scenarios: 1) enforce and audit side-by-side, 2) simpler targeting for policies with different scope/intent, 3) expanding a policy using a new supplemental policy. - [Multiple Policies](/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies): Windows Defender Application Control now supports multiple simultaneous code integrity policies for one device in order to enable the following scenarios: 1) enforce and audit side-by-side, 2) simpler targeting for policies with different scope/intent, 3) expanding a policy using a new supplemental policy.
- [Path-Based Rules](/windows/security/threat-protection/windows-defender-application-control/create-path-based-rules): The path condition identifies an app by its location in the file system of the computer or on the network instead of a signer or hash identifier. Additionally, WDAC has an option that allows admins to enforce at runtime that only code from paths that are not user-writeable is executed. When code tries to execute at runtime, the directory is scanned and files will be checked for write permissions for non-known admins. If a file is found to be user writeable, the executable is blocked from running unless it is authorized by something other than a path rule like a signer or hash rule.<br> - [Path-Based Rules](/windows/security/threat-protection/windows-defender-application-control/create-path-based-rules): The path condition identifies an app by its location in the file system of the computer or on the network instead of a signer or hash identifier. Additionally, Windows Defender Application Control has an option that allows admins to enforce at runtime that only code from paths that are not user-writeable is executed. When code tries to execute at runtime, the directory is scanned and files will be checked for write permissions for non-known admins. If a file is found to be user writeable, the executable is blocked from running unless it is authorized by something other than a path rule like a signer or hash rule.<br>
This brings WDAC to functionality parity with AppLocker in terms of support for file path rules. WDAC improves upon the security of policies based on file path rules with the availability of the user-writability permission checks at runtime time, which is a capability that is not available with AppLocker. This brings Windows Defender Application Control (WDAC) to functionality parity with AppLocker in terms of support for file path rules. WDAC improves upon the security of policies based on file path rules with the availability of the user-writability permission checks at runtime time, which is a capability that is not available with AppLocker.
- [Allow COM Object Registration](/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy): Previously, WDAC enforced a built-in allow list for COM object registration. While this mechanism works for most common application usage scenarios, customers have provided feedback that there are cases where additional COM objects need to be allowed. The 1903 update to Windows 10 introduces the ability to specify allowed COM objects via their GUID in the WDAC policy. - [Allow COM Object Registration](/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy): Previously, Windows Defender Application Control enforced a built-in allow list for COM object registration. While this mechanism works for most common application usage scenarios, customers have provided feedback that there are cases where additional COM objects need to be allowed. The 1903 update to Windows 10 introduces the ability to specify allowed COM objects via their GUID in the WDAC policy.
#### System Guard #### System Guard