deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-07 10:07:21 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge branch 'master' into repo_sync_working_branch

Browse Source
This commit is contained in:
Jeff Borsecnik 2021-06-01 09:02:24 -07:00 committed by GitHub
commit 647483d57a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 19 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
windows/security/threat-protection/windows-defender-application-control/audit-and-enforce-windows-defender-application-control-policies.md
View File

@ -12,7 +12,6 @@ audience: ITPro
ms.collection: M365-security-compliance
author: jsuther1974
ms.reviewer: jogeurte
ms.reviewer: v-kikl
ms.author: dansimp
manager: dansimp
ms.date: 05/03/2021

2
windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-script.md
View File

@ -54,7 +54,7 @@ This topic describes how to deploy Windows Defender Application Control (WDAC) p
### Deploying signed policies
In addition to the steps outlined above, the binary policy file must also be copied to the device's EFI partition. Deploying your policy via [MEM](deploy-windows-defender-application-control-policies-using-intune.md) or the [Application Control CSP](#Deploying-multiple-policies-via-ApplicationControl-CSP) will handle this step automatically.
In addition to the steps outlined above, the binary policy file must also be copied to the device's EFI partition. Deploying your policy via [MEM](/windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune) or the Application Control CSP will handle this step automatically.
1. Mount the EFI volume and make the directory, if it does not exist, in an elevated PowerShell prompt:
```powershell

14
windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md
View File

@ -35,17 +35,17 @@ A Windows Defender Application Control (WDAC) policy logs events locally in Wind
| 3089 | Signing information event correlated with either a 3076 or 3077 event. One 3089 event is generated for each signature of a file. Contains the total number of signatures on a file and an index as to which signature it is. Unsigned files will generate a single 3089 event with TotalSignatureCount 0. Correlated in the "System" portion of the event data under "Correlation ActivityID". |
| 3099 | Indicates that a policy has been loaded |
## Microsoft Windows Applocker MSI and Script log event IDs
## Microsoft Windows AppLocker MSI and Script log event IDs
| Event ID | Explanation |
|---|----------|
| 8028 | Audit script/MSI file generated by Windows LockDown Policy (WLDP) being called by the scripthosts themselves. Note: there is no WDAC enforcement on 3rd party scripthosts. |
| 8028 | Audit script/MSI file generated by Windows LockDown Policy (WLDP) being called by the script hosts themselves. Note: there is no WDAC enforcement on third-party script hosts. |
| 8029 | Block script/MSI file |
| 8038 | Signing information event correlated with either a 8028 or 8029 event. One 8038 event is generated for each signature of a script file. Contains the total number of signatures on a script file and an index as to which signature it is. Unsigned script files will generate a single 8038 event with TotalSignatureCount 0. Correlated in the "System" portion of the event data under "Correlation ActivityID". | |
| 8038 | Signing information event correlated with either an 8028 or 8029 event. One 8038 event is generated for each signature of a script file. Contains the total number of signatures on a script file and an index as to which signature it is. Unsigned script files will generate a single 8038 event with TotalSignatureCount 0. Correlated in the "System" portion of the event data under "Correlation ActivityID". | |
## Optional Intelligent Security Graph (ISG) or Managed Installer (MI) diagnostic events
If either the ISG or MI is enabled in a WDAC policy, you can optionally choose to enable 3090, 3091, and 3092 events to provide additional diagnostic information.
If either the ISG or MI is enabled in a WDAC policy, you can optionally choose to enable 3090, 3091, and 3092 events to provide more diagnostic information.
| Event ID | Explanation |
|---|----------|
@ -53,11 +53,11 @@ If either the ISG or MI is enabled in a WDAC policy, you can optionally choose t
| 3091 | Audit executable/dll file |
| 3092 | Block executable/dll file |
3090, 3091, and 3092 events are generated based on the status code of whether a binary passed the policy, regardless of what reputation it was given or whether it was allowed by a designated MI. The SmartLocker template which appears in the event should indicate why the binary passed/failed. Only one event is generated per binary pass/fail. If both ISG and MI are disabled, 3090, 3091, and 3092 events will not be generated.
3090, 3091, and 3092 events are generated based on the status code of whether a binary passed the policy, regardless of what reputation it was given or whether it was allowed by a designated MI. The SmartLocker template that appears in the event should indicate why the binary passed/failed. Only one event is generated per binary pass/fail. If both ISG and MI are disabled, 3090, 3091, and 3092 events will not be generated.
### SmartLocker template
Below are the fields which help to diagnose what a 3090, 3091, or 3092 event indicates.
Below are the fields that help to diagnose what a 3090, 3091, or 3092 event indicates.
| Name | Explanation |
|---|----------|
@ -76,7 +76,7 @@ In order to enable 3091 audit events and 3092 block events, you must create a Te
reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x100
```
In order to enable 3090 allow events as well as 3091 and 3092 events, you must instead create a TestFlags regkey with a value of 0x300. You can do so using the following PowerShell command:
To enable 3090 allow events, and 3091 and 3092 events, you must instead create a TestFlags regkey with a value of 0x300. You can do so using the following PowerShell command:
```powershell
reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x300

3
windows/security/threat-protection/windows-defender-application-control/event-tag-explanations.md
View File

@ -95,6 +95,7 @@ Represents why verification failed, or if it succeeded.
## Microsoft Root CAs trusted by Windows
The rule means trust anything signed by a certificate that chains to this root CA.
| Root ID | Root Name |
|---|----------|
| 0| None |
@ -118,4 +119,4 @@ The rule means trust anything signed by a certificate that chains to this root C
| 18 | Microsoft ECC Product Root CA 2018 |
| 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 don’t 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 WDAC. For example, they don’t need to be listed as TBS hashes in the policy file.

18
windows/security/threat-protection/windows-defender-application-control/understand-windows-defender-application-control-policy-design-decisions.md
View File

@ -40,13 +40,13 @@ You should consider using WDAC as part of your organization's application contro
## 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. While this opens up many new use cases for organizations, 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, 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.
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.
For example, the DefaultWindows policy, which can be found under %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies, establishes a "circle-of-trust" that allows Windows, 3rd-party hardware and software kernel drivers, and applications from the Microsoft Store.
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.
@ -54,31 +54,31 @@ The following questions can help you plan your WDAC deployment and determine the
### 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 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.
| 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. |
| Some apps are centrally managed and deployed, but teams can install additional 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 leverage 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 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. |
| 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 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.|
### Are internally-developed line-of-business (LOB) apps and apps developed by 3rd parties digitally signed?
### Are internally developed line-of-business (LOB) apps and apps developed by third-party companies digitally signed?
Traditional Win32 apps on Windows can run without being digitally signed. This practice can expose Windows devices to malicious or tampered code and presents a security vulnerability to your Windows devices. Adopting code-signing as part of your organization's app development practices or augmenting apps with signed catalog files as part of your app ingestion and distribution can greatly improve the integrity and security of apps used.
| 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). |
| Apps used in your organization do not need to meet any codesigning requirements. | Organizations can [use built-in Windows 10 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 10 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?
Most business teams or departments have specific security requirements that pertain to data access and the applications used to access that data. You should consider the scope of the project for each group and the group’s priorities before you deploy application control policies for the entire organization. There is overhead in managing policies which may lead you to choose between broad, organization-wide policies and multiple team-specific policies.
Most business teams or departments have specific security requirements that pertain to data access and the applications used to access that data. Consider the scope of the project for each group and the group’s priorities before you deploy application control policies for the entire organization. There is overhead in managing policies that might lead you to choose between broad, organization-wide policies and multiple team-specific policies.
| Possible answers | Design considerations |
| - | - |
| Yes | WDAC policies can be created unique per team, or team-specific supplemental policies can be used to expand what is allowed by a common, centrally-defined base policy.|
| Yes | WDAC policies can be created unique per team, or team-specific supplemental policies can be used to expand what is allowed by a common, centrally defined base policy.|
| No | WDAC policies can be applied globally to applications that are installed on PCs running Windows 10. Depending on the number of apps you need to control, managing all the rules and exceptions might be challenging.|
### Does your IT department have resources to analyze application usage, and to design and manage the policies?
@ -87,7 +87,7 @@ The time and resources that are available to you to perform the research and ana
| Possible answers | Design considerations |
| - | - |
| Yes | Invest the time to analyze your organization's application control requirements, and plan a complete deployment that uses rules that are as simply constructed as possible.|
| Yes | Invest the time to analyze your organization's application control requirements, and plan a complete deployment that uses rules that are constructed as simply as possible.|
| No | Consider a focused and phased deployment for specific groups by using a small number of rules. As you apply controls to applications in a specific group, learn from that deployment to plan your next deployment. Alternatively, you can create a policy with a broad trust profile to authorize as many apps as possible. |
### Does your organization have Help Desk support?