mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-19 04:13:41 +00:00
Merge pull request #6901 from vinaypamnani-msft/vp-sv2-sac
Smart App Control and Driver Blocklist
This commit is contained in:
Jeff Borsecnik
GitHub
@ -6,7 +6,6 @@
|
||||
items:
|
||||
- name: WDAC and AppLocker Overview
|
||||
href: wdac-and-applocker-overview.md
|
||||
items:
|
||||
- name: WDAC and AppLocker Feature Availability
|
||||
href: feature-availability.md
|
||||
- name: Virtualization-based protection of code integrity
|
||||
@ -310,6 +309,3 @@
|
||||
href: applocker\using-event-viewer-with-applocker.md
|
||||
- name: AppLocker Settings
|
||||
href: applocker\applocker-settings.md
|
||||
- name: Windows security
|
||||
href: /windows/security/
|
||||
|
||||
|
||||
@ -23,9 +23,9 @@ ms.technology: windows-sec
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
- Windows Server 2016 and above
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
- Windows Server 2016 and above
|
||||
|
||||
>[!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).
|
||||
@ -118,9 +118,6 @@ Alice follows these steps to complete this task:
|
||||
|
||||
7. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the Windows Defender Application Control policy to a binary format:
|
||||
|
||||
> [!NOTE]
|
||||
> In the sample commands below, replace the string "{InsertPolicyID}" with the actual PolicyID GUID (including braces **{ }**) found in your policy XML file.
|
||||
|
||||
```powershell
|
||||
[xml]$LamnaPolicyXML = Get-Content $LamnaPolicy
|
||||
$PolicyId = $LamnaPolicyXML.SiPolicy.PolicyId
|
||||
|
||||
@ -13,9 +13,9 @@ audience: ITPro
|
||||
ms.collection: M365-security-compliance
|
||||
author: jsuther1974
|
||||
ms.reviewer: isbrahm
|
||||
ms.author: dansimp
|
||||
manager: dansimp
|
||||
ms.date: 11/15/2019
|
||||
ms.author: vinpa
|
||||
manager: aaroncz
|
||||
ms.date: 08/10/2022
|
||||
ms.technology: windows-sec
|
||||
---
|
||||
|
||||
@ -23,9 +23,9 @@ ms.technology: windows-sec
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
- Windows Server 2016 and above
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
- Windows Server 2016 and above
|
||||
|
||||
>[!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).
|
||||
@ -58,61 +58,84 @@ Based on the above, Alice defines the pseudo-rules for the policy:
|
||||
- WHQL (third-party kernel drivers)
|
||||
- Windows Store signed apps
|
||||
|
||||
2. **"MEMCM works”** rules that include signer and hash rules for Configuration Manager components to properly function.
|
||||
3. **Allow Managed Installer** (Configuration Manager configured as a managed installer)
|
||||
4. **Allow Intelligent Security Graph (ISG)** (reputation-based authorization)
|
||||
5. **Admin-only path rules** for the following locations:
|
||||
1. **"MEMCM works”** rules that include:
|
||||
- Signer and hash rules for Configuration Manager components to properly function.
|
||||
- **Allow Managed Installer** rule to authorize Configuration Manager as a managed installer.
|
||||
|
||||
1. **Allow Intelligent Security Graph (ISG)** (reputation-based authorization)
|
||||
|
||||
1. **Signed apps** using a certificate issued by a Windows Trusted Root Program certificate authority
|
||||
|
||||
1. **Admin-only path rules** for the following locations:
|
||||
- C:\Program Files\*
|
||||
- C:\Program Files (x86)\*
|
||||
- %windir%\*
|
||||
|
||||
## Create a custom base policy using an example WDAC base policy
|
||||
|
||||
Having defined the "circle-of-trust", Alice is ready to generate the initial policy for Lamna's lightly managed devices. Alice decides to use Configuration Manager to create the initial base policy and then customize it to meet Lamna's needs.
|
||||
Having defined the "circle-of-trust", Alice is ready to generate the initial policy for Lamna's lightly managed devices. Alice decides to use the example `SmartAppControl.xml` to create the initial base policy and then customize it to meet Lamna's needs.
|
||||
|
||||
Alice follows these steps to complete this task:
|
||||
|
||||
1. On a client device, run the following commands in an elevated Windows PowerShell session to initialize variables:
|
||||
|
||||
> [!NOTE]
|
||||
> If you do not use Configuration Manager 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 Configuration Manager policy path with your preferred example base policy.
|
||||
|
||||
1. [Use Configuration Manager 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.
|
||||
|
||||
2. On the client device, run the following commands in an elevated Windows PowerShell session to initialize variables:
|
||||
> If you prefer to use a different [example Windows Defender Application Control base policy](example-wdac-base-policies.md), substitute the example policy path with your preferred base policy in this step.
|
||||
|
||||
```powershell
|
||||
$PolicyPath = $env:userprofile+"\Desktop\"
|
||||
$PolicyName= "Lamna_LightlyManagedClients_Audit"
|
||||
$LamnaPolicy=$env:userprofile+"\Desktop\"+$PolicyName+".xml"
|
||||
$MEMCMPolicy=$env:windir+"\CCM\DeviceGuard\MergedPolicy_Audit_ISG.xml"
|
||||
$LamnaPolicy=Join-Path $PolicyPath "$PolicyName.xml"
|
||||
$ExamplePolicy=$env:windir+"\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml"
|
||||
```
|
||||
|
||||
3. Copy the policy created by Configuration Manager to the desktop:
|
||||
1. Copy the example policy to the desktop:
|
||||
|
||||
```powershell
|
||||
cp $MEMCMPolicy $LamnaPolicy
|
||||
Copy-Item $ExamplePolicy $LamnaPolicy
|
||||
```
|
||||
|
||||
4. Give the new policy a unique ID, descriptive name, and initial version number:
|
||||
1. Modify the policy to remove unsupported rule:
|
||||
|
||||
> [!NOTE]
|
||||
> `SmartAppControl.xml` is available on Windows 11 version 22H2 and later. This policy includes "Enabled:Conditional Windows Lockdown Policy" rule that is unsupported for enterprise WDAC policies and must be removed. For more information, see [WDAC and Smart App Control](windows-defender-application-control.md#wdac-and-smart-app-control). If you are using an example policy other than `SmartAppControl.xml`, skip this step.
|
||||
|
||||
```powershell
|
||||
[xml]$xml = Get-Content $LamnaPolicy
|
||||
$ns = New-Object System.Xml.XmlNamespaceManager($xml.NameTable)
|
||||
$ns.AddNamespace("ns", $xml.DocumentElement.NamespaceURI)
|
||||
$node = $xml.SelectSingleNode("//ns:Rules/ns:Rule[ns:Option[.='Enabled:Conditional Windows Lockdown Policy']]", $ns)
|
||||
$node.ParentNode.RemoveChild($node)
|
||||
$xml.Save($LamnaPolicy)
|
||||
```
|
||||
|
||||
1. Give the new policy a unique ID, descriptive name, and initial version number:
|
||||
|
||||
```powershell
|
||||
Set-CIPolicyIdInfo -FilePath $LamnaPolicy -PolicyName $PolicyName -ResetPolicyID
|
||||
Set-CIPolicyVersion -FilePath $LamnaPolicy -Version "1.0.0.0"
|
||||
```
|
||||
|
||||
5. Modify the copied policy to set policy rules:
|
||||
1. [Use Configuration Manager to create and deploy an audit policy](/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager) to the client device running Windows 10 version 1903 and above, or Windows 11. Merge the Configuration Manager policy with the example policy.
|
||||
|
||||
> [!NOTE]
|
||||
> If you do not use Configuration Manager, skip this step.
|
||||
|
||||
```powershell
|
||||
$MEMCMPolicy=$env:windir+"\CCM\DeviceGuard\MergedPolicy_Audit_ISG.xml"
|
||||
Merge-CIPolicy -OutputFilePath $LamnaPolicy -PolicyPaths $LamnaPolicy,$MEMCMPolicy
|
||||
Set-RuleOption -FilePath $LamnaPolicy -Option 13 # Managed Installer
|
||||
```
|
||||
|
||||
1. Modify the policy to set additional policy rules:
|
||||
|
||||
```powershell
|
||||
Set-RuleOption -FilePath $LamnaPolicy -Option 3 # Audit Mode
|
||||
Set-RuleOption -FilePath $LamnaPolicy -Option 6 # Unsigned Policy
|
||||
Set-RuleOption -FilePath $LamnaPolicy -Option 9 # Advanced Boot Menu
|
||||
Set-RuleOption -FilePath $LamnaPolicy -Option 12 # Enforce Store Apps
|
||||
Set-RuleOption -FilePath $LamnaPolicy -Option 13 # Managed Installer
|
||||
Set-RuleOption -FilePath $LamnaPolicy -Option 14 # ISG
|
||||
Set-RuleOption -FilePath $LamnaPolicy -Option 16 # No Reboot
|
||||
Set-RuleOption -FilePath $LamnaPolicy -Option 17 # Allow Supplemental
|
||||
Set-RuleOption -FilePath $LamnaPolicy -Option 19 # Dynamic Code Security
|
||||
```
|
||||
|
||||
6. Add rules to allow windir and Program Files directories:
|
||||
1. Add rules to allow windir and Program Files directories:
|
||||
|
||||
```powershell
|
||||
$PathRules += New-CIPolicyRule -FilePathRule "%windir%\*"
|
||||
@ -121,19 +144,17 @@ Alice follows these steps to complete this task:
|
||||
Merge-CIPolicy -OutputFilePath $LamnaPolicy -PolicyPaths $LamnaPolicy -Rules $PathRules
|
||||
```
|
||||
|
||||
7. If appropriate, add more signer or file rules to further customize the policy for your organization.
|
||||
1. If appropriate, add more signer or file rules to further customize the policy for your organization.
|
||||
|
||||
8. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the WDAC policy to a binary format:
|
||||
|
||||
> [!NOTE]
|
||||
> In the sample commands below, replace the string "{InsertPolicyID}" with the actual PolicyID GUID (including braces **{ }**) found in your policy XML file.
|
||||
1. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the Windows Defender Application Control policy to a binary format:
|
||||
|
||||
```powershell
|
||||
$WDACPolicyBin=$env:userprofile+"\Desktop\"+$PolicyName+"_{InsertPolicyID}.bin"
|
||||
[xml]$policyXML = Get-Content $LamnaPolicy
|
||||
$WDACPolicyBin = Join-Path $PolicyPath "$($PolicyName)_$($policyXML.SiPolicy.PolicyID).cip"
|
||||
ConvertFrom-CIPolicy $LamnaPolicy $WDACPolicyBin
|
||||
```
|
||||
|
||||
9. Upload your base policy XML and the associated binary to 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).
|
||||
1. Upload your base policy XML and the associated binary to 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).
|
||||
|
||||
At this point, Alice now has an initial policy that is ready to deploy in audit mode to the managed clients within Lamna.
|
||||
|
||||
@ -141,44 +162,69 @@ At this point, Alice now has an initial policy that is ready to deploy in audit
|
||||
|
||||
In order to minimize user productivity impact, Alice has defined a policy that makes several trade-offs between security and user app flexibility. Some of the trade-offs include:
|
||||
|
||||
- **Users with administrative access**<br>
|
||||
- **Users with administrative access**
|
||||
|
||||
By far the most impactful security trade-off, this trade-off allows the device user (or malware running with the user's privileges) to modify or remove altogether the WDAC policy applied on the device. Additionally, administrators can configure any app they wish to operate as a managed installer that would allow them to gain persistent app authorization for whatever apps or binaries they wish.
|
||||
|
||||
Possible mitigations:
|
||||
|
||||
- Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies.
|
||||
- Create and deploy signed catalog files as part of the app deployment process in order to remove the requirement for managed installer.
|
||||
- Use device attestation to detect the configuration state of WDAC at boot time and use that information to condition access to sensitive corporate resources.
|
||||
- **Unsigned policies**<br>
|
||||
|
||||
- **Unsigned policies**
|
||||
|
||||
Unsigned policies can be replaced or removed without consequence by any process running as administrator. Unsigned base policies that also enable supplemental policies can have their "circle-of-trust" altered by any unsigned supplemental policy.
|
||||
|
||||
Possible mitigations:
|
||||
|
||||
- Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies.
|
||||
- Limit who can elevate to administrator on the device.
|
||||
- **Managed installer**<br>
|
||||
|
||||
- **Managed installer**
|
||||
|
||||
See [security considerations with managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md#security-considerations-with-managed-installer)
|
||||
|
||||
Possible mitigations:
|
||||
|
||||
- Create and deploy signed catalog files as part of the app deployment process in order to remove the requirement for managed installer.
|
||||
- Limit who can elevate to administrator on the device.
|
||||
- **Intelligent Security Graph (ISG)**<br>
|
||||
|
||||
- **Intelligent Security Graph (ISG)**
|
||||
|
||||
See [security considerations with the Intelligent Security Graph](use-windows-defender-application-control-with-intelligent-security-graph.md#security-considerations-with-the-intelligent-security-graph)
|
||||
|
||||
Possible mitigations:
|
||||
|
||||
- Implement policies requiring apps are managed by IT; audit existing app usage and deploy authorized apps using a software distribution solution such as Microsoft Endpoint Manager; move from ISG to managed installer or signature-based rules.
|
||||
- Use a restrictive audit mode policy to audit app usage and augment vulnerability detection.
|
||||
- **Supplemental policies**<br>
|
||||
|
||||
- **Supplemental policies**
|
||||
|
||||
Supplemental policies are designed to relax the associated base policy. Additionally allowing unsigned policies allows any administrator process to expand the "circle-of-trust" defined by the base policy without restriction.
|
||||
|
||||
Possible mitigations:
|
||||
|
||||
- Use signed WDAC policies that allow authorized signed supplemental policies only.
|
||||
- Use a restrictive audit mode policy to audit app usage and augment vulnerability detection.
|
||||
- **FilePath rules**<br>
|
||||
|
||||
- **FilePath rules**
|
||||
|
||||
See [more information about filepath rules](select-types-of-rules-to-create.md#more-information-about-filepath-rules)
|
||||
|
||||
Possible mitigations:
|
||||
|
||||
- Limit who can elevate to administrator on the device.
|
||||
- Migrate from filepath rules to managed installer or signature-based rules.
|
||||
|
||||
- **Signed files**
|
||||
|
||||
Although files that are code-signed verify the author's identity and ensures that the code has not been altered by anyone other than the author, it does not guarantee that the signed code is safe.
|
||||
|
||||
Possible mitigations:
|
||||
|
||||
- Use a reputable antimalware or antivirus software with real-time protection, such as Microsoft Defender, to protect your devices from malicious files, adware, and other threats.
|
||||
|
||||
## Up next
|
||||
|
||||
- [Create a Windows Defender Application Control policy for fully managed devices](create-wdac-policy-for-fully-managed-devices.md)
|
||||
|
||||
@ -15,7 +15,7 @@ author: jsuther1974
|
||||
ms.reviewer: jogeurte
|
||||
ms.author: dansimp
|
||||
manager: dansimp
|
||||
ms.date: 11/15/2019
|
||||
ms.date: 08/05/2022
|
||||
ms.technology: windows-sec
|
||||
---
|
||||
|
||||
@ -23,9 +23,9 @@ ms.technology: windows-sec
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
- Windows Server 2016 and above
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
- Windows Server 2016 and above
|
||||
|
||||
>[!NOTE]
|
||||
>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).
|
||||
@ -39,7 +39,8 @@ 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](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 |
|
||||
| **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 Windows Defender Application Control. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
|
||||
| **AllowAll_EnableHVCI.xml** | This example policy can be used to enable [memory integrity](https://support.microsoft.com/windows/core-isolation-e30ed737-17d8-42f3-a2a9-87521df09b78) (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 |
|
||||
| **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 Configuration Manager can deploy a policy with Configuration Manager'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 |
|
||||
| **SmartAppControl.xml** | This example policy includes rules based on [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) that are well-suited for lightly managed systems. This policy includes a rule that is unsupported for enterprise WDAC policies and must be removed. For more information about using this example policy, see [Create a custom base policy using an example WDAC base policy](create-wdac-policy-for-lightly-managed-devices.md#create-a-custom-base-policy-using-an-example-wdac-base-policy)). | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
|
||||
|
||||
@ -21,6 +21,8 @@ landingContent:
|
||||
linkLists:
|
||||
- linkListType: overview
|
||||
links:
|
||||
- text: What is Application Control?
|
||||
url: windows-defender-application-control.md
|
||||
- text: What is Windows Defender Application Control (WDAC)?
|
||||
url: wdac-and-applocker-overview.md
|
||||
- text: What is AppLocker?
|
||||
|
||||
@ -15,16 +15,16 @@ author: jsuther1974
|
||||
ms.reviewer: isbrahm
|
||||
ms.author: dansimp
|
||||
manager: dansimp
|
||||
ms.date: 09/29/2021
|
||||
ms.date: 08/11/2022
|
||||
---
|
||||
|
||||
# Microsoft recommended block rules
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
- Windows Server 2016 and above
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
- Windows Server 2016 and above
|
||||
|
||||
>[!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).
|
||||
@ -100,9 +100,7 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
|
||||
| `Vladas Bulavas` | `Kaspersky Lab` |
|
||||
| `William Easton` | `@Strawgate` |
|
||||
|
||||
<br />
|
||||
|
||||
> [!Note]
|
||||
> [!NOTE]
|
||||
> This application list will be updated with the latest vendor information as application vulnerabilities are resolved and new issues are discovered.
|
||||
|
||||
Certain software applications may allow other code to run by design. Such applications should be blocked by your Windows Defender Application Control policy. In addition, when an application version is upgraded to fix a security vulnerability or potential Windows Defender Application Control bypass, you should add *deny* rules to your application control policies for that application’s previous, less secure versions.
|
||||
@ -119,6 +117,10 @@ Microsoft recommends that you block the following Microsoft-signed applications
|
||||
|
||||
Select the correct version of each .dll for the Windows release you plan to support, and remove the other versions. Ensure that you also uncomment them in the signing scenarios section.
|
||||
|
||||
<br>
|
||||
<details>
|
||||
<summary>Expand this section to see the WDAC policy XML</summary>
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
|
||||
@ -1524,9 +1526,10 @@ Select the correct version of each .dll for the Windows release you plan to supp
|
||||
<HvciOptions>0</HvciOptions>
|
||||
</SiPolicy>
|
||||
```
|
||||
<br />
|
||||
|
||||
> [!Note]
|
||||
</details>
|
||||
|
||||
> [!NOTE]
|
||||
> To create a policy that works on both Windows 10, version 1803 and version 1809, you can create two different policies, or merge them into one broader policy.
|
||||
|
||||
## More information
|
||||
|
||||
@ -20,28 +20,49 @@ manager: dansimp
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
- Windows Server 2016 and above
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
- Windows Server 2016 and above
|
||||
|
||||
>[!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).
|
||||
|
||||
Microsoft has strict requirements for code running in kernel. So, malicious actors are turning to exploit vulnerabilities in legitimate and signed kernel drivers to run malware in kernel. One of the many strengths of the Windows platform is our strong collaboration with independent hardware vendors (IHVs) and OEMs. Microsoft works closely with our IHVs and security community to ensure the highest level of driver security for our customers and when vulnerabilities in drivers do arise, that they're quickly patched and rolled out to the ecosystem. Microsoft then adds the vulnerable versions of the drivers to our ecosystem block policy, which is applied to the following sets of devices:
|
||||
|
||||
- Hypervisor-protected code integrity (HVCI) enabled devices
|
||||
- Windows 10 in S mode (S mode) devices
|
||||
|
||||
The vulnerable driver blocklist is designed to help harden systems against third party-developed drivers across the Windows ecosystem with any of the following attributes:
|
||||
Microsoft has strict requirements for code running in kernel. So, malicious actors are turning to exploit vulnerabilities in legitimate and signed kernel drivers to run malware in kernel. One of the many strengths of the Windows platform is our strong collaboration with independent hardware vendors (IHVs) and OEMs. Microsoft works closely with our IHVs and security community to ensure the highest level of driver security for our customers and when vulnerabilities in drivers do arise, that they're quickly patched and rolled out to the ecosystem. The vulnerable driver blocklist is designed to help harden systems against third party-developed drivers across the Windows ecosystem with any of the following attributes:
|
||||
|
||||
- Known security vulnerabilities that can be exploited by attackers to elevate privileges in the Windows kernel
|
||||
- Malicious behaviors (malware) or certificates used to sign malware
|
||||
- Behaviors that aren't malicious but circumvent the Windows Security Model and can be exploited by attackers to elevate privileges in the Windows kernel
|
||||
|
||||
Drivers can be submitted to Microsoft for security analysis at the [Microsoft Security Intelligence Driver Submission page](https://www.microsoft.com/en-us/wdsi/driversubmission). To report an issue or request a change to the vulnerable driver blocklist, including updating a block rule once a driver vulnerability has been patched, visit the [Microsoft Security Intelligence portal](https://www.microsoft.com/wdsi) or submit feedback on this article.
|
||||
Drivers can be submitted to Microsoft for security analysis at the [Microsoft Security Intelligence Driver Submission page](https://www.microsoft.com/en-us/wdsi/driversubmission). For more information about driver submission, see [Improve kernel security with the new Microsoft Vulnerable and Malicious Driver Reporting Center
|
||||
](https://www.microsoft.com/security/blog/2021/12/08/improve-kernel-security-with-the-new-microsoft-vulnerable-and-malicious-driver-reporting-center/). To report an issue or request a change to the vulnerable driver blocklist, including updating a block rule once a driver vulnerability has been patched, visit the [Microsoft Security Intelligence portal](https://www.microsoft.com/wdsi) or submit feedback on this article.
|
||||
|
||||
## Microsoft vulnerable driver blocklist
|
||||
|
||||
<!-- MAXADO-6286432 -->
|
||||
|
||||
Microsoft adds the vulnerable versions of the drivers to our vulnerable driver blocklist, which is automatically enabled on devices when any of the listed conditions are met:
|
||||
|
||||
| Condition | Windows 10 or 11 | Windows 11 22H2 or later |
|
||||
|--|:--:|:--:|
|
||||
| Device has [Hypervisor-protected code integrity (HVCI)](../device-guard/enable-virtualization-based-protection-of-code-integrity.md) enabled | :heavy_check_mark: | :heavy_check_mark: |
|
||||
| Device is in [S mode](https://support.microsoft.com/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85#WindowsVersion=Windows_11) | :heavy_check_mark: | :heavy_check_mark: |
|
||||
| Device has [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) enabled | :x: | :heavy_check_mark: |
|
||||
| Clean install of Windows | :x: | :heavy_check_mark: |
|
||||
|
||||
> [!NOTE]
|
||||
> Microsoft vulnerable driver blocklist can also be enabled using [Windows Security](https://support.microsoft.com/windows/device-protection-in-windows-security-afa11526-de57-b1c5-599f-3a4c6a61c5e2), but the option to disable it is grayed out when HVCI or Smart App Control is enabled, or when the device is in S mode. You must disable HVCI or Smart App Control, or switch the device out of S mode, and restart the device before you can disable Microsoft vulnerable driver blocklist.
|
||||
|
||||
## Blocking vulnerable drivers using WDAC
|
||||
|
||||
Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity) or S mode to protect your devices against security threats. If this setting isn't possible, Microsoft recommends blocking this list of drivers within your existing Windows Defender Application Control policy. Blocking kernel drivers without sufficient testing can result in devices or software to malfunction, and in rare cases, blue screen. It's recommended to first validate this policy in [audit mode](audit-windows-defender-application-control-policies.md) and review the audit block events.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Microsoft also recommends enabling Attack Surface Reduction (ASR) rule [**Block abuse of exploited vulnerable signed drivers**](/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-reference#block-abuse-of-exploited-vulnerable-signed-drivers) to prevent an application from writing a vulnerable signed driver to disk. The ASR rule doesn't block a driver already existing on the system from being loaded, however enabling **Microsoft vulnerable driver blocklist** or applying this WDAC policy prevents the existing driver from being loaded.
|
||||
|
||||
<br>
|
||||
<details>
|
||||
<summary>Expand this section to see the blocklist WDAC policy XML</summary>
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
|
||||
@ -207,9 +228,9 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
|
||||
<Deny ID="ID_DENY_DIRECTIO_34" FriendlyName="PassMark DirectIo.sys Hash Page Sha1" Hash="05E20D0274A4FCC5368F25C62174003A555917E7" />
|
||||
<Deny ID="ID_DENY_DIRECTIO_35" FriendlyName="PassMark DirectIo.sys Hash Page Sha256" Hash="70344F2494D6B7EE4C5716E886D912447CFFE9695D2286814DC3CE0361727BBA" />
|
||||
<Deny ID="ID_DENY_DIRECTIO_36" FriendlyName="PassMark DirectIo.sys Hash Sha1" Hash="706686F2A1EF4738A1856D01AB10EB730FC7B327" />
|
||||
<Deny ID="ID_DENY_DIRECTIO_37" FriendlyName="PassMark DirectIo.sys Hash Sha256" Hash="B74246C8CB77B0364B7CECE38BFF5F462EEC983C" />
|
||||
<Deny ID="ID_DENY_DIRECTIO_37" FriendlyName="PassMark DirectIo.sys Hash Sha1" Hash="B74246C8CB77B0364B7CECE38BFF5F462EEC983C" />
|
||||
<Deny ID="ID_DENY_DIRECTIO_38" FriendlyName="PassMark DirectIo.sys Hash Sha1" Hash="B423CA58603513B5D3A9669736D5E13C353FD6F9" />
|
||||
<Deny ID="ID_DENY_DIRECTIO_39" FriendlyName="PassMark DirectIo.sys Hash Sha1" Hash="2FB5D7E6DB01C9090BBA92ABF580D38993E02CE9357E08FE1F224A9B18056E5A" />
|
||||
<Deny ID="ID_DENY_DIRECTIO_39" FriendlyName="PassMark DirectIo.sys Hash Sha256" Hash="2FB5D7E6DB01C9090BBA92ABF580D38993E02CE9357E08FE1F224A9B18056E5A" />
|
||||
<Deny ID="ID_DENY_DIRECTIO_3A" FriendlyName="PassMark DirectIo.sys Hash Sha1" Hash="AE806CA05E141B71664D9C6F20CC2369EF26F996" />
|
||||
<Deny ID="ID_DENY_DIRECTIO_3B" FriendlyName="PassMark DirectIo.sys Hash Sha1" Hash="D0559503988DAA407FCC11E59079560CB456BB84" />
|
||||
<Deny ID="ID_DENY_MSIO_SHA1_1" FriendlyName="MsIo.sys Hash Sha1" Hash="0CB0FD5BEA730E4EAAEC1426B0C15376CCAC6D83" />
|
||||
@ -1198,8 +1219,11 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
|
||||
</Settings>
|
||||
</SiPolicy>
|
||||
```
|
||||
<br />
|
||||
|
||||
</details>
|
||||
|
||||
> [!NOTE]
|
||||
> The policy listed above contains **Allow All** rules. Microsoft recommends deploying this policy alongside an existing WDAC policy instead of merging it with the existing policy. If you must use a single policy, remove the **Allow All** rules before merging it with the existing policy. For more information, see [Create a WDAC Deny Policy](create-wdac-deny-policy.md#single-policy-considerations).
|
||||
|
||||
## More information
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ author: dansimp
|
||||
ms.reviewer: isbrahm
|
||||
ms.author: dansimp
|
||||
manager: dansimp
|
||||
ms.date: 06/28/2022
|
||||
ms.date: 08/12/2022
|
||||
ms.technology: windows-sec
|
||||
---
|
||||
|
||||
@ -22,9 +22,9 @@ ms.technology: windows-sec
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
- Windows Server 2016 and above
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
- Windows Server 2016 and above
|
||||
|
||||
> [!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).
|
||||
@ -70,7 +70,7 @@ You can set several rule options within a WDAC policy. Table 1 describes each ru
|
||||
| **11 Disabled: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).<br/> NOTE: This option is required to run HTA files, and is supported on 1709, 1803, and 1809 builds with the 2019 10C LCU or higher, and on devices with the Windows 10 May 2019 Update (1903) and higher. Using it on versions of Windows without the proper update may have unintended results. | No |
|
||||
| **12 Required:Enforce Store Applications** | If this rule option is enabled, WDAC policies will also apply to Universal Windows applications. | No |
|
||||
| **13 Enabled:Managed Installer** | Use this option to automatically allow applications installed by a managed installer. For more information, see [Authorize apps deployed with a WDAC managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) | Yes |
|
||||
| **14 Enabled:Intelligent Security Graph Authorization** | Use this option to automatically allow applications with "known good" reputation as defined by Microsoft’s Intelligent Security Graph (ISG). | Yes |
|
||||
| **14 Enabled:Intelligent Security Graph Authorization** | Use this option to automatically allow applications with "known good" reputation as defined by Microsoft's Intelligent Security Graph (ISG). | Yes |
|
||||
| **15 Enabled:Invalidate EAs on Reboot** | When the Intelligent Security Graph option (14) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. This option will cause WDAC to periodically revalidate the reputation for files that were authorized by the ISG.| No |
|
||||
| **16 Enabled:Update Policy No Reboot** | Use this option to allow future WDAC policy updates to apply without requiring a system reboot.<br/> NOTE: This option is only supported on Windows 10, version 1709 and above.| No |
|
||||
| **17 Enabled:Allow Supplemental Policies** | Use this option on a base policy to allow supplemental policies to expand it.<br/> NOTE: This option is only supported on Windows 10, version 1903 and above. | No |
|
||||
@ -88,12 +88,12 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
|
||||
|
||||
| Rule level | Description |
|
||||
|----------- | ----------- |
|
||||
| **Hash** | Specifies individual [Authenticode/PE image hash values](#more-information-about-hashes) for each discovered binary. This level is the most specific level, and requires more effort to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. |
|
||||
| **Hash** | Specifies individual [Authenticode/PE image hash values](#more-information-about-hashes) for each discovered binary. This level is the most specific level, and requires more effort to maintain the current product versions' hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. |
|
||||
| **FileName** | Specifies the original filename for each binary. Although the hash values for an application are modified when updated, the file names are typically not. This level offers less specific security than the hash level, but it doesn't typically require a policy update when any binary is modified. |
|
||||
| **FilePath** | Beginning with Windows 10 version 1903, this level allows binaries to run from specific file path locations. FilePath rules only apply to user mode binaries and can't be used to allow kernel mode drivers. More information about FilePath level rules can be found below. |
|
||||
| **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). |
|
||||
| **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. When this level is used, 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). |
|
||||
| **RootCertificate** | Currently unsupported. |
|
||||
@ -105,9 +105,17 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
|
||||
> 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]
|
||||
>
|
||||
> - WDAC only supports signer rules for RSA certificate signing keys with a maximum of 4096 bits.
|
||||
> - The code uses CN for the CertSubject and CertIssuer fields in the policy. You can use the inbox certutil to look at the underlying format to ensure UTF-8 is not being used for the CN. For example, you can use printable string, IA5, or BMP.
|
||||
|
||||
> [!NOTE]
|
||||
> When applicable, minimum and maximum version numbers in a file rule are referenced as MinimumFileVersion and MaximumFileVersion respectively in the policy XML.
|
||||
>
|
||||
> - Both MinimumFileVersion and MaximumFileVersion specified: For Allow rules, file with version **greater than or equal** to MinimumFileVersion and **less than or equal** to MaximumFileVersion are allowed. For Deny rules, file with version **greater than or equal** to MinimumFileVersion and **less than or equal** to MaximumFileVersion are denied.
|
||||
> - MinimumFileVersion specified without MaximumFileVersion: For Allow rules, file with version **greater than or equal** to the specified version are allowed to run. For Deny rules, file with version **less than or equal** to the specified version are blocked.
|
||||
> - MaximumFileVersion specified without MinimumFileVersion: For Allow rules, file with version **less than or equal** to the specified version are allowed to run. For Deny rules, file with version **greater than or equal** to the specified version are blocked.
|
||||
|
||||
## Example of file rule levels in use
|
||||
|
||||
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.
|
||||
@ -155,11 +163,11 @@ The Authenticode/PE image hash can be calculated for digitally signed and unsign
|
||||
The PowerShell cmdlet will produce an Authenticode Sha1 Hash, Sha256 Hash, Sha1 Page Hash, Sha256 Page Hash.
|
||||
During validation, CI will choose which hashes to calculate, depending on how the file is signed. For example, if the file is page-hash signed the entire file wouldn't get paged in to do a full sha256 authenticode, and we would just match using the first page hash.
|
||||
|
||||
In the cmdlets, rather than try to predict which hash CI will use, we pre-calculate and use the four hashes (sha1/sha2 authenticode, and sha1/sha2 of first page). This method is also resilient, if the signing status of the file changes and necessary for deny rules to ensure that changing/stripping the signature doesn’t result in a different hash than what was in the policy being used by CI.
|
||||
In the cmdlets, rather than try to predict which hash CI will use, we pre-calculate and use the four hashes (sha1/sha2 authenticode, and sha1/sha2 of first page). This method is also resilient, if the signing status of the file changes and necessary for deny rules to ensure that changing/stripping the signature doesn't result in a different hash than what was in the policy being used by CI.
|
||||
|
||||
### Why does scan create eight hash rules for certain XML files?
|
||||
|
||||
Separate rules are created for UMCI and KMCI. In some cases, files that are purely user-mode or purely kernel-mode may still generate both sets, since CI can’t always precisely determine what is purely user vs. kernel mode, and errs on the side of caution.
|
||||
Separate rules are created for UMCI and KMCI. In some cases, files that are purely user-mode or purely kernel-mode may still generate both sets, since CI can't always precisely determine what is purely user vs. kernel mode, and errs on the side of caution.
|
||||
|
||||
## Windows Defender Application Control filename rules
|
||||
|
||||
|
||||
@ -46,15 +46,24 @@ Windows 10 and Windows 11 include two technologies that can be used for applicat
|
||||
- **Windows Defender Application Control (WDAC)**; and
|
||||
- **AppLocker**
|
||||
|
||||
## In this section
|
||||
## WDAC and Smart App Control
|
||||
|
||||
| Article | Description |
|
||||
| --- | --- |
|
||||
| [WDAC and AppLocker Overview](wdac-and-applocker-overview.md) | This article describes the decisions you need to make to establish the processes for managing and maintaining WDAC policies. |
|
||||
| [WDAC and AppLocker Feature Availability](feature-availability.md) | This article lists the design questions, possible answers, and ramifications of the decisions when you plan a deployment of application control policies. |
|
||||
Starting in Windows 11 version 22H2, [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) provides application control for consumers. Smart App Control is based on WDAC, allowing enterprise customers to create a policy that offers the same security and compatibility with the ability to customize it to run line-of-business (LOB) apps. To make it easier to implement this policy, an [example policy](example-wdac-base-policies.md) is provided. The example policy includes **Enabled:Conditional Windows Lockdown Policy** rule which isn't supported for WDAC enterprise policies. This rule must be removed before you use the example policy. To use this example policy as a starting point for creating your own policy, see [Create a custom base policy using an example WDAC base policy](create-wdac-policy-for-lightly-managed-devices.md#create-a-custom-base-policy-using-an-example-wdac-base-policy).
|
||||
|
||||
Smart App Control is only available on clean installation of Windows 11 version 22H2 or later, and starts in evaluation mode. Smart App Control will automatically turn off for enterprise managed devices unless the user has turned it on first. To turn Smart App Control on or off across your organization's endpoints, you can set the **VerifiedAndReputablePolicyState** (DWORD) registry value under `HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy` to one of the values listed below. After you change the registry value, you must either restart the device or run [RefreshPolicy.exe](https://www.microsoft.com/download/details.aspx?id=102925) for the change to take effect.
|
||||
|
||||
| Value | Description |
|
||||
|-------|-------------|
|
||||
| 0 | Off |
|
||||
| 1 | Enforce |
|
||||
| 2 | Evaluation |
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Once you turn Smart App Control off, it can't be turned on without resetting or reinstalling Windows.
|
||||
|
||||
## Related articles
|
||||
|
||||
- [WDAC design guide](windows-defender-application-control-design-guide.md)
|
||||
- [WDAC deployment guide](windows-defender-application-control-deployment-guide.md)
|
||||
- [WDAC operational guide](windows-defender-application-control-operational-guide.md)
|
||||
- [AppLocker overview](applocker/applocker-overview.md)
|
||||
Reference in New Issue
Block a user