deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-17 19:33:37 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Merge branch 'master' into master

Browse Source
This commit is contained in:
isbrahm
2020-02-20 20:23:05 -05:00
committed by GitHub
parent b2c3aef0bb ded072442e
commit 495fa6c409
488 changed files with 7793 additions and 8655 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
windows/security/threat-protection/windows-defender-application-control/LOB-win32-apps-on-s.md
View File

@ -32,7 +32,8 @@ Refer to the below video for an overview and brief demo.
## Policy Authorization Process
![Policy Authorization](images/wdac-intune-policy-authorization.png)
The general steps for expanding the S mode base policy on your devices are to generate a supplemental policy, sign that policy, and then upload the signed policy to Intune and assign it to user or device groups.
The general steps for expanding the S mode base policy on your Intune-managed devices are to generate a supplemental policy, sign that policy, and then upload the signed policy to Intune and assign it to user or device groups. Because you need access to WDAC PowerShell cmdlets to generate your supplemental policy, you should create and manage your policies on a non-S mode device. Once the policy has been uploaded to Intune, we recommend assigning it to a single test S-mode device to verify expected functioning before deploying the policy more broadly.
1. Generate a supplemental policy with WDAC tooling
This policy will expand the S mode base policy to authorize additional applications. Anything authorized by either the S mode base policy or your supplemental policy will be allowed to run. Your supplemental policies can specify filepath rules, trusted publishers, and more.
@ -60,7 +61,7 @@ The general steps for expanding the S mode base policy on your devices are to ge
- 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
Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User -Update`
Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User -Update
```
- Convert to .bin using [ConvertFrom-CIPolicy](https://docs.microsoft.com/powershell/module/configci/convertfrom-cipolicy?view=win10-ps)
@ -70,7 +71,7 @@ The general steps for expanding the S mode base policy on your devices are to ge
2. Sign policy
Supplemental S mode policies must be digitally signed. To sign your policy, you can choose to use the Device Guard Signing Service or your organization's custom Public Key Infrastructure (PKI). Refer to [Use the Device Guard Signing Portal in the Microsoft Store for Business](use-device-guard-signing-portal-in-microsoft-store-for-business.md) for guidance on using DGSS and [Create a code signing cert for WDAC](create-code-signing-cert-for-windows-defender-application-control.md) for guidance on signing using an internal CA.
Supplemental S mode policies must be digitally signed. To sign your policy, you can choose to use the Device Guard Signing Service (DGSS) or your organization's custom Public Key Infrastructure (PKI). Refer to [Use the Device Guard Signing Portal in the Microsoft Store for Business](use-device-guard-signing-portal-in-microsoft-store-for-business.md) for guidance on using DGSS and [Create a code signing cert for WDAC](create-code-signing-cert-for-windows-defender-application-control.md) for guidance on signing using an internal CA.
Rename your policy to "{PolicyID}.p7b" after you've signed it. PolicyID can be found by inspecting the Supplemental Policy XML.
@ -91,7 +92,7 @@ Your supplemental policy can be used to significantly relax the S mode base poli
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. 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.
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.
> [!Note]
> Every time an app updates, you will need to deploy an updated catalog. Because of this, IT Pros should try to avoid using catalog files for applications that auto-update and direct users not to update applications on their own.
@ -180,8 +181,11 @@ Below is a sample policy that allows kernel debuggers, PowerShell ISE, and Regis
</SiPolicy>
```
## Policy removal
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 a policy deletion bug, with a fix expected in the 2D update in late February 2020. Devices of users who are unenrolled will still have their WDAC policies removed. In the mentime, IT Pros are recommended to update their policy with the below 'empty' policy which makes no changes to S mode.
> 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"?>
@ -233,3 +237,6 @@ Below is a sample policy that allows kernel debuggers, PowerShell ISE, and Regis
</Settings>
</SiPolicy>
```
## Errata
If an S-mode device with a policy authorization token and supplemental policy is rolled back from the 1909 update to the 1903 build, it will not revert to locked-down S mode until the next policy refresh. To achieve an immediate change to a locked-down S mode state, IT Pros should delete any tokens in %SystemRoot%\System32\CI\Tokens\Active.

7
windows/security/threat-protection/windows-defender-application-control/applocker/document-your-applocker-rules.md
View File

@ -1,6 +1,6 @@
---
title: Document your AppLocker rules (Windows 10)
description: Learn how to document your Applocker rules with this planning guide. Associate rule conditions with files, permissions, rule source, and implementation.
description: Learn how to document your AppLocker rules and associate rule conditions with files, permissions, rule source, and implementation.
ms.assetid: 91a198ce-104a-45ff-b49b-487fb40cd2dd
ms.reviewer:
ms.author: dansimp
@ -23,7 +23,7 @@ ms.date: 09/21/2017
- Windows 10
- Windows Server
This topic describes what rule conditions to associate with each file, how to associate the rule conditions with each file, the source of the rule, and whether the file should be included or excluded.
This topic describes what AppLocker rule conditions to associate with each file, how to associate these rule conditions, the source of the rule, and whether the file should be included or excluded.
## Record your findings
@ -119,9 +119,10 @@ The following table details sample data for documenting rule type and rule condi
</tbody>
</table>
## Next steps
For each rule, determine whether to use the allow or deny option. Then, three tasks remain:
For each rule, determine whether to use the allow or deny option, and then complete the following tasks:
- [Determine Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
- [Plan for AppLocker policy management](plan-for-applocker-policy-management.md)

6
windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-lightly-managed-devices.md
View File

@ -43,8 +43,8 @@ Alice identifies the following key factors to arrive at the "circle-of-trust" fo
- All clients are running Windows 10 version 1903 or above;
- All clients are managed by Microsoft Endpoint Manager (MEM) either with Configuration Manager (MEMCM) standalone or hybrid mode with Intune;
> [!NOTE]
> Microsoft Endpoint Configuration Manager was previously known as System Center Configuration Manager (SCCM)
> [!NOTE]
> Microsoft Endpoint Configuration Manager was previously known as System Center Configuration Manager (SCCM).
- Some, but not all, apps are deployed using MEMCM;
- Most users are local administrators on their devices;
@ -117,7 +117,7 @@ Alice follows these steps to complete this task:
$PathRules += New-CIPolicyRule -FilePathRule "%windir%\*"
$PathRules += New-CIPolicyRule -FilePathRule "%OSDrive%\Program Files\*"
$PathRules += New-CIPolicyRule -FilePathRule "%OSDrive%\Program Files (x86)\*"
Merge-CIPolicy -OutputFilePath = $LamnaPolicy -PolicyPaths $LamnaPolicy -Rules $PathRules
Merge-CIPolicy -OutputFilePath $LamnaPolicy -PolicyPaths $LamnaPolicy -Rules $PathRules
```
7. If appropriate, add additional signer or file rules to further customize the policy for your organization.

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

@ -160,9 +160,8 @@ Pick the correct version of each .dll for the Windows release you plan to suppor
<Deny ID="ID_DENY_MS_BUILD" FriendlyName="Microsoft.Build.dll" FileName="Microsoft.Build.dll" MinimumFileVersion="65535.65535.65535.65535" />
<Deny ID="ID_DENY_MS_BUILD_FMWK" FriendlyName="Microsoft.Build.Framework.dll" FileName="Microsoft.Build.Framework.dll" MinimumFileVersion="65535.65535.65535.65535" />
<!-- msxml3.dll pick correct version based on release you are supporting -->
<!-- msxml6.dll pick correct version based on release you are supporting -->
<!-- jscript9.dll pick correct version based on release you are supporting -->
<!-- pick the correct version of msxml3.dll, msxml6.dll, and jscript9.dll based on the release you are supporting -->
<!-- the versions of these files in the 1903 release have this issue fixed, so they don’t need to be blocked -->
<!-- RS1 Windows 1607
<Deny ID="ID_DENY_MSXML3" FriendlyName="msxml3.dll" FileName="msxml3.dll" MinimumFileVersion ="8.110.14393.2550"/>
<Deny ID="ID_DENY_MSXML6" FriendlyName="msxml6.dll" FileName="msxml6.dll" MinimumFileVersion ="6.30.14393.2550"/>
@ -893,7 +892,7 @@ Pick the correct version of each .dll for the Windows release you plan to suppor
<FileRuleRef RuleID="ID_DENY_WMIC"/>
<FileRuleRef RuleID="ID_DENY_MWFC" />
<FileRuleRef RuleID="ID_DENY_WFC" />
<!-- Uncomment the relevant line(s) below if you have uncommented them in the rule definitions above.
<!-- uncomment the relevant line(s) below if you have uncommented them in the rule definitions above
<FileRuleRef RuleID="ID_DENY_MSXML3" />
<FileRuleRef RuleID="ID_DENY_MSXML6" />
<FileRuleRef RuleID="ID_DENY_JSCRIPT9" />

10
windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md
View File

@ -67,7 +67,7 @@ You can set several rule options within a WDAC policy. Table 1 describes each ru
| **15 Enabled:Invalidate EAs on Reboot** | When the Intelligent Security Graph option (14) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. This option will cause WDAC to periodically re-validate the reputation for files that were authorized by the ISG.|
| **16 Enabled:Update Policy No Reboot** | Use this option to allow future WDAC policy updates to apply without requiring a system reboot. |
| **17 Enabled:Allow Supplemental Policies** | Use this option on a base policy to allow supplemental policies to expand it. |
| **18 Disabled:Runtime FilePath Rule Protection** | Disable default FilePath rule protection (apps and executables allowed based on file path rules must come from a file path that’s only writable by an administrator) for the path specified in the FilePathRule parameter of the New-CIPolicyRule cmdlet. |
| **18 Disabled:Runtime FilePath Rule Protection** | Disable default FilePath rule protection (apps and executables allowed based on file path rules must come from a file path that’s only writable by an administrator) for any FileRule that allows a file based on FilePath. |
| **19 Enabled:Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically-loaded libraries. |
## Windows Defender Application Control file rule levels
@ -83,11 +83,6 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
| **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 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)
| Rule level | Description |
|----------- | ----------- |
| **SignedVersion** | This combines the publisher rule with a version number. This option allows anything from the specified publisher, with a version at or above the specified version number, to run. |
| **Publisher** | This is a combination of the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. This rule level allows organizations to trust a certificate from a major CA (such as Symantec), but only if the leaf certificate is from a specific company (such as Intel, for device drivers). |
| **FilePublisher** | This is a combination of the “FileName” attribute of the signed file, plus “Publisher” (PCA certificate with CN of leaf), plus a minimum version number. This option trusts specific files from the specified publisher, with a version at or above the specified version number. |
@ -101,6 +96,9 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
> [!NOTE]
> When you create WDAC policies with [New-CIPolicy](https://docs.microsoft.com/powershell/module/configci/new-cipolicy), you can specify a primary file rule level by including the **-Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **-Fallback** parameter. For example, if the primary file rule level is PCACertificate but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate.
> [!NOTE]
> WDAC only supports signer rules for RSA certificate signing keys with a maximum of 4096 bits.
## Example of file rule levels in use
For example, consider some IT professionals in a department that runs many servers. They decide they want their servers to run only software signed by the providers of their software and drivers, that is, the companies that provide their hardware, operating system, antivirus, and other important software. They know that their servers also run an internally written application that is unsigned but is rarely updated. They want to allow this application to run.

7
windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control.md
View File

@ -46,7 +46,7 @@ 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 policies.
> Prior to Windows 10, version 1709, Windows Defender Application Control was known as configurable code integrity (CCI) policies.
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;
@ -58,9 +58,8 @@ WDAC policies apply to the managed computer as a whole and affects all users of
### 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 Endpoint Manager Intune (Intune).
Group Policy can also be used to deploy WDAC policies to Windows 10 Enterprise edition or Windows Server 2016 and above.
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 via a Mobile Device Management (MDM) solution like Intune, a management interface like Configuration Manager, or a scripthost 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.
## AppLocker