Merge branch 'master' into ios

This commit is contained in:
Gary Moore
2020-09-30 14:38:35 -07:00
committed by GitHub
2 changed files with 28 additions and 40 deletions

View File

@ -25,7 +25,7 @@ ms.date: 10/30/2019
Beginning with the Windows 10 November 2019 update (build 18363), Microsoft Intune enables customers to deploy and run business critical Win32 applications as well as Windows components that are normally blocked in S mode (ex. PowerShell.exe) on their Intune-managed Windows 10 in S mode devices.
With Intune, IT Pros can now configure their managed S mode devices using a Windows Defender Application Control (WDAC) supplemental policy that expands the S mode base policy to authorize the apps their business uses. This feature changes the S mode security posture from every app is Microsoft-verified" to every app is verified by Microsoft or your organization.
With Intune, IT Pros can now configure their managed S mode devices using a Windows Defender Application Control (WDAC) supplemental policy that expands the S mode base policy to authorize the apps their business uses. This feature changes the S mode security posture from "every app is Microsoft-verified" to "every app is verified by Microsoft or your organization".
Refer to the below video for an overview and brief demo.
> [!VIDEO https://www.microsoft.com/videoplayer/embed/RE4mlcp]
@ -57,7 +57,7 @@ The general steps for expanding the S mode base policy on your Intune-managed de
```powershell
Set-RuleOption -FilePath "<path>\SupplementalPolicy.xml>" -Option 3 Delete
```
This deletes the audit mode qualifier.
This deletes the 'audit mode' qualifier.
- Since you'll be signing your policy, you must authorize the signing certificate you will use to sign the policy and optionally one or more additional signers that can be used to sign updates to the policy in the future. For more information, refer to Section 2, Sign policy. Use Add-SignerRule to add the signing certificate to the WDAC policy:
```powershell
@ -88,9 +88,9 @@ Refer to [Intune Standalone - Win32 app management](https://docs.microsoft.com/i
## Optional: Process for Deploying Apps using Catalogs
![Deploying Apps using Catalogs](images/wdac-intune-app-catalogs.png)
Your supplemental policy can be used to significantly relax the S mode base policy, but there are security trade-offs you must consider in doing so. For example, you can use a signer rule to trust an external signer, but that will authorize all apps signed by that certificate, which may include apps you dont want to allow as well.
Your supplemental policy can be used to significantly relax the S mode base policy, but there are security trade-offs you must consider in doing so. For example, you can use a signer rule to trust an external signer, but that will authorize all apps signed by that certificate, which may include apps you don't want to allow as well.
Instead of authorizing signers external to your organization, Intune has added new functionality to make it easier to authorize existing applications (without requiring repackaging or access to the source code) through the use of signed catalogs. This works for apps which may be unsigned or even signed apps when you dont want to trust all apps that may share the same signing certificate.
Instead of authorizing signers external to your organization, Intune has added new functionality to make it easier to authorize existing applications (without requiring repackaging or access to the source code) through the use of signed catalogs. This works for apps which may be unsigned or even signed apps when you don't want to trust all apps that may share the same signing certificate.
The basic process is to generate a catalog file for each app using Package Inspector, then sign the catalog files using the DGSS or a custom PKI. Use the Add-SignerRule PowerShell cmdlet as shown above to authorize the catalog signing certificate in the supplemental policy. After that, IT Pros can use the standard Intune app deployment process outlined above. Refer to [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md) for more in-depth guidance on generating catalogs.
@ -184,8 +184,6 @@ Below is a sample policy that allows kernel debuggers, PowerShell ISE, and Regis
In order to revert users to an unmodified S mode policy, an IT Pro can remove a user or users from the targeted Intune group which received the policy, which will trigger a removal of both the policy and the authorization token from the device.
IT Pros also have the choice of deleting a supplemental policy through Intune.
> [!Note]
> This feature currently has a known bug which occurs when an S mode supplemental policy is deleted through Intune, in which the policy is not immediately removed from the devices to which it was deployed. A fix is expected in the 2D update in late February 2020. In the meantime, IT Pros are recommended to update their policy with the below 'empty' policy which makes no changes to S mode.
```xml
<?xml version="1.0" encoding="utf-8"?>

View File

@ -1,7 +1,7 @@
---
title: WDAC and AppLocker Overview
description: Compare Windows application control technologies.
keywords: security, malware
keywords: security, malware, allow-list, block-list
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: w10
ms.mktglfcycl: deploy
@ -14,7 +14,7 @@ author: denisebmsft
ms.reviewer: isbrahm
ms.author: deniseb
manager: dansimp
ms.date: 04/15/2020
ms.date: 09/30/2020
ms.custom: asr
---
@ -29,58 +29,48 @@ Windows 10 includes two technologies that can be used for application control de
## 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 (CCI) policies.
WDAC was introduced with Windows 10 and allows organizations to control which 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).
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.
- 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](use-windows-defender-application-control-with-intelligent-security-graph.md)
- The identity of the process that initiated the installation of the app and its binaries ([managed installer](use-windows-defender-application-control-with-managed-installer.md))
- The [path from which the app or file is launched](select-types-of-rules-to-create.md#more-information-about-filepath-rules) (beginning with Windows 10 version 1903)
- The process that launched the app or binary
Note that prior to Windows 10, version 1709, Windows Defender Application Control was known as configurable code integrity (CCI). WDAC was also one of the features which comprised the now-defunct term 'Device Guard'.
### WDAC System Requirements
WDAC policies can only be created on computers running Windows 10 build 1903+ on any SKU, pre-1903 Windows 10 Enterprise, or Windows Server 2016 and above.
WDAC policies can be applied to computers running any edition of Windows 10 or Windows Server 2016 and above via a Mobile Device Management (MDM) solution like Intune, a management interface like Configuration Manager, or a script host like PowerShell. Group Policy can also be used to deploy WDAC policies to Windows 10 Enterprise edition or Windows Server 2016 and above, but cannot deploy policies to machines running non-Enterprise SKUs of Windows 10.
WDAC policies can only be created on devices running Windows 10 build 1903+ on any SKU, pre-1903 Windows 10 Enterprise, or Windows Server 2016 and above.
WDAC policies can be applied to devices running any edition of Windows 10 or Windows Server 2016 and above via a Mobile Device Management (MDM) solution like Intune, a management interface like Configuration Manager, or a script host like PowerShell. Group Policy can also be used to deploy WDAC policies to Windows 10 Enterprise edition or Windows Server 2016 and above, but cannot deploy policies to devices running non-Enterprise SKUs of Windows 10.
## AppLocker
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.
AppLocker was introduced with Windows 7 and allows organizations to control which applications are allowed to run on their Windows clients. AppLocker helps to prevent end users from running unapproved software on their computers, but it does not meet the servicing criteria for being a security feature.
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).
- 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
### 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 only be configured on and applied to devices 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.
Generally, it is recommended that customers who are able to implement application control using WDAC rather than AppLocker do so. WDAC is undergoing continual improvements and will be getting added support from Microsoft management platforms. AppLocker is a legacy technology which will continue to receive security fixes but will not undergo new feature improvements.
### 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:
In some cases, however, AppLocker may be the more appropriate technology for your organization. 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.
- You need to apply different policies for different users or groups on shared computers.
## 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.
AppLocker can also be deployed as a complement to WDAC to add user- or group-specific rules for shared device scenarios where it is 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 further fine-tune the restrictions.