Merge pull request #1531 from MicrosoftDocs/master

Publish 11/08/2019 3:31 PM PST
This commit is contained in:
Thomas Raya 2019-11-08 15:48:32 -08:00 committed by GitHub
commit 779638de41
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
17 changed files with 249 additions and 843 deletions

View File

@ -241,6 +241,21 @@
"redirect_document_id": true
},
{
"source_path": "windows/security/threat-protection/windows-defender-application-control/create-your-windows-defender-application-control-planning-document.md",
"redirect_url": "https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/plan-windows-defender-application-control-management",
"redirect_document_id": true
},
{
"source_path": "windows/security/threat-protection/windows-defender-application-control/document-your-windows-defender-application-control-management-processes.md",
"redirect_url": "https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/plan-windows-defender-application-control-management",
"redirect_document_id": false
},
{
"source_path": "windows/security/threat-protection/windows-defender-application-control/windows-defender-device-guard-and-applocker.md",
"redirect_url": "https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control",
"redirect_document_id": false
},
{
"source_path": "windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-if-server-agrees.md",
"redirect_url": "https://docs.microsoft.com/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees",
"redirect_document_id": true
@ -256,6 +271,11 @@
"redirect_document_id": true
},
{
"source_path": "windows/security/threat-protection/windows-defender-application-control/create-path-based-rules.md",
"redirect_url": "https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create",
"redirect_document_id": false
},
{
"source_path": "windows/security/threat-protection/applocker/administer-applocker-using-mdm.md",
"redirect_url": "https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/applocker/administer-applocker-using-mdm",
"redirect_document_id": true
@ -15337,11 +15357,6 @@
"redirect_document_id": false
},
{
"source_path": "windows/security/threat-protection/windows-defender-application-control/create-path-based-rules.md",
"redirect_url": "https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create",
"redirect_document_id": false
},
{
"source_path": "windows/security/threat-protection/windows-defender-antivirus/microsoft-defender-atp-mac.md",
"redirect_url": "https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/microsoft-defender-atp-mac",
"redirect_document_id": true

View File

@ -48,6 +48,14 @@ The HoloLens box contains the following items:
>[!TIP]
>The [clicker](hololens1-clicker.md) ships with HoloLens (1st Gen), in a separate box.
### Power Supply details
The power supply and the USB cable that come with the device are the best supported mechanism for charging. The power supply is an 18W charger. It supplies 9V at 2A.
Charging rate and speed may vary depending on the environment in which the device is running.
In order to maintain/advance Internal Battery Charge Percentage while the device is on, it must be connected minimum to a 15W charger.
## Device specifications
### Display

View File

@ -7,7 +7,7 @@ author: JesseMcCulloch
ms.author: jemccull
ms.topic: article
ms.localizationpriority: high
ms.date: 8/12/19
ms.date: 8/12/2019
ms.reviewer:
manager: jarrettr
appliesto:
@ -29,6 +29,10 @@ When your HoloLens is on, the battery indicator shows the battery level in incre
> [!TIP]
> To get an estimate of your current battery level, say "Hey Cortana, how much battery do I have left?"
The power supply and USB cable that come with the device are the best way to charge your HoloLens (1st gen). The power supply provides 18W of power (9V 2A).
Charging rate and speed may vary depending on the environment in which the device is running.
## Adjust fit
> [!VIDEO https://www.microsoft.com/videoplayer/embed/be3cb527-f2f1-4f85-b4f7-a34fbaba980d]

View File

@ -35,6 +35,14 @@ Microsoft HoloLens 2 is an untethered holographic computer. It refines the holo
- **Power supply**. Plugs into a power outlet.
- **Microfiber cloth**. Use to clean your HoloLens visor.
### Power Supply details
The power supply and the USB cable that come with the device are the best supported mechanism for charging. The power supply is an 18W charger. It's supplies 9V at 2A.
Charging rate and speed may vary depending on the environment in which the device is running.
In order to maintain/advance Internal Battery Charge Percentage while the device is on, it must be connected minimum to a 15W charger.
## Device specifications
### Display
@ -83,6 +91,7 @@ Microsoft HoloLens 2 is an untethered holographic computer. It refines the holo
| Battery technology | [Lithium batteries](https://www.microsoft.com/download/details.aspx?id=43388) |
| Charging behavior | Fully functional when charging |
| Cooling type | Passively cooled (no fans) |
| Power draw | In order to maintain/advance Internal Battery Charge Percentage while the device is on, it must be connected minimum to a 15W charger. |
### Fit

View File

@ -21,7 +21,9 @@ The procedures below will help you set up a HoloLens 2 for the first time.
## Charge your HoloLens
Connect the power supply to the charging port by using the USB-C cable (included). Plug the power supply into a power outlet.
Connect the power supply to the charging port by using the USB-C cable (included). Plug the power supply into a power outlet. The power supply and USB-C-to-C cable that come with the device are the best way to charge your HoloLens 2. The charger supplies 18W of power (9V at 2A).
Charging rate and speed may vary depending on the environment in which the device is running.
- When the device is charging, the battery indicator lights up to indicate the current level of charge. The last light will fade in and out to indicate active charging.
- When your HoloLens is on, the battery indicator displays the battery level in increments.

View File

@ -24,15 +24,17 @@ Microsoft Safety Scanner is a scan tool designed to find and remove malware from
- [Download Microsoft Safety Scanner (64-bit)](https://go.microsoft.com/fwlink/?LinkId=212732)
> [!NOTE]
> The security intelligence update version of the Microsoft Safety Scanner matches the version described [in this web page](https://www.microsoft.com/wdsi/definitions).
> Starting November 2019, Safety Scanner will be SHA-2 signed exclusively. Your devices must be updated to support SHA-2 in order to run Safety Scanner. To learn more, see [2019 SHA-2 Code Signing Support requirement for Windows and WSUS](https://support.microsoft.com/help/4472027/2019-sha-2-code-signing-support-requirement-for-windows-and-wsus).
Safety Scanner only scans when manually triggered and is available for use 10 days after being downloaded. We recommend that you always download the latest version of this tool before each scan.
## Important information
> [!NOTE]
> This tool does not replace your antimalware product. For real-time protection with automatic updates, use [Windows Defender Antivirus on Windows 10 and Windows 8](https://www.microsoft.com/windows/comprehensive-security) or [Microsoft Security Essentials on Windows 7](https://support.microsoft.com/help/14210/security-essentials-download). These antimalware products also provide powerful malware removal capabilities. If you are having difficulties removing malware with these products, you can refer to our help on [removing difficult threats](https://www.microsoft.com/wdsi/help/troubleshooting-infection).
- The security intelligence update version of the Microsoft Safety Scanner matches the version described [in this web page](https://www.microsoft.com/wdsi/definitions).
> [!NOTE]
> Safety scanner is a portable executable and does not appear in the Windows Start menu or as an icon on the desktop. Note where you saved this download.
- Safety Scanner only scans when manually triggered and is available for use 10 days after being downloaded. We recommend that you always download the latest version of this tool before each scan.
- Safety scanner is a portable executable and does not appear in the Windows Start menu or as an icon on the desktop. Note where you saved this download.
- This tool does not replace your antimalware product. For real-time protection with automatic updates, use [Windows Defender Antivirus on Windows 10 and Windows 8](https://www.microsoft.com/windows/comprehensive-security) or [Microsoft Security Essentials on Windows 7](https://support.microsoft.com/help/14210/security-essentials-download). These antimalware products also provide powerful malware removal capabilities. If you are having difficulties removing malware with these products, you can refer to our help on [removing difficult threats](https://www.microsoft.com/wdsi/help/troubleshooting-infection).
## System requirements

View File

@ -1,19 +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)
### [Select the types of rules to create](select-types-of-rules-to-create.md)
### [Plan for WDAC policy management](plan-windows-defender-application-control-management.md)
#### [Document your application control management processes](document-your-windows-defender-application-control-management-processes.md)
### [Create your WDAC planning document](create-your-windows-defender-application-control-planning-document.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)
@ -34,10 +32,10 @@
### [Use signed policies to protect Windows Defender Application Control against tampering](use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md)
#### [Signing WDAC policies with SignTool.exe](signing-policies-with-signtool.md)
### [Disable WDAC policies](disable-windows-defender-application-control-policies.md)
### [Device Guard and AppLocker](windows-defender-device-guard-and-applocker.md)
### [LOB Win32 Apps on S Mode](LOB-win32-apps-on-s.md)
## [AppLocker](applocker\applocker-overview.md)
### [Administer AppLocker](applocker\administer-applocker.md)
#### [Maintain AppLocker policies](applocker\maintain-applocker-policies.md)

View File

@ -80,12 +80,6 @@ The following are examples of scenarios in which AppLocker can be used:
AppLocker can help you protect the digital assets within your organization, reduce the threat of malicious software being introduced into your environment, and improve the management of application control and the maintenance of application control policies.
## System requirements
AppLocker policies can only be configured on and applied to computers that are running on the supported versions and editions of the Windows operating system. Group Policy is required to distribute Group Policy Objects that contain AppLocker policies. For more info, see [Requirements to Use AppLocker](requirements-to-use-applocker.md).
AppLocker rules can be created on domain controllers.
## Installing AppLocker
AppLocker is included with enterprise-level editions of Windows. You can author AppLocker rules for a single computer or for a group of computers. For a single computer, you can author the rules by using the Local Security Policy editor (secpol.msc). For a group of computers, you can author the rules within a Group Policy Object by using the Group Policy Management Console (GPMC).

View File

@ -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 todays IT organization is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone additional company assets. WDAC policies follow a similar methodology, that begins with the establishment of a golden computer. As with imaging, you can have multiple golden computers based on model, department, application set, and so on. Although the thought process around the creation of WDAC policies is similar to imaging, these policies should be maintained independently. Assess the necessity of additional WDAC policies based on what should be allowed to be installed and run and for whom. For more details on doing this assessment, see the [WDAC Design Guide](windows-defender-application-control-design-guide.md).
Optionally, WDAC can align with your software catalog as well as any IT departmentapproved applications. One straightforward method to implement WDAC is to use existing images to create one master WDAC policy. You do so by creating a WDAC policy from each image, and then by merging the policies. This way, what is installed on all of those images will be allowed to run, if the applications are installed on a computer based on a different image. Alternatively, you may choose to create a base applications policy and add policies based on the computers role or department. Organizations have a choice of how their policies are created, merged or serviced, and managed.
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.

View File

@ -1,382 +0,0 @@
---
title: Create your Windows Defender Application Control (WDAC) planning document (Windows 10)
description: This planning topic for the IT professional summarizes the information you need to research and include in your WDAC planning document.
keywords: whitelisting, security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
ms.collection: M365-security-compliance
author: jsuther1974
ms.reviewer: isbrahm
ms.author: dansimp
manager: dansimp
ms.date: 09/21/2017
---
# Create your Windows Defender Application Control (WDAC) planning document
**Applies to**
- Windows 10
- Windows Server
This planning topic for the IT professional summarizes the information you need to research and include in your WDAC planning document.
## The WDAC deployment design
The design process and the planning document help you investigate application usage in your organization and record your findings so you can effectively deploy and maintain application control policies by using WDAC.
You should have completed these steps in the design and planning process:
1. [Select types of rules to create](select-types-of-rules-to-create.md)
2. [Plan for WDAC policy management](document-your-windows-defender-application-control-management-processes.md)
### WDAC planning document contents
Your planning document should contain:
- A list of business groups that will participate in the application control policy project, their requirements, a description of their business processes, and contact information.
- Application control policy project target dates, both for planning and deployment.
- A complete list of apps used by each business group (or organizational unit), including version information and installation paths.
- What condition to apply to rules governing each application (or whether to use the default set provided by WDAC).
- A strategy for using Group Policy to deploy the WDAC policies.
- A strategy in processing the application usage events generated by WDAC.
- A strategy to maintain and manage WDAC polices after deployment.
### Sample template for an WDAC planning document
You can use the following form to construct your own WDAC planning document.
**Business group**:
**Operating system environment**: (Windows and non-Windows)
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><strong>Contacts</strong></p></td>
<td align="left"><p>Business contact:</p></td>
<td align="left"><p>Technical contact:</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Other departments</strong></p></td>
<td align="left"><p>In this business group:</p></td>
<td align="left"><p>Affected by this project:</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Security policies</strong></p></td>
<td align="left"><p>Internal:</p></td>
<td align="left"><p>Regulatory/compliance:</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Business goals</strong></p></td>
<td align="left"><p>Primary:</p></td>
<td align="left"><p>Secondary:</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Project target dates</strong></p></td>
<td align="left"><p>Design signoff date:</p></td>
<td align="left"><p>Policy deployment date:</p></td>
</tr>
</tbody>
</table>
<strong>Rules</strong>
<table style="width:100%;">
<colgroup>
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Business group</th>
<th align="left">Organizational unit</th>
<th align="left">Implement WDAC?</th>
<th align="left">Apps</th>
<th align="left">Installation path</th>
<th align="left">Use default rule or define new rule condition</th>
<th align="left">Allow or deny</th>
<th align="left">GPO name</th>
<th align="left">Support policy</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p> </p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
</tr>
</tbody>
</table>
<strong>Event processing</strong>
<table>
<colgroup>
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Business group</th>
<th align="left">WDAC event collection location</th>
<th align="left">Archival policy</th>
<th align="left">Analyzed?</th>
<th align="left">Security policy</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p> </p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
</tr>
</tbody>
</table>
<strong>Policy maintenance</strong>
<table>
<colgroup>
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Business group</th>
<th align="left">Rule update policy</th>
<th align="left">App decommission policy</th>
<th align="left">App version policy</th>
<th align="left">App deployment policy</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p> </p></td>
<td align="left"><p>Planned:</p>
<p>Emergency:</p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
</tr>
</tbody>
</table>
### Example of a WDAC planning document
**Rules**
<table style="width:100%;">
<colgroup>
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Business group</th>
<th align="left">Organizational unit</th>
<th align="left">Implement WDAC?</th>
<th align="left">Applications</th>
<th align="left">Installation path</th>
<th align="left">Use default rule or define new rule condition</th>
<th align="left">Allow or deny</th>
<th align="left">GPO name</th>
<th align="left">Support policy</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Bank Tellers</p></td>
<td align="left"><p>Teller-East and Teller-West</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Teller Software</p></td>
<td align="left"><p>C:\Program Files\Woodgrove\Teller.exe</p></td>
<td align="left"><p>File is signed; create a publisher condition</p></td>
<td align="left"><p>Allow</p></td>
<td align="left"><p>Tellers-WDACTellerRules</p></td>
<td align="left"><p>Web help</p></td>
</tr>
<tr class="even">
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>Windows files</p>
<p></p></td>
<td align="left"><p>C:\Windows</p></td>
<td align="left"><p>Create a path exception to the default rule to exclude \Windows\Temp</p></td>
<td align="left"><p>Allow</p></td>
<td align="left"><p></p></td>
<td align="left"><p>Help desk</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Human Resources</p></td>
<td align="left"><p>HR-All</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Check Payout</p></td>
<td align="left"><p>C:\Program Files\Woodgrove\HR\Checkcut.exe</p></td>
<td align="left"><p>File is signed; create a publisher condition</p></td>
<td align="left"><p>Allow</p></td>
<td align="left"><p>HR-WDACHRRules</p></td>
<td align="left"><p>Web help</p></td>
</tr>
<tr class="even">
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>Time Sheet Organizer</p></td>
<td align="left"><p>C:\Program Files\Woodgrove\HR\Timesheet.exe</p></td>
<td align="left"><p>File is not signed; create a file hash condition</p></td>
<td align="left"><p>Allow</p></td>
<td align="left"><p></p></td>
<td align="left"><p>Web help</p></td>
</tr>
<tr class="odd">
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>Internet Explorer 7</p></td>
<td align="left"><p>C:\Program Files\Internet Explorer&lt;/p&gt;</td>
<td align="left"><p>File is signed; create a publisher condition</p></td>
<td align="left"><p>Deny</p></td>
<td align="left"><p></p></td>
<td align="left"><p>Web help</p>
<p></p></td>
</tr>
<tr class="even">
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>Windows files</p></td>
<td align="left"><p>C:\Windows</p></td>
<td align="left"><p>Use the default rule for the Windows path</p></td>
<td align="left"><p>Allow</p></td>
<td align="left"><p></p></td>
<td align="left"><p>Help desk</p></td>
</tr>
</tbody>
</table>
<strong>Event processing</strong>
<table>
<colgroup>
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Business group</th>
<th align="left">WDAC event collection location</th>
<th align="left">Archival policy</th>
<th align="left">Analyzed?</th>
<th align="left">Security policy</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Bank Tellers</p></td>
<td align="left"><p>Forwarded to: WDAC Event Repository on srvBT093</p></td>
<td align="left"><p>Standard</p></td>
<td align="left"><p>None</p></td>
<td align="left"><p>Standard</p></td>
</tr>
<tr class="even">
<td align="left"><p>Human Resources</p></td>
<td align="left"><p>DO NOT FORWARD. srvHR004</p></td>
<td align="left"><p>60 months</p></td>
<td align="left"><p>Yes, summary reports monthly to managers</p></td>
<td align="left"><p>Standard</p></td>
</tr>
</tbody>
</table>
<strong>Policy maintenance</strong>
<table>
<colgroup>
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Business group</th>
<th align="left">Rule update policy</th>
<th align="left">App decommission policy</th>
<th align="left">App version policy</th>
<th align="left">App deployment policy</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Bank Tellers</p></td>
<td align="left"><p>Planned: Monthly through business office triage</p>
<p>Emergency: Request through help desk</p></td>
<td align="left"><p>Through business office triage</p>
<p>30-day notice required</p></td>
<td align="left"><p>General policy: Keep past versions for 12 months</p>
<p>List policies for each application</p></td>
<td align="left"><p>Coordinated through business office</p>
<p>30-day notice required</p></td>
</tr>
<tr class="even">
<td align="left"><p>Human Resources</p></td>
<td align="left"><p>Planned: Monthly through HR triage</p>
<p>Emergency: Request through help desk</p></td>
<td align="left"><p>Through HR triage</p>
<p>30-day notice required</p></td>
<td align="left"><p>General policy: Keep past versions for 60 months</p>
<p>List policies for each application</p></td>
<td align="left"><p>Coordinated through HR</p>
<p>30-day notice required</p></td>
</tr>
</tbody>
</table>
### Additional resources
- [Windows Defender Application Control](windows-defender-application-control.md)

View File

@ -1,240 +0,0 @@
---
title: Document your application control management processes (Windows 10)
description: This planning topic describes the WDAC policy maintenance information to record for your design document.
keywords: whitelisting, security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
ms.collection: M365-security-compliance
author: jsuther1974
ms.reviewer: isbrahm
ms.author: dansimp
manager: dansimp
ms.topic: conceptual
ms.date: 09/21/2017
---
# Document your application control management processes
**Applies to**
- Windows 10
- Windows Server
This planning topic describes the Windows Defender Application Control (WDAC) policy maintenance information to record for your design document.
## Record your findings
To complete this planning document, you should first complete the following steps:
3. [Select the types of rules to create](select-types-of-rules-to-create.md)
4. [Plan for WDAC policy management](plan-windows-defender-application-control-management.md)
The three key areas to determine for WDAC policy management are:
1. Support policy
Document the process that you will use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel know recommended troubleshooting steps and escalation points for your policy.
2. Event processing
Document whether events will be collected in a central location, how that store will be archived, and whether the events will be processed for analysis.
3. Policy maintenance
Detail how rules will be added to the policy, in which Group Policy Object (GPO) the rules should be defined, and how to modify rules when apps are retired, updated, or added.
The following table contains the added sample data that was collected when determining how to maintain and manage WDAC policies.
<table style="width:100%;">
<colgroup>
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
<col width="11%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Business group</th>
<th align="left">Organizational unit</th>
<th align="left">Implement WDAC?</th>
<th align="left">Apps</th>
<th align="left">Installation path</th>
<th align="left">Use default rule or define new rule condition</th>
<th align="left">Allow or deny</th>
<th align="left">GPO name</th>
<th align="left">Support policy</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Bank Tellers</p></td>
<td align="left"><p>Teller-East and Teller-West</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Teller Software</p></td>
<td align="left"><p>C:\Program Files\Woodgrove\Teller.exe</p></td>
<td align="left"><p>File is signed; create a publisher condition</p></td>
<td align="left"><p>Allow</p></td>
<td align="left"><p>Tellers-WDACTellerRules</p></td>
<td align="left"><p>Web help</p></td>
</tr>
<tr class="even">
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>Windows files</p>
<p></p></td>
<td align="left"><p>C:\Windows</p></td>
<td align="left"><p>Create a path exception to the default rule to exclude \Windows\Temp</p></td>
<td align="left"><p>Allow</p></td>
<td align="left"><p></p></td>
<td align="left"><p>Help desk</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Human Resources</p></td>
<td align="left"><p>HR-All</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Check Payout</p></td>
<td align="left"><p>C:\Program Files\Woodgrove\HR\Checkcut.exe</p></td>
<td align="left"><p>File is signed; create a publisher condition</p></td>
<td align="left"><p>Allow</p></td>
<td align="left"><p>HR-WDACHRRules</p></td>
<td align="left"><p>Web help</p></td>
</tr>
<tr class="even">
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>Time Sheet Organizer</p></td>
<td align="left"><p>C:\Program Files\Woodgrove\HR\Timesheet.exe</p></td>
<td align="left"><p>File is not signed; create a file hash condition</p></td>
<td align="left"><p>Allow</p></td>
<td align="left"><p></p></td>
<td align="left"><p>Web help</p></td>
</tr>
<tr class="odd">
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>Internet Explorer 7</p></td>
<td align="left"><p>C:\Program Files\Internet Explorer&lt;/p&gt;</td>
<td align="left"><p>File is signed; create a publisher condition</p></td>
<td align="left"><p>Deny</p></td>
<td align="left"><p></p></td>
<td align="left"><p>Web help</p>
<p></p></td>
</tr>
<tr class="even">
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>Windows files</p></td>
<td align="left"><p>C:\Windows</p></td>
<td align="left"><p>Use the default rule for the Windows path</p></td>
<td align="left"><p>Allow</p></td>
<td align="left"><p></p></td>
<td align="left"><p>Help desk</p></td>
</tr>
</tbody>
</table>
The following two tables illustrate examples of documenting considerations to maintain and manage WDAC policies.
**Event processing policy**
One discovery method for app usage is to use Audit mode. This will write events to the CodeIntegrity log, which can be managed and analyzed like other Windows logs.
The following table is an example of what to consider and record.
<table>
<colgroup>
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Business group</th>
<th align="left">WDAC event collection location</th>
<th align="left">Archival policy</th>
<th align="left">Analyzed?</th>
<th align="left">Security policy</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Bank Tellers</p></td>
<td align="left"><p>Forwarded to: CodeIntegrity Event Repository on srvBT093</p></td>
<td align="left"><p>Standard</p></td>
<td align="left"><p>None</p></td>
<td align="left"><p>Standard</p></td>
</tr>
<tr class="even">
<td align="left"><p>Human Resources</p></td>
<td align="left"><p>DO NOT FORWARD. srvHR004</p></td>
<td align="left"><p>60 months</p></td>
<td align="left"><p>Yes, summary reports monthly to managers</p></td>
<td align="left"><p>Standard</p></td>
</tr>
</tbody>
</table>
<strong>Policy maintenance policy</strong>
When applications are identified and policies are created for application control, then you can begin documenting how you intend to update those policies.
The following table is an example of what to consider and record.
<table>
<colgroup>
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Business group</th>
<th align="left">Rule update policy</th>
<th align="left">Application decommission policy</th>
<th align="left">Application version policy</th>
<th align="left">Application deployment policy</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Bank Tellers</p></td>
<td align="left"><p>Planned: Monthly through business office triage</p>
<p>Emergency: Request through help desk</p></td>
<td align="left"><p>Through business office triage</p>
<p>30-day notice required</p></td>
<td align="left"><p>General policy: Keep past versions for 12 months</p>
<p>List policies for each application</p></td>
<td align="left"><p>Coordinated through business office</p>
<p>30-day notice required</p></td>
</tr>
<tr class="even">
<td align="left"><p>Human Resources</p></td>
<td align="left"><p>Planned: Monthly through HR triage</p>
<p>Emergency: Request through help desk</p></td>
<td align="left"><p>Through HR triage</p>
<p>30-day notice required</p></td>
<td align="left"><p>General policy: Keep past versions for 60 months</p>
<p>List policies for each application</p></td>
<td align="left"><p>Coordinated through HR</p>
<p>30-day notice required</p></td>
</tr>
</tbody>
</table>
## Next steps
After you determine your application control management strategy for each business group, [create your WDAC planning document](create-your-windows-defender-application-control-planning-document.md).

View File

@ -17,20 +17,57 @@ 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:**
- Windows 10
- Windows Server 2016
- Windows Server 2016 and above
This topic for describes the decisions you need to make to establish the processes for managing and maintaining Windows Defender Application Control (WDAC) policies.
This topic describes the decisions you need to make to establish the processes for managing and maintaining Windows Defender Application Control (WDAC) policies.
## Policy management
## Policy XML lifecycle management
Before you begin the deployment process, consider how the WDAC rules will be managed. Developing a process for managing WDAC rules helps assure that WDAC continues to effectively control how applications are allowed to run in your organization.
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.
### Application and user support policy
<!-- 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 in order to differentiate each policy when reviewing WDAC events or when viewing the policy XML document. Although you can specify a string value for PolicyId, for policies using the multiple policy format we recommend using the -ResetPolicyId switch to let the system 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. Running -ResetPolicyId on a policy created for pre-1903 computers will convert it to multiple policy format and prevent it from running on those earlier versions of Windows 10.
> PolicyID 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").
### Policy rule updates
As new apps are deployed or existing apps are updated by the software publisher, you may need to make revisions to your rules to ensure that these apps run correctly. Whether policy rule updates are required will depend significantly on the types of rules your policy includes. Rules based on codesigning certificates provide the most resiliency against app changes while rules based on file attributes or hash are most likely to require updates when apps change. Alternatively, if you leverage WDAC [managed installer](use-windows-defender-application-control-with-managed-installer.md) functionality and consistently deploy all apps and their updates through your managed installer, then you are less likely to need policy updates.
## WDAC event management
Each time that a process is blocked by WDAC, events will be written to either the CodeIntegrity\Operational or the AppLocker\MSI and Script Windows event logs. The event details which file tried to run, the attributes of that file and its signatures, and the process that attempted to run the blocked file.
Collecting these events in a central location can help you maintain your WDAC policy and troubleshoot rule configuration problems. Event collection technologies such as those available in Windows allow administrators to subscribe to specific event channels and have the events from source computers aggregated into a forwarded event log on a Windows Server operating system collector. For more info about setting up an event subscription, see [Configure Computers to Collect and Forward Events](https://go.microsoft.com/fwlink/p/?LinkId=145012).
Additionally, WDAC events are collected by [Microsoft Defender Advanced Threat Protection](https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/microsoft-defender-advanced-threat-protection) and can be queried using the [advanced hunting](querying-application-control-events-centrally-using-advanced-hunting.md) feature.
## Application and user support policy
Considerations include:
@ -39,7 +76,7 @@ Considerations include:
- How are existing rules updated?
- Are events forwarded for review?
**Help desk support**
### Help desk support
If your organization has an established help desk support department in place, consider the following when deploying WDAC policies:
@ -48,49 +85,17 @@ If your organization has an established help desk support department in place, c
- Who are the contacts in the support department?
- How will the support department resolve application control issues between the end user and those who maintain the WDAC rules?
**End-user support**
### End-user support
Because WDAC is preventing unapproved apps from running, it is important that your organization carefully plan how to provide end-user support. Considerations include:
- Do you want to use an intranet site as a first line of support for users who have tried to run a blocked app?
- How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily allow access to a blocked app?
**WDAC event management**
Each time that a process requests permission to run, WDAC creates an event in the CodeIntegrity log. The event details which file tried to run, the attributes of that file, and the user that initiated the request.
Collecting these events in a central location can help you maintain your WDAC policy and troubleshoot rule configuration problems. Event collection technologies such as those available in Windows allow administrators to subscribe to specific event channels and have the events from source computers aggregated into a forwarded event log on a Windows Server operating system collector. For more info about setting up an event subscription, see [Configure Computers to Collect and Forward Events](https://go.microsoft.com/fwlink/p/?LinkId=145012).
### Policy maintenance
As new apps are deployed or existing apps are updated by the software publisher, you will need to make revisions to your rule collections to ensure that the policy is current.
To ensure version control when modifying an WDAC policy, use Group Policy management software that allows you to create versions of Group Policy Objects (GPOs). An example of this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop Optimization Pack. For more info about Advanced Group Policy Management, see [Advanced Group Policy Management Overview](https://go.microsoft.com/fwlink/p/?LinkId=145013) (https://go.microsoft.com/fwlink/p/?LinkId=145013).
 
**New version of a supported app**
When a new version of an app is deployed in the organization, you need to determine whether to continue to support the previous version of that app. To add the new version, you might only need to create a new rule for each file that is associated with the app. If you are using publisher conditions and the version is not specified, then the existing rule or rules might be sufficient to allow the updated file to run. You must ensure, however, that the updated app has not altered the file names or added files to support new functionality. If so, then you must modify the existing rules or create new rules. To continue to reuse a publisher-based rule without a specific file version, you must also ensure that the file's digital signature is still identical to the previous version—the publisher, product name, and file name (if configured in your rule) must all match for the rule to be correctly applied.
To determine whether a file has been modified during an app update, review the publisher's release details provided with the update package. You can also review the publisher's web page to retrieve this information. Each file can also be inspected to determine the version.
For files that are allowed or denied with file hash conditions, you must retrieve the new file hash. To add support for a new version and maintain support for the older version, you can either create a new file hash rule for the new version or edit the existing rule and add the new file hash to the list of conditions.
For files with path conditions, you should verify that the installation path has not changed from what is stated in the rule. If the path has changed, you need to update the rule before installing the new version of the app
**Recently deployed app**
To support a new app, you must add one or more rules to the existing WDAC policy.
**App is no longer supported**
If your organization has determined that it will no longer support an application that has WDAC rules associated with it, the easiest way to prevent users from running the app is to delete these rules.
## Next steps
## Document your plan
After deciding how your organization will manage your WDAC policy, record your findings.
- **End-user support policy.** Document the process that you will use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel have clear escalation steps so that the administrator can update the WDAC policy, if necessary.
- **Event processing.** Document whether events will be collected in a central location called a store, how that store will be archived, and whether the events will be processed for analysis.
- **Policy maintenance.** Detail how rules will be added to the policy and in which GPO the rules are defined.
For information and steps how to document your processes, see [Document your application control management processes](document-your-windows-defender-application-control-management-processes.md).
- **Policy management.** Detail what policies are planned, how they will be managed, and how rules will be maintained over time.

View File

@ -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 todays IT organization is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone additional company assets. WDAC policies follow a similar methodology, that begins with the establishment of a golden computer. As with imaging, you can have multiple golden computers based on model, department, application set, and so on. Although the thought process around the creation of WDAC policies is similar to imaging, these policies should be maintained independently. Assess the necessity of additional WDAC policies based on what should be allowed to be installed and run and for whom. For more details on doing this assessment, see the [WDAC Design Guide](windows-defender-application-control-design-guide.md).
Optionally, WDAC can align with your software catalog as well as any IT departmentapproved applications. One straightforward method to implement WDAC is to use existing images to create one master WDAC policy. You do so by creating a WDAC policy from each image, and then by merging the policies. This way, what is installed on all of those images will be allowed to run, if the applications are installed on a computer based on a different image. Alternatively, you may choose to create a base applications policy and add policies based on the computers role or department. Organizations have a choice of how their policies are created, merged or serviced, and managed.
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 Microsofts Intelligent Security Graph (ISG). |
@ -82,15 +74,15 @@ 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 |
|----------- | ----------- |
| **Hash** | Specifies individual hash values for each discovered binary. Although this level is specific, it can cause additional administrative overhead 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 individual binary file names. Although the hash values for an application are modified when updated, the file names are typically not. This offers less specific security than the hash level but does not typically require a policy update when any binary is modified. |
| **FilePath** | Beginning with Windows 10 version 1903, this specifies rules that allow execution of binaries contained in paths that are admin-writeable only. By default, WDAC performs a user-writeability check at runtime which ensures that the current permissions on the specified filepath and its parent directories (recursively) do not allow standard users write access. <br> Note that filepath rules do not provide the same security guarantees that explicit signer rules do, as they are based on mutable access permissions. Filepath rules are best suited for environments where most users are running as standard rather than admin. IT Pros should take care while crafting path rules to allow paths that they know are likely to remain to be admin-writeable only and deny execution from sub-directories where standard users can modify ACLs on the folder. <br> There is a defined list of SIDs which are recognized as admins (below). If a file has write permissions for a SID not in this list, the file will be flagged as user writeable. <br> S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523. <br> Wildcards can be used at the beginning or end of a path rule: only one wildcard is allowed per path rule. Wildcards placed at the end of a path authorize all files in that path and its subdirectories recursively (ex. C:\\* would include C:\foo\\* ). Wildcards placed at the beginning of a path scan all directories for files with a specific name (ex. \*\bar.exe would allow C:\bar.exe and C:\foo\bar.exe). Wildcards in the middle of a path are not supported (ex. C:\\*\foo.exe). Without a wildcard, the rule will allow only a specific file (ex. C:\foo\bar.exe). <br> Supported macros: %WINDIR%, %SYSTEM32%, %OSDRIVE%.|
| **FilePath** | Beginning with Windows 10 version 1903, this specifies rules that allow execution of binaries contained under specific file path locations. Additional information about FilePath level rules can be found below. |
> [!NOTE]
> Due to an existing bug, you can not combine Path-based ALLOW rules with any DENY rules in a single policy. Instead, either separate DENY rules into a separate Base policy or move the Path-based ALLOW rules into a supplemental policy as described in [Deploy multiple WDAC policies.](deploy-multiple-windows-defender-application-control-policies.md)
@ -119,3 +111,20 @@ As part of normal operations, they will eventually install software updates, or
They could also choose to create a catalog that captures information about the unsigned internal application, then sign and distribute the catalog. Then the internal application could be handled by WDAC policies in the same way as any other signed application. An update to the internal application would only require that the catalog be regenerated, signed, and distributed (no restarts would be required).
## More information about filepath rules
Filepath rules do not provide the same security guarantees that explicit signer rules do, as they are based on mutable access permissions. Filepath rules are best suited for environments where most users are running as standard rather than admin. IT Pros should take care while crafting path rules to allow paths that they know are likely to remain to be admin-writeable only and deny execution from sub-directories where standard users can modify ACLs on the folder.
By default, WDAC performs a user-writeability check at runtime which ensures that the current permissions on the specified filepath and its parent directories (recursively) do not allow standard users write access.
There is a defined list of SIDs which WDAC recognizes as admins. If a filepath allows write permissions for any SID not in this list, the filepath is considered to be user-writeable even if the additional SID is associated to a custom admin user. To handle these special cases, you can override WDAC's runtime admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option described above.
WDAC's list of well-known admin SIDs are: <br>
S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.
When generating filepath rules using [New-CIPolicy](https://docs.microsoft.com/powershell/module/configci/new-cipolicy), a unique, fully-qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](https://docs.microsoft.com/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards and include them in your [New-CIPolicy](https://docs.microsoft.com/powershell/module/configci/new-cipolicy) scan using the -Rules switch.
Wildcards can be used at the beginning or end of a path rule: only one wildcard is allowed per path rule. Wildcards placed at the end of a path authorize all files in that path and its subdirectories recursively (ex. C:\\* would include C:\foo\\* ). Wildcards placed at the beginning of a path will allow the exact specified filename under any path (ex. \*\bar.exe would allow C:\bar.exe and C:\foo\bar.exe). Wildcards in the middle of a path are not supported (ex. C:\\*\foo.exe). Without a wildcard, the rule will allow only a specific file (ex. C:\foo\bar.exe). <br> Supported macros: %WINDIR%, %SYSTEM32%, %OSDRIVE%.
> [!NOTE]
> Due to an existing bug, you can not combine Path-based ALLOW rules with any DENY rules in a single policy. Instead, either separate DENY rules into a separate Base policy or move the Path-based ALLOW rules into a supplemental policy as described in [Deploy multiple WDAC policies.](deploy-multiple-windows-defender-application-control-policies.md)

View File

@ -25,55 +25,62 @@ ms.date: 02/08/2018
**Applies to:**
- Windows 10
- Windows Server 2016
- Windows Server 2016 and above
This topic for the IT professional lists the design questions, possible answers, and ramifications of the decisions when you plan a deployment of application control policies by using Windows Defender Application Control (WDAC) within a Windows operating system environment.
This topic is for the IT professional and lists the design questions, possible answers, and ramifications of the decisions when you plan a deployment of application control policies by using Windows Defender Application Control (WDAC) within a Windows operating system environment.
When you begin the design and planning process, you should consider the ramifications of your design choices. The resulting decisions will affect your policy deployment scheme and subsequent application control policy maintenance.
You should consider using WDAC as part of your organization's application control policies if all the following are true:
You should consider using WDAC as part of your organization's application control policies if the following are true:
- You have deployed or plan to deploy the supported versions of Windows in your organization.
- You need improved control over the access to your organization's applications and the data your users access.
- The number of applications in your organization is known and manageable.
- Your organization has a well-defined process for application management and deployed.
- You have resources to test policies against the organization's requirements.
- You have resources to involve Help Desk or to build a self-help process for end-user application access issues.
- The group's requirements for productivity, manageability, and security can be controlled by restrictive policies.
The following questions are not in priority or sequential order. They should be considered when you deploy application control policies (as appropriate for your targeted environment).
## Decide what policies to create
### Which apps do you need to control in your organization?
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.
You might need to control a limited number of apps because they access sensitive data, or you might have to exclude all applications except those that are sanctioned for business purposes. There might be certain business groups that require strict control, and others that promote independent application usage.
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?
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|
| - | - |
| Control all apps | WDAC policies control applications by creating an allowed list of applications. Exceptions are also possible. WDAC policies can only be applied to applications installed on computers running Windows 10 . |
| Control specific apps | When you create WDAC rules, a list of allowed apps are created. All apps on that list will be allowed to run (except those on the exception list). Apps that are not on the list will be prevented from running. WDAC policies can only be applied to apps installed on computers running Windows 10 or Windows Server 2016. |
|Control only Classic Windows applications, only Universal Windows apps, or both| WDAC policies control apps by creating an allowed list of apps based on code signing certificate and\or file hash information. Because Universal Windows apps are all signed by the Windows Store, Classic Windows applications and Universal Windows apps can be controlled together. WDAC policies for Universal Windows apps can be applied only to apps that are installed on PCs that support the Microsoft Store, but Classic Windows applications can be controlled with WDAC on Windows. The rules you currently have configured for Classic Windows applications can remain, and you can create new ones for Universal Windows apps.|
| Control apps by business group | WDAC policies can be applied through a Group Policy Object (GPO) to computer objects within an organizational unit (OU). |
| Control apps by computer, not user | WDAC is a computer-based policy implementation. If your domain or site organizational structure is not based on a logical user structure, such as an OU, you might want to set up that structure before you begin your WDAC planning. Otherwise, you will have to identify users, their computers, and their app access requirements.|
|Understand app usage, but there is no need to control any apps yet | WDAC policies can be set to audit app usage to help you track which apps are used in your organization. You can then use the CodeIntegrity log in Event Viewer to create WDAC policies.|
| 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](use-windows-defender-application-control-with-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. |
| 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 Windows Defender Antivirus and 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.|
### How do you currently control app usage in your organization?
### Are internally-developed line-of-business (LOB) apps and apps developed by 3rd parties digitally signed?
Most organizations have evolved app control policies and methods over time. With heightened security concerns and an emphasis on tighter IT control over desktop use, your organization might decide to consolidate app control practices or design a comprehensive application control scheme. WDAC includes improvements over AppLocker and SRP in the architecture and management of application control policies.
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 |
| - | - |
| Security polices (locally set or through Mobile Device Management (MDM) or Group Policy) | Using WDAC requires increased effort in planning to create correct policies, but this results in a simpler distribution method.|
| Non-Microsoft app control software | Using WDAC requires a complete app control policy evaluation and implementation.|
| Managed usage by group or OU | Using WDAC requires a complete app control policy evaluation and implementation.|
| Authorization Manager or other role-based access technologies | Using WDAC requires a complete app control policy evaluation and implementation.|
| Other | Using WDAC requires a complete app control policy evaluation and implementation.|
| 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. |
### Are there specific groups in your organization that need customized application control policies?
Most business groups 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 groups priorities before you deploy application control policies for the entire organization.
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 groups 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.
| Possible answers | Design considerations |
| - | - |
| Yes | For each group, you need to create a list that includes their application control requirements. Although this may increase the planning time, it will most likely result in a more effective deployment.<br/>If your GPO structure is not currently configured so that you can apply different policies to specific groups, you can alternatively apply WDAC rules in a GPO to specific user groups.|
| 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?
@ -83,7 +90,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.|
| 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. |
| 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?
@ -93,56 +100,3 @@ Preventing your users from accessing known, deployed, or personal applications w
| - | - |
| Yes | Involve the support department early in the planning phase because your users may inadvertently be blocked from using their applications, or they may seek exceptions to use specific applications. |
| No | Invest time in developing online support processes and documentation before deployment. |
### Do you know what applications require restrictive policies?
Any successful application control policy implementation is based on your knowledge and understanding of app usage within the organization or business group. In addition, the application control design is dependent on the security requirements for data and the apps that access that data.
| Possible answers | Design considerations |
| - | - |
| Yes | You should determine the application control priorities for a business group and then attempt to design the simplest scheme for their application control policies. |
| No | You will have to perform an audit and requirements gathering project to discover the application usage. WDAC provides the means to deploy policies in audit mode.|
### How do you deploy or sanction applications (upgraded or new) in your organization?
Implementing a successful application control policy is based on your knowledge and understanding of application usage within the organization or business group. In addition, the application control design is dependent on the security requirements for data and the applications that access that data. Understanding the upgrade and deployment policy will help shape the construction of the application control policies.
| Possible answers | Design considerations |
| - | - |
| Ad hoc | You need to gather requirements from each group. Some groups might want unrestricted access or installation, while other groups might want strict controls.|
| Strict written policy or guidelines to follow | You need to develop WDAC rules that reflect those policies, and then test and maintain the rules. |
| No process in place | You need to determine if you have the resources to develop an application control policy, and for which groups. |
### What are your organization's priorities when implementing application control policies?
Some organizations will benefit from application control policies as shown by an increase in productivity or conformance, while others will be hindered in performing their duties. Prioritize these aspects for each group to allow you to evaluate the effectiveness of WDAC.
| Possible answers | Design considerations |
| - | - |
| Productivity: The organization assures that tools work and required applications can be installed. | To meet innovation and productivity goals, some groups require the ability to install and run a variety of software from different sources, including software that they developed. Therefore, if innovation and productivity is a high priority, managing application control policies through an allowed list might be time consuming and an impediment to progress. |
| Management: The organization is aware of and controls the apps it supports. | In some business groups, application usage can be managed from a central point of control. WDAC policies can be built into a GPO for that purpose. This shifts the burden of app access to the IT department, but it also has the benefit of controlling the number of apps that can be run and controlling the versions of those apps|
| Security: The organization must protect data in part by ensuring that only approved apps are used. | WDAC can help protect data by allowing a defined set of users access to apps that access the data. If security is the top priority, the application control policies will be the most restrictive.|
### How are apps currently accessed in your organization?
WDAC is very effective for organizations that have application restriction requirements if they have environments with a simple topography and application control policy goals that are straightforward. For example, WDAC can benefit an environment where non-employees have access to computers that are connected to the organizational network, such as a school or library. Large organizations also benefit from WDAC policy deployment when the goal is to achieve a detailed level of control on the desktop computers with a relatively small number of applications to manage, or when the applications are manageable with a small number of rules.
| Possible answers | Design considerations |
| - | - |
| Users run without administrative rights. | Apps are installed by using an installation deployment technology.|
| WDAC can help reduce the total cost of ownership for business groups that typically use a finite set of apps, such as human resources and finance departments. At the same time, these departments access highly sensitive information, much of which contains confidential and proprietary information. By using WDAC to create rules for specific apps that are allowed to run, you can help limit unauthorized applications from accessing this information.<br/>**Note: **WDAC can also be effective in helping create standardized desktops in organizations where users run as administrators. | Users must be able to install applications as needed.
| Users currently have administrator access, and it would be difficult to change this.|Enforcing WDAC rules is not suited for business groups that must be able to install apps as needed and without approval from the IT department. If one or more OUs in your organization has this requirement, you can choose not to enforce application rules in those OUs by using WDAC or to implement the audit only enforcement setting.|
### Is the structure in Active Directory Domain Services based on the organization's hierarchy?
Designing application control policies based on an organizational structure that is already built into Active Directory Domain Services (AD DS) is easier than converting the existing structure to an organizational structure.
Because the effectiveness of application control policies is dependent on the ability to update policies, consider what organizational work needs to be accomplished before deployment begins.
| Possible answers | Design considerations |
| - | - |
| Yes | WDAC rules can be developed and implemented through Group Policy, based on your AD DS structure.|
| No | The IT department must create a scheme to identify how application control policies can be applied to the correct user or computer.|
## Record your findings
The next step in the process is to record and analyze your answers to the preceding questions. If WDAC is the right solution for your goals, you can set your application control policy objectives and plan your WDAC rules.

View File

@ -1,6 +1,6 @@
---
title: Windows Defender Application Control design guide (Windows 10)
description: Microsoft Windows Defender Device Guard is a feature set that consists of both hardware and software system integrity hardening features that revolutionize the Windows operating systems security.
description: Microsoft Windows Defender Application Control allows organizations to control what apps and drivers will run on their managed Windows 10 devices.
keywords: whitelisting, security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: w10
@ -22,10 +22,20 @@ ms.date: 02/20/2018
**Applies to**
- Windows 10
- Windows Server
- Windows Server 2016 and above
This guide covers design and planning for Windows Defender Application Control (WDAC). It is intended to help security architects, security administrators, and system administrators create a plan that addresses specific application control requirements for different departments or business groups within an organization.
## Plan for success
A common refrain you may hear about application control is that it is "too hard". While it is true that application control is not as simple as flipping a switch, organizations can be very successful if they take a methodical approach and carefully plan their approach. In reality, the issues that lead to failure with application control often arise from business issues rather than technology challenges. Organizations that have successfully deployed application control have ensured the following before starting their planning:
- Executive sponsorship and organizational buy-in is in place.
- There is a clear **business** objective for using application control and it is not being planned as a purely technical problem from IT.
- The organization has a plan to handle potential helpdesk support requests for users who are blocked from running some apps.
- The organization has considered where application control can be most useful (e.g. securing sensitive workloads or business functions) and also where it may be difficult to achieve (e.g. developer workstations).
Once these business factors are in place, you are ready to begin planning your WDAC deployment. The following topics can help guide you through your planning process.
## In this section
@ -34,6 +44,5 @@ This guide covers design and planning for Windows Defender Application Control (
| [Understand WDAC policy design decisions](understand-windows-defender-application-control-policy-design-decisions.md) | This topic lists the design questions, possible answers, and ramifications of the decisions when you plan a deployment of application control policies. |
| [Select the types of rules to create](select-types-of-rules-to-create.md) | This topic lists resources you can use when selecting your application control policy rules by using WDAC. |
| [Plan for WDAC policy management](plan-windows-defender-application-control-management.md) | This topic describes the decisions you need to make to establish the processes for managing and maintaining WDAC policies. |
| [Create your WDAC planning document](create-your-windows-defender-application-control-planning-document.md) | This planning topic summarizes the information you need to research and include in your planning document. |
After planning is complete, the next step is to deploy WDAC. The [Windows Defender Application Control Deployment Guide](windows-defender-application-control-deployment-guide.md) covers the creation and testing of policies, deploying the enforcement setting, and managing and maintaining the policies.

View File

@ -1,6 +1,6 @@
---
title: Windows Defender Application Control (WDAC) (Windows 10)
description: Windows Defender Application Control restricts which applications users are allowed to run and the code that runs in the system core.
title: Application Control for Windows
description: 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
ms.prod: w10
@ -17,7 +17,7 @@ manager: dansimp
ms.date: 01/08/2019
---
# Windows Defender Application Control
# Application Control
**Applies to:**
@ -26,35 +26,76 @@ ms.date: 01/08/2019
- Windows Server 2019
With thousands of new malicious files created every day, using traditional methods like antivirus solutions—signature-based detection to fight against malware—provides an inadequate defense against new attacks.
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.
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 is a crucial line of defense for protecting enterprises given todays threat landscape, and it has an inherent advantage over traditional antivirus solutions.
Specifically, application control moves away from the traditional application trust model where all applications are assumed trustworthy by default 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.).
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).
Windows Defender Application Control (WDAC) 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).
WDAC policies also block unsigned scripts and MSIs, and Windows PowerShell runs in [Constrained Language Mode](https://docs.microsoft.com/powershell/module/microsoft.powershell.core/about/about_language_modes?view=powershell-5.1).
Application control is a crucial line of defense for protecting enterprises given todays 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.).
> [!NOTE]
> Although application control can significantly harden your computers against malicious code, we recommend that you continue to maintain an enterprise antivirus solution for a well-rounded enterprise security portfolio.
Windows 10 includes two technologies that can be used for application control depending on your organization's specific scenarios and requirements:<br>
- **Windows Defender Application Control**; and
- **AppLocker**
## Windows Defender Application Control
Windows Defender Application Control (WDAC) was introduced with Windows 10 and allows organizations to control what drivers and applications are allowed to run on their Windows 10 clients. WDAC was designed as a security feature under the [servicing criteria](https://www.microsoft.com/msrc/windows-security-servicing-criteria) defined by the Microsoft Security Response Center (MSRC).
> [!NOTE]
> Prior to Windows 10, version 1709, Windows Defender Application Control was known as configurable code integrity policies.
## WDAC System Requirements
WDAC policies apply to the managed computer as a whole and affects all users of the device. WDAC rules can be defined based on:
- Attributes of the codesigning certificate(s) used to sign an app and its binaries;
- Attributes of the app's binaries that come from the signed metadata for the files, such as Original Filename and version, or the hash of the file;
- The reputation of the app as determined by Microsoft's Intelligent Security Graph;
- The identity of the process that initiated the installation of the app and its binaries (managed installer);
- The path from which the app or file is launched (beginning with Windows 10 version 1903);
- The process that launched the app or binary.
### WDAC System Requirements
WDAC policies can only be created on computers beginning with Windows 10 Enterprise or Windows Server 2016 and above.
They can be applied to computers running any edition of Windows 10 or Windows Server 2016 and optionally managed via Mobile Device Management (MDM), such as Microsoft Intune.
Group Policy or Intune can be used to distribute WDAC policies.
Group Policy can also be used to deploy WDAC policies to Windows 10 Enterprise edition or Windows Server 2016 and above.
## New and changed functionality
## AppLocker
Prior to Windows 10, version 1709, Windows Defender Application Control was known as Windows Defender Device Guard configurable code integrity policies.
AppLocker was introduced with Windows 7 and allows organizations to control what applications their users are allowed to run on their Windows clients. AppLocker provides security value as a defense in depth feature and helps end users avoid running unapproved software on their computers.
Beginning with Windows 10, version 1703, you can use WDAC not only to control applications, but also to control whether specific plug-ins, add-ins, and modules can run from specific apps (such as a line-of-business application or a browser).
For more information, see [Use a Windows Defender Application Control policy to control specific plug-ins, add-ins, and modules](use-windows-defender-application-control-policy-to-control-specific-plug-ins-add-ins-and-modules.md).
AppLocker policies can apply to all users on a computer or to individual users and groups. AppLocker rules can be defined based on:
- Attributes of the codesigning certificate(s) used to sign an app and its binaries;
- Attributes of the app's binaries that come from the signed metadata for the files, such as Original Filename and version, or the hash of the file;
- The path from which the app or file is launched (beginning with Windows 10 version 1903).
### AppLocker System Requirements
AppLocker policies can only be configured on and applied to computers that are running on the supported versions and editions of the Windows operating system. For more info, see [Requirements to Use AppLocker](applocker/requirements-to-use-applocker.md).
AppLocker policies can be deployed using Group Policy or MDM.
## Choose when to use WDAC or AppLocker
Although either AppLocker or WDAC can be used to control application execution on Windows 10 clients, the following factors can help you decide when to use each of the technologies.
**WDAC is best when:**
- You are adopting application control primarily for security reasons.
- Your application control policy can be applied to all users on the managed computers.
- All of the devices you wish to manage are running Windows 10.
**AppLocker is best when:**
- You have a mixed Windows operating system (OS) environment and need to apply the same policy controls to Windows 10 and earlier versions of the OS.
- You need to apply different policies for different users or groups on a shared computer.
- You are using application control to help users avoid running unapproved software, but you do not require a solution designed as a security feature.
- You do not wish to enforce application control on application files such as DLLs or drivers.
**When to use both WDAC and AppLocker together**
AppLocker can also be deployed as a complement to WDAC to add user- or group-specific rules for shared device scenarios where its important to prevent some users from running specific apps.
As a best practice, you should enforce WDAC at the most restrictive level possible for your organization, and then you can use AppLocker to fine-tune the restrictions to an even lower level.
## See also
- [WDAC design guide](windows-defender-application-control-design-guide.md)
- [WDAC deployment guide](windows-defender-application-control-deployment-guide.md)
- [AppLocker overview](applocker/applocker-overview.md)

View File

@ -1,30 +0,0 @@
---
title: Windows Defender Device Guard and AppLocker (Windows 10)
description: Explains how
keywords: virtualization, whitelisting, security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
ms.collection: M365-security-compliance
author: jsuther1974
ms.reviewer: isbrahm
ms.author: dansimp
manager: dansimp
ms.date: 05/03/2018
---
# Windows Defender Device Guard with AppLocker
Although [AppLocker](applocker/applocker-overview.md) is not considered a new Windows Defender Device Guard feature, it complements Windows Defender Device Guard functionality when Windows Defender Application Control (WDAC) cannot be fully implemented or its functionality does not cover every desired scenario.
There are many scenarios in which WDAC would be used alongside AppLocker rules.
As a best practice, you should enforce WDAC at the most restrictive level possible for your organization, and then you can use AppLocker to fine-tune the restrictions to an even lower level.
> [!NOTE]
> One example of how Windows Defender Device Guard functionality can be enhanced by AppLocker is when you want to apply different policies for different users on the same device. For example, you may allow your IT support personnel to run additional apps that you do not allow for your end-users. You can accomplish this user-specific enforcement by using an AppLocker rule.
AppLocker and Windows Defender Device Guard should run side-by-side in your organization, which offers the best of both security features at the same time and provides the most comprehensive security to as many devices as possible.
In addition to these features, we recommend that you continue to maintain an enterprise antivirus solution for a well-rounded enterprise security portfolio.