deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-28 05:07:23 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Merge pull request #8393 from MicrosoftDocs/main

Browse Source 
Publish main to live, Wednesday 10:30AM PDT, 6/14
This commit is contained in:
Stacyrch140 2023-06-14 13:41:24 -04:00 committed by GitHub
commit 3e1bf3f1de
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 43 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
windows/security/threat-protection/windows-defender-application-control/AppIdTagging/design-create-appid-tagging-policies.md
View File

@ -35,9 +35,14 @@ You can use the Windows Defender Application Control (WDAC) Wizard and the Power
1. Create a new base policy using the templates:
Start with the Policy Creator task and select Multiple Policy Format and Base Policy. Select the Base Template to use for the policy. The example below shows beginning with the [Default Windows Mode](../wdac-wizard-create-base-policy.md#template-base-policies) template and build on top of these rules.
Start with the Policy Creator task and select Multiple Policy Format and Base Policy. Select the Base Template to use for the policy. The following example shows beginning with the [Default Windows Mode](../wdac-wizard-create-base-policy.md#template-base-policies) template and build on top of these rules.
![Configuring the policy base and template.](../images/appid-wdac-wizard-1.png)
> [!NOTE]
> If your AppId Tagging Policy does build off the base templates or does not allow Windows in-box processes, you will notice significant performance regressions, especially during boot. For this reason, it is strongly recommended to build off the base templates.
For more information on the issue, see the [AppId Tagging Known Issue](../operations/known-issues.md#slow-boot-and-performance-with-custom-policies).
2. Set the following rule-options using the Wizard toggles:
@ -45,7 +50,7 @@ You can use the Windows Defender Application Control (WDAC) Wizard and the Power
3. Create custom rules:
Selecting the `+ Custom Rules` button will open the Custom Rules panel. The Wizard supports five types of file rules:
Selecting the `+ Custom Rules` button opens the Custom Rules panel. The Wizard supports five types of file rules:
- Publisher rules: Create a rule based off the signing certificate hierarchy. Additionally, the original filename and version can be combined with the signing certificate for added security.
- Path rules: Create a rule based off the path to a file or a parent folder path. Path rules support wildcards.
@ -58,16 +63,16 @@ You can use the Windows Defender Application Control (WDAC) Wizard and the Power
4. Convert to AppId Tagging Policy:
After the Wizard builds the policy file, open the file in a text editor and remove the entire "Value=131" SigningScenario text block. The only remaining signing scenario should be "Value=12" which is the usermode application section. Next, open PowerShell in an elevated prompt and run the following command. Replace the AppIdTagging Key-Value pair for your scenario:
After the Wizard builds the policy file, open the file in a text editor and remove the entire "Value=131" SigningScenario text block. The only remaining signing scenario should be "Value=12" which is the user mode application section. Next, open PowerShell in an elevated prompt and run the following command. Replace the AppIdTagging Key-Value pair for your scenario:
```powershell
Set-CIPolicyIdInfo -ResetPolicyID -FilePath .\AppIdPolicy.xml -AppIdTaggingPolicy -AppIdTaggingKey "MyKey" -AppIdTaggingValue "MyValue"
```
The policyID GUID will be returned by PowerShell if successful.
The policyID GUID is returned by the PowerShell command if successful.
## Create the policy using PowerShell
Using this method, you'll create an AppId Tagging policy directly using the WDAC PowerShell commands. These PowerShell commands are only available on the supported platforms listed in [AppId Tagging Guide](./windows-defender-application-control-appid-tagging-guide.md). In an elevate PowerShell instance:
Using this method, you create an AppId Tagging policy directly using the WDAC PowerShell commands. These PowerShell commands are only available on the supported platforms listed in [AppId Tagging Guide](./windows-defender-application-control-appid-tagging-guide.md). In an elevate PowerShell instance:
1. Create an AppId rule for the policy based on a combination of the signing certificate chain and version of the application. In the example below, the level has been set to SignedVersion. Any of the [WDAC File Rule Levels](../select-types-of-rules-to-create.md#table-2-windows-defender-application-control-policy---file-rule-levels) can be used in AppId rules:
@ -87,14 +92,14 @@ Using this method, you'll create an AppId Tagging policy directly using the WDAC
Set-RuleOption -Option 18 .\AppIdPolicy.xml # (Optional) Disable FilePath Rule Protection
```
If you're using filepath rules, you'll likely want to set option 18. Otherwise, there's no need.
If you're using filepath rules, you may want to set option 18. Otherwise, there's no need.
4. Set the name and ID on the policy, which is helpful for future debugging:
```powershell
Set-CIPolicyIdInfo -ResetPolicyId -PolicyName "MyPolicyName" -PolicyId "MyPolicyId"" -AppIdTaggingPolicy -FilePath ".\AppIdPolicy.xml"
```
The policyID GUID will be returned by PowerShell if successful.
The policyID GUID is returned by the PowerShell command if successful.
## Deploy for Local Testing

BIN
windows/security/threat-protection/windows-defender-application-control/images/known-issue-appid-dll-rule-xml.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 21 KiB

BIN
windows/security/threat-protection/windows-defender-application-control/images/known-issue-appid-dll-rule.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

22
windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules.md
View File

@ -8,7 +8,7 @@ author: jsuther1974
ms.reviewer: jgeurten
ms.author: vinpa
manager: aaroncz
ms.date: 11/04/2022
ms.date: 06/13/2023
ms.topic: reference
---
@ -25,7 +25,7 @@ ms.topic: reference
Members of the security community<sup>*</sup> continuously collaborate with Microsoft to help protect customers. With the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also potentially use to bypass WDAC.
Unless your use scenarios explicitly require them, Microsoft recommends that you block the following applications. These applications or files can be used by an attacker to circumvent application allow policies, including WDAC:
Unless your use scenarios explicitly require them, Microsoft recommends that you block the following applications. An attacker can use these applications or files to circumvent application allow policies, including WDAC:
- addinprocess.exe
- addinprocess32.exe
@ -72,7 +72,7 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
<sup>1</sup> A vulnerability in bginfo.exe was fixed in version 4.22. If you use BGInfo, for security, make sure to download and run the latest version of [BGInfo](/sysinternals/downloads/bginfo). BGInfo versions earlier than 4.22 are still vulnerable and should be blocked.
<sup>2</sup> If you're using your reference system in a development context and use msbuild.exe to build managed applications, we recommend that you allow msbuild.exe in your code integrity policies. However, if your reference system is an end-user device that isn't being used in a development context, we recommend that you block msbuild.exe.
<sup>2</sup> If you're using your reference system in a development context and use msbuild.exe to build managed applications, we recommend that you allow msbuild.exe in your code integrity policies. Otherwise, we recommend that you block msbuild.exe.
<sup>*</sup> Microsoft recognizes the efforts of people in the security community who help us protect customers through responsible vulnerability disclosure, and extends thanks to the following people:
@ -99,9 +99,9 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
> [!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 WDAC policy. In addition, when an application version is upgraded to fix a security vulnerability or potential WDAC bypass, you should add *deny* rules to your application control policies for that application’s previous, less secure versions.
Certain software applications may allow other code to run by design. Unless these applications are business critical, you should block them in your WDAC policy. In addition, when an application version is upgraded to fix a security vulnerability or potential WDAC bypass, add *deny* rules to your application control policies for that application’s previous, less secure versions.
Microsoft recommends that you install the latest security updates. For example, updates help resolve several issues in PowerShell modules that allowed an attacker to bypass WDAC. These modules can't be blocked by name or version, and therefore must be blocked by their corresponding hashes.
Microsoft recommends that you install the latest security updates. For example, updates help resolve several issues in PowerShell modules that allowed an attacker to bypass WDAC. These modules can be blocked by their corresponding hashes.
As of October 2017, system.management.automation.dll is updated to revoke earlier versions by hash values, instead of version rules.
@ -111,14 +111,14 @@ If you wish to use this blocklist policy on Windows Server 2016, locate the deny
- msxml6.dll
- jscript9.dll
The blocklist policy below includes "Allow all" rules for both kernel and user mode that make it safe to deploy as a standalone WDAC policy. On Windows versions 1903 and above, Microsoft recommends converting this policy to multiple policy format using the *Set-CiPolicyIdInfo* cmdlet with the *-ResetPolicyId* switch. Then, you can deploy it as a Base policy side-by-side with any other policies in your environment. To instead add these rules to an existing Base policy, you can merge the policy below using the *Merge-CIPolicy* cmdlet. If merging into an existing policy that includes an explicit allowlist, you should first remove the two "Allow all" rules and their corresponding FileRuleRefs from the sample policy below.
The blocklist policy that follows includes "Allow all" rules for both kernel and user mode that make it safe to deploy as a standalone WDAC policy. On Windows versions 1903 and above, Microsoft recommends converting this policy to multiple policy format using the *Set-CiPolicyIdInfo* cmdlet with the *-ResetPolicyId* switch. Then, you can deploy it as a Base policy side-by-side with any other policies in your environment. To instead add these rules to an existing Base policy, you can merge the policy that follows using the *Merge-CIPolicy* cmdlet. If merging into an existing policy that includes an explicit allowlist, you should first remove the two "Allow all" rules and their corresponding FileRuleRefs from the blocklist policy.
**WDAC policy XML**:
```xml
<?xml version="1.0" encoding="utf-8"?>
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
<VersionEx>10.1.0.0</VersionEx>
<VersionEx>10.1.0.1</VersionEx>
<PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>
<PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
<Rules>
@ -159,6 +159,10 @@ The blocklist policy below includes "Allow all" rules for both kernel and user m
<Deny ID="ID_DENY_DOTNET" FriendlyName="dotnet.exe" FileName="dotnet.exe" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
<Deny ID="ID_DENY_FSI" FriendlyName="fsi.exe" FileName="fsi.exe" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
<Deny ID="ID_DENY_FSI_ANYCPU" FriendlyName="fsiAnyCpu.exe" FileName="fsiAnyCpu.exe" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
<Deny ID="ID_DENY_HVCISCAN_AMD_1" FriendlyName="HVCIScan.exe with missing resources AMD Hash Sha1" Hash="424823CD625834C05D55C7B825B0D8059D589748" />
<Deny ID="ID_DENY_HVCISCAN_AMD_2" FriendlyName="HVCIScan.exe with missing resources AMD Hash Sha256" Hash="4968BA3E491CF6471C5D1C6CBECE84294012298D8EB6D32C03E476892F34279C" />
<Deny ID="ID_DENY_HVCISCAN_AMD_3" FriendlyName="HVCIScan.exe with missing resources AMD Hash Page Sha1" Hash="FCFA167F5F1FC88E0886132AB0B2E0C32B4B1BF5" />
<Deny ID="ID_DENY_HVCISCAN_AMD_4" FriendlyName="HVCIScan.exe with missing resources AMD Hash Page Sha256" Hash="283F6E8998E7A20C68FFD8715E6F130EC7648055285883686336F5711DB1C978" />
<Deny ID="ID_DENY_INFINSTALL" FriendlyName="infdefaultinstall.exe" FileName="infdefaultinstall.exe" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
<Deny ID="ID_DENY_INSTALLUTIL" FriendlyName="Microsoft InstallUtil" FileName="InstallUtil.exe" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
<Deny ID="ID_DENY_KD" FriendlyName="kd.exe" FileName="kd.Exe" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
@ -1500,6 +1504,10 @@ The blocklist policy below includes "Allow all" rules for both kernel and user m
<FileRuleRef RuleID="ID_DENY_D_604" />
<FileRuleRef RuleID="ID_DENY_D_605" />
<FileRuleRef RuleID="ID_DENY_D_606" />
<FileRuleRef RuleID="ID_DENY_HVCISCAN_AMD_1" />
<FileRuleRef RuleID="ID_DENY_HVCISCAN_AMD_2" />
<FileRuleRef RuleID="ID_DENY_HVCISCAN_AMD_3" />
<FileRuleRef RuleID="ID_DENY_HVCISCAN_AMD_4" />
</FileRulesRef>
</ProductSigners>
</SigningScenario>

16
windows/security/threat-protection/windows-defender-application-control/operations/known-issues.md
View File

@ -95,3 +95,19 @@ As a workaround, download the MSI file and run it locally:
```console
msiexec –i c:\temp\Windows10_Version_1511_ADMX.msi
```
### Slow boot and performance with custom policies
WDAC will evaluate all running processes, including inbox Windows processes. If policies don't build off the WDAC templates or don't trust the Windows signers, you'll see slower boot times, degraded performance and possibly boot issues. For these reasons, it's strongly recommended to build off the [WDAC base templates](../example-wdac-base-policies.md).
#### AppId Tagging policy considerations
If the AppId Tagging Policy wasn't built off the WDAC base templates or doesn't allow the Windows in-box signers, you'll notice a significant increase in boot times (~2 minutes).
If you can't allowlist the Windows signers, or build off the WDAC base templates, it is strongly recommended to add the following rule to your policies to improve the performance:
:::image type="content" source="../images/known-issue-appid-dll-rule.png" alt-text="Allow all dlls in the policy.":::
:::image type="content" source="../images/known-issue-appid-dll-rule-xml.png" alt-text="Allow all dll files in the xml policy.":::
Since AppId Tagging policies evaluate but can't tag dll files, this rule will short circuit dll evaluation and improve evaluation performance.