From bf5977d74e5c809b84443f27f8d60f9e30cbea41 Mon Sep 17 00:00:00 2001 From: JanKeller1 Date: Fri, 17 Feb 2017 16:08:31 -0800 Subject: [PATCH] Folded in draft updates for new functionality in RS2 --- .../deploy-code-integrity-policies-steps.md | 34 ++++++++++++++++--- ...ed-security-and-code-integrity-policies.md | 4 +++ ...-on-the-device-guard-deployment-process.md | 4 +-- 3 files changed, 36 insertions(+), 6 deletions(-) diff --git a/windows/keep-secure/deploy-code-integrity-policies-steps.md b/windows/keep-secure/deploy-code-integrity-policies-steps.md index 2febd90862..8d56af3696 100644 --- a/windows/keep-secure/deploy-code-integrity-policies-steps.md +++ b/windows/keep-secure/deploy-code-integrity-policies-steps.md @@ -38,11 +38,11 @@ To create a code integrity policy, copy each of the following commands into an e > **Notes** - > - By specifying the *–UserPEs* parameter, rule option **0 Enabled:UMCI** is automatically added to the code integrity policy. If you do not specify this parameter, to enable UMCI, use [Set-RuleOption](https://technet.microsoft.com/library/mt634483.aspx) as shown in the following command:
**Set-RuleOption -FilePath $InitialCIPolicy -Option 0** + > - When you specify the **-UserPEs** parameter (to include user mode executables in the scan), rule option **0 Enabled:UMCI** is automatically added to the code integrity policy. In contrast, if you do not specify **-UserPEs**, the policy will be empty of user mode executables and will only have rules for kernel mode binaries like drivers, in other words, the whitelist will not include applications. If you create such a policy and later add rule option **0 Enabled:UMCI**, all attempts to start applications will cause a response from Device Guard. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application. - > - You can add the *–Fallback* parameter to catch any applications not discovered using the primary file rule level specified by the *–Level* parameter. For more information about file rule level options, see [Code integrity file rule levels](deploy-code-integrity-policies-policy-rules-and-file-rules.md#code-integrity-file-rule-levels) in “Deploy code integrity policies: policy rules and file rules.” + > - You can add the **-Fallback** parameter to catch any applications not discovered using the primary file rule level specified by the **-Level** parameter. For more information about file rule level options, see [Code integrity file rule levels](deploy-code-integrity-policies-policy-rules-and-file-rules.md#code-integrity-file-rule-levels) in “Deploy code integrity policies: policy rules and file rules.” - > - To specify that the code integrity policy scan only a specific drive, include the *–ScanPath* parameter followed by a path. Without this parameter, the entire system is scanned. + > - To specify that the code integrity policy scan only a specific drive, include the **-ScanPath** parameter followed by a path. Without this parameter, the entire system is scanned. > - The preceding example includes `3> CIPolicylog.txt`, which redirects warning messages to a text file, **CIPolicylog.txt**. @@ -136,11 +136,37 @@ You can now use this file to update the existing code integrity policy that you > **Note**  You may have noticed that you did not generate a binary version of this policy as you did in [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer). This is because code integrity policies created from an audit log are not intended to run as stand-alone policies but rather to update existing code integrity policies. +## Use a code integrity policy to control specific plug-ins, add-ins, and modules + +As of Windows 10, version 1703, you can use code integrity policies 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): + +| Approach (as of Windows 10, version 1703) | Guideline | +|---|---| +| You can work from a list of plug-ins, add-ins, or modules that you want only a specific application to be able to run. Other applications would be blocked from running them. | Use `New-CIPolicyRule` with the `-AppID` option. | +| In addition, you can work from a list of plug-ins, add-ins, or modules that you want to block in a specific application. Other applications would be allowed to run them. | Use New-CIPolicyRule with the `-AppID` and `-Deny` options. | + +To work with these options, the typical method is to create a policy that only affects plug-ins, add-ins, and modules, then merge it into your ‘master’ policy (merging is described in the next section). + +For example, to create a code integrity policy that allows **addin1.dll** and **addin2.dll** to run in **ERP1.exe**, your organization’s enterprise resource planning (ERP) application, but blocks those add-ins in other applications, run the following commands. Note that in the second command, **+=** is used to add a second rule to the **$rule** variable: + +``` +$rule = New-CIPolicyRule -DriverFilePath '.\temp\addin1.dll' -Level FileName -AppID '.\ERP1.exe' +$rule += New-CIPolicyRule -DriverFilePath '.\temp\addin2.dll' -Level FileName -AppID '.\ERP1.exe' +New-CIPolicy -Rules $rule -FilePath ".\AllowERPAddins.xml" -UserPEs +``` + +As another example, to create a code integrity policy that blocks **addin3.dll** from running in Microsoft Word, run the following command. You must include the `-Deny` option to block the specified add-ins in the specifed application: + +``` +$rule = New-CIPolicyRule -DriverFilePath '.\temp\addin3.dll' -Level FileName -Deny -AppID '.\winword.exe' +New-CIPolicy -Rules $rule -FilePath ".\BlockAddins.xml" -UserPEs +``` + ## Merge code integrity policies When you develop code integrity policies, you will occasionally need to merge two policies. A common example is when a code integrity policy is initially created and audited. Another example is when you create a single master policy by using multiple code integrity policies previously created from golden computers. Because each computer running Windows 10 can have only one code integrity policy, it is important to properly maintain these policies. In this example, audit events have been saved into a secondary code integrity policy that you then merge with the initial code integrity policy. -> **Note**  The following example uses the code integrity policy .xml files that you created in earlier sections in this topic. You can follow this process, however, with any two code integrity policies you would like to combine. +> **Note**  The following example uses several of the code integrity policy .xml files that you created in earlier sections in this topic. You can follow this process, however, with any two code integrity policies you would like to combine. To merge two code integrity policies, complete the following steps in an elevated Windows PowerShell session: diff --git a/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md b/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md index 3712b6aed0..73592f2841 100644 --- a/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md +++ b/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md @@ -36,6 +36,10 @@ The following table lists security threats and describes the corresponding Devic In this guide, you learn about the individual features found within Device Guard as well as how to plan for, configure, and deploy them. Device Guard with configurable code integrity is intended for deployment alongside additional threat-mitigating Windows features such as [Credential Guard](credential-guard.md) and [AppLocker](applocker-overview.md). +## New and changed functionality + +As of Windows 10, version 1703, you can use code integrity policies 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 code integrity policy to control specific plug-ins, add-ins, and modules](deploy-code-integrity-policies-steps.md#plug-ins). + ## Tools for managing Device Guard features You can easily manage Device Guard features by using familiar enterprise and client-management tools that IT pros use every day: diff --git a/windows/keep-secure/planning-and-getting-started-on-the-device-guard-deployment-process.md b/windows/keep-secure/planning-and-getting-started-on-the-device-guard-deployment-process.md index 2846134874..3e922b1c6b 100644 --- a/windows/keep-secure/planning-and-getting-started-on-the-device-guard-deployment-process.md +++ b/windows/keep-secure/planning-and-getting-started-on-the-device-guard-deployment-process.md @@ -25,8 +25,8 @@ This topic provides a roadmap for planning and getting started on the Device Gua 3. **Review how much variety in software and hardware is needed by roles or departments**. When several departments all use the same hardware and software, you might need to deploy only one code integrity policy for them. More variety across departments might mean you need to create and manage more code integrity policies. The following questions can help you clarify how many code integrity policies to create: - How standardized is the hardware?
This can be relevant because of drivers. You could create a code integrity policy on hardware that uses a particular set of drivers, and if other drivers in your environment use the same signature, they would also be allowed to run. However, you might need to create several code integrity policies on different "reference" hardware, then merge the policies together, to ensure that the resulting policy recognizes all the drivers in your environment. - - Is there already a list of accepted applications?
A list of accepted applications can be used to help create a baseline code integrity policy. - + - Is there already a list of accepted applications?
A list of accepted applications can be used to help create a baseline code integrity policy.
As of Windows 10, version 1703, it might also be useful to have a list of plug-ins, add-ins, or modules that you want to allow only in a specific app (such as a line-of-business app). Similarly, it might be useful to have a list of plug-ins, add-ins, or modules that you want to block in a specific app (such as a browser). + - What software does each department or role need? Should they be able to install and run other departments’ software?
If multiple departments are allowed to run the same list of software, you might be able to merge several code integrity policies to simplify management. - Are there departments or roles where unique, restricted software is used?
If one department needs to run an application that no other department is allowed, it might require a separate code integrity policy. Similarly, if only one department must run an old version of an application (while other departments allow only the newer version), it might require a separate code integrity policy.