mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-28 05:07:23 +00:00
Reorganized and made updates to docs related to policy planning
This commit is contained in:
parent
db19adae21
commit
cff717a54e
@ -1,17 +1,17 @@
|
||||
# [Windows Defender Application Control](windows-defender-application-control.md)
|
||||
|
||||
## [Windows Defender Application Control design guide](windows-defender-application-control-design-guide.md)
|
||||
### [Understand WDAC policy design decisions](understand-windows-defender-application-control-policy-design-decisions.md)
|
||||
### [Plan for WDAC policy management](plan-windows-defender-application-control-management.md)
|
||||
### [Select the types of rules to create](select-types-of-rules-to-create.md)
|
||||
### [Plan for WDAC policy lifecycle management](plan-windows-defender-application-control-management.md)
|
||||
### Design and create your WDAC policy
|
||||
#### [Understand WDAC policy design decisions](understand-windows-defender-application-control-policy-design-decisions.md)
|
||||
#### [Understand WDAC policy rules and file rules](select-types-of-rules-to-create.md)
|
||||
#### [Create an initial default policy](create-initial-default-policy.md)
|
||||
#### [Microsoft recommended block rules](microsoft-recommended-block-rules.md)
|
||||
|
||||
|
||||
|
||||
## [Windows Defender Application Control deployment guide](windows-defender-application-control-deployment-guide.md)
|
||||
### [Types of devices](types-of-devices.md)
|
||||
### Use WDAC with custom policies
|
||||
#### [Create an initial default policy](create-initial-default-policy.md)
|
||||
#### [Microsoft recommended block rules](microsoft-recommended-block-rules.md)
|
||||
### [Audit WDAC policies](audit-windows-defender-application-control-policies.md)
|
||||
### [Merge WDAC policies](merge-windows-defender-application-control-policies.md)
|
||||
### [Deploy multiple WDAC policies](deploy-multiple-windows-defender-application-control-policies.md)
|
||||
|
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Create an initial default policy (Windows 10)
|
||||
title: Create a Windows Defender Application Control policy from a reference computer (Windows 10)
|
||||
description: Windows Defender Application Control restricts which applications users are allowed to run and the code that runs in the system core.
|
||||
keywords: whitelisting, security, malware
|
||||
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
|
||||
@ -32,6 +32,14 @@ For this example, you must initiate variables to be used during the creation pro
|
||||
Then create the WDAC policy by scanning the system for installed applications.
|
||||
The policy file is converted to binary format when it gets created so that Windows can interpret it.
|
||||
|
||||
## Overview of the process of creating Windows Defender Application Control policies
|
||||
|
||||
A common system imaging practice in today’s 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).
|
||||
|
||||
Optionally, WDAC can align with your software catalog as well as any IT department–approved 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 computer’s role or department. Organizations have a choice of how their policies are created, merged or serviced, and managed.
|
||||
|
||||
If you plan to use an internal CA to sign catalog files or WDAC policies, see the steps in [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md).
|
||||
|
||||
> [!NOTE]
|
||||
> Make sure the reference computer is virus and malware-free, and install any software you want to be scanned before creating the WDAC policy.
|
||||
|
||||
|
@ -17,7 +17,7 @@ manager: dansimp
|
||||
ms.date: 02/21/2018
|
||||
---
|
||||
|
||||
# Plan for Windows Defender Application Control policy management
|
||||
# Plan for Windows Defender Application Control lifecycle policy management
|
||||
|
||||
**Applies to:**
|
||||
|
||||
@ -30,13 +30,28 @@ This topic describes the decisions you need to make to establish the processes f
|
||||
|
||||
Before you begin deploying WDAC, consider how your policies will be managed and maintained over time. Developing a process for managing WDAC policies helps assure that WDAC continues to effectively control how applications are allowed to run in your organization.
|
||||
|
||||
<!-- We should insert a diagram to show this visually -->
|
||||
Most WDAC 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.
|
||||
2. Deploy the audit mode policy to intended computers.
|
||||
3. Monitor audit block events from the intended computers and add/edit/delete rules as needed to address unexpected/unwanted blocks.
|
||||
4. Repeat steps 2-3 until the remaining block events meet expectations.
|
||||
5. Generate the enforced mode version of the policy.
|
||||
6. Deploy the enforced mode policy to intended computers. We recommend using staged rollouts for enforced policies to detect and respond to issues before deploying the policy broadly.
|
||||
7. Repeat steps 1-6 anytime the desired "circle-of-trust" changes.
|
||||
|
||||
### 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.
|
||||
|
||||
### Set PolicyName, PolicyID, and Version metadata for each policy
|
||||
|
||||
Use the [Set-CIPolicyIDInfo](https://docs.microsoft.com/powershell/module/configci/set-cipolicyidinfo) cmdlet to give each policy a descriptive name and set a unique ID. This should be done once per policy in order to differentiate them when reviewing WDAC events or when viewing the policy XML document. Although you can specify a string value for PolicyId, we recommend using the -ResetPolicyId switch to let the system auto-generate a unique ID for the policy.
|
||||
Use the [Set-CIPolicyIDInfo](https://docs.microsoft.com/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, we recommend using the -ResetPolicyId switch to let the system auto-generate a unique ID for the policy.
|
||||
|
||||
> [!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.
|
||||
> PolicyID should be set only once per policy and use different PolicyID's for the audit and enforced mode versions of each policy.
|
||||
|
||||
In addition, we recommend using the [Set-CIPolicyVersion](https://docs.microsoft.com/powershell/module/configci/set-cipolicyversion) cmdlet to increment the policy's internal version number when you make changes to the policy. The version must be defined as a standard four-part version string (e.g. "1.0.0.0").
|
||||
|
||||
|
@ -17,43 +17,35 @@ manager: dansimp
|
||||
ms.date: 04/20/2018
|
||||
---
|
||||
|
||||
# Deploy Windows Defender Application Control policy rules and file rules
|
||||
# Understand WDAC policy rules and file rules
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- Windows 10
|
||||
- Windows Server 2016
|
||||
- Windows Server 2016 and above
|
||||
|
||||
Windows Defender Application Control (WDAC) provides control over a computer running Windows 10 by using policies that specify whether a driver or application is trusted and can be run. A policy includes *policy rules* that control options such as audit mode or whether user mode code integrity (UMCI) is enabled in a WDAC policy, and *file rules* (or *file rule levels*) that specify the level at which applications will be identified and trusted.
|
||||
|
||||
## Overview of the process of creating Windows Defender Application Control policies
|
||||
|
||||
A common system imaging practice in today’s 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).
|
||||
|
||||
Optionally, WDAC can align with your software catalog as well as any IT department–approved 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 computer’s role or department. Organizations have a choice of how their policies are created, merged or serviced, and managed.
|
||||
|
||||
If you plan to use an internal CA to sign catalog files or WDAC policies, see the steps in [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md).
|
||||
|
||||
## Windows Defender Application Control policy rules
|
||||
|
||||
To modify the policy rule options of an existing WDAC policy, use [Set-RuleOption](https://docs.microsoft.com/powershell/module/configci/set-ruleoption). Note the following examples of 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 WDAC policy XML, use [Set-RuleOption](https://docs.microsoft.com/powershell/module/configci/set-ruleoption). Note the following examples of 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:
|
||||
|
||||
`Set-RuleOption -FilePath <Path to policy> -Option 0`
|
||||
`Set-RuleOption -FilePath <Path to policy XML> -Option 0`
|
||||
|
||||
Note that a policy that was created without the `-UserPEs` option is empty of user mode executables, that is, applications. If you enable UMCI (Option 0) for such a policy and then attempt to run an application, Windows Defender Application Control will see that the application is not on its list (which is empty of applications), and respond. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application. To create a policy that includes user mode executables (applications), when you run `New-CIPolicy`, include the `-UserPEs` option.
|
||||
|
||||
- To disable UMCI on an existing WDAC policy, delete rule option 0 by running the following command:
|
||||
|
||||
`Set-RuleOption -FilePath <Path to policy> -Option 0 -Delete`
|
||||
`Set-RuleOption -FilePath <Path to policy XML> -Option 0 -Delete`
|
||||
|
||||
You can set several rule options within a WDAC policy. Table 2 describes each rule option.
|
||||
You can set several rule options within a WDAC policy. Table 1 describes each rule option.
|
||||
|
||||
> [!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.
|
||||
|
||||
**Table 2. Windows Defender Application Control policy - policy rule options**
|
||||
**Table 1. Windows Defender Application Control policy - policy rule options**
|
||||
|
||||
| Rule option | Description |
|
||||
|------------ | ----------- |
|
||||
@ -68,7 +60,7 @@ You can set several rule options within a WDAC policy. Table 2 describes each ru
|
||||
| **8 Required:EV Signers** | In addition to being WHQL signed, this rule requires that drivers must have been submitted by a partner that has an Extended Verification (EV) certificate. All future Windows 10 and later drivers will meet this requirement. |
|
||||
| **9 Enabled: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. |
|
||||
| **10 Enabled: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. |
|
||||
| **11 Disabled:Script Enforcement** | This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to Restricted Language Mode. NOTE: This option 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. |
|
||||
| **11 Disabled:Script Enforcement** | This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to [Constrained Language Mode](https://docs.microsoft.com/powershell/module/microsoft.powershell.core/about/about_language_modes). NOTE: This option 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. |
|
||||
| **12 Required:Enforce Store Applications** | If this rule option is enabled, WDAC policies will also apply to Universal Windows applications. |
|
||||
| **13 Enabled:Managed Installer** | Use this option to automatically allow applications installed by a software distribution solution, such as System Center Configuration Manager, that has been defined as a managed installer. |
|
||||
| **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). |
|
||||
@ -82,9 +74,9 @@ You can set several rule options within a WDAC policy. Table 2 describes each ru
|
||||
|
||||
File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as fine-tuned as the hash of each binary or as general as a CA certificate. You specify file rule levels both when you create a new WDAC policy from a scan and when you create a policy from audit events. In addition, to combine rule levels found in multiple policies, you can merge the policies. When merged, WDAC policies combine their file rules, so that any application that would be allowed by either of the original policies will be allowed by the combined policy.
|
||||
|
||||
Each file rule level has its benefit and disadvantage. Use Table 3 to select the appropriate protection level for your available administrative resources and Windows Defender Application Control deployment scenario.
|
||||
Each file rule level has its benefit and disadvantage. Use Table 2 to select the appropriate protection level for your available administrative resources and Windows Defender Application Control deployment scenario.
|
||||
|
||||
Table 3. Windows Defender Application Control policy - file rule levels
|
||||
**Table 2. Windows Defender Application Control policy - file rule levels**
|
||||
|
||||
| Rule level | Description |
|
||||
|----------- | ----------- |
|
||||
|
@ -44,7 +44,15 @@ You should consider using WDAC as part of your organization's application contro
|
||||
|
||||
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.
|
||||
|
||||
The following questions can help you plan your WDAC deployment. They are not in priority or sequential order and are not meant to be an exhaustive set of design considerations.
|
||||
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 (SCCM)), uses the DefaultWindows policy as the basis for its policy but then modifies the policy rules to allow SCCM and its dependencies, sets the managed installer policy rule, and additionally configures SCCM 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 SCCM administrator which adds rules for any apps found in the specified paths on the managed endpoint. This establishes the "circle-of-trust" for SCCM'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.
|
||||
|
||||
## WDAC design considerations
|
||||
|
||||
### How are apps managed and deployed in your organization?
|
||||
|
||||
|
@ -29,7 +29,7 @@ With thousands of new malicious files created every day, using traditional metho
|
||||
|
||||
In most organizations, information is the most valuable asset, and ensuring that only approved users have access to that information is imperative. However, when a user runs a process, that process has the same level of access to data that the user has. As a result, sensitive information could easily be deleted or transmitted out of the organization if a user knowingly or unknowingly runs malicious software.
|
||||
|
||||
Application control can help mitigate these types of security threats by restricting the applications that users are allowed to run and the code that runs in the System Core (kernel). Application control policies can also block unsigned scripts and MSIs, and restrict Windows PowerShell to run in [Constrained Language Mode](https://docs.microsoft.com/powershell/module/microsoft.powershell.core/about/about_language_modes?view=powershell-5.1).
|
||||
Application control can help mitigate these types of security threats by restricting the applications that users are allowed to run and the code that runs in the System Core (kernel). Application control policies can also block unsigned scripts and MSIs, and restrict Windows PowerShell to run in [Constrained Language Mode](https://docs.microsoft.com/powershell/module/microsoft.powershell.core/about/about_language_modes).
|
||||
|
||||
Application control is a crucial line of defense for protecting enterprises given today’s threat landscape, and it has an inherent advantage over traditional antivirus solutions. Specifically, application control moves away from an application trust model where all applications are assumed trustworthy to one where applications must earn trust in order to run. Many organizations, like the Australian Signals Directorate, understand this and frequently cite application control as one of the most effective means for addressing the threat of executable file-based malware (.exe, .dll, etc.).
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user