mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-12 21:37:22 +00:00
Revert "Edits to block list process steps document."
This commit is contained in:
Elizabeth Ross
GitHub
parent
8325d7c39e
commit
3a1e19b50b
@ -20,473 +20,7 @@ For an overview of the process described in the following procedures, see [Deplo
|
||||
|
||||
The process for creating a golden code integrity policy from a reference system is straightforward. This section outlines the process that is required to successfully create a code integrity policy with Windows PowerShell. First, for this example, you must initiate variables to be used during the creation process. Rather than using variables, you can simply use the full file paths in the command. Next, you create the code integrity policy by scanning the system for installed applications. When created, the policy file is converted to binary format so that Windows can consume its contents.
|
||||
|
||||
> [!Note]
|
||||
> Before you begin this procedure, make sure that the reference PC is virus and malware-free,and that any software you want to be scanned is installed on the system before creating the code integrity policy.
|
||||
|
||||
### Scripting and applications
|
||||
|
||||
Each installed software application should be validated as trustworthy before you create a policy. We recommend that you review the reference PC for software that can load arbitrary DLLs and run code or scripts that could render the PC more vulnerable. Examples include software aimed at development or scripting such as msbuild.exe (part of Visual Studio and the .NET Framework) which can be removed, and Windows Script Host (WSH), which can be manually disabled if you do not want it to run scripts.
|
||||
You can remove or disable such software on reference PCs used to create code integrity policies. You can also fine-tune your control by using Device Guard in combination with AppLocker, as described in [Device Guard with AppLocker](https://technet.microsoft.com/itpro/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies#device-guard-with-applocker).
|
||||
|
||||
Members of the security community<sup>*</sup> continuously collaborate with Microsoft to help protect customers. With the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also potentially use to bypass Device Guard code integrity policies.
|
||||
|
||||
In certain circumstances, if the use case is appropriate, for example if your operational scenario requires elevated security, you may want to block these applications. For example, if you have a code integrity policy that trusts all Microsoft-signed applications, we recommend that you block the following applications (optional in the case of cscript.exe and wscript.exe) from running on your systems:
|
||||
|
||||
- bash.exe
|
||||
- bginfo.exe
|
||||
- cdb.exe
|
||||
- cscript.exe<sup>1</sup>
|
||||
- csi.exe
|
||||
- dnx.exe
|
||||
- fsi.exe
|
||||
- kd.exe
|
||||
- lxssmanager.dll
|
||||
- msbuild.exe<sup>2</sup>
|
||||
- mshta.exe
|
||||
- ntsd.exe
|
||||
- rcsi.exe
|
||||
- windbg.exe
|
||||
- wscript.exe<sup>1</sup>
|
||||
|
||||
<sup>1</sup> Microsoft Windows Script Host (WSH) is an automation technology for Microsoft Windows operating systems that allows scripts to load and run. It comprises two files, wscript.exe and cscript.exe. When WSH is enabled, scripts are allowed. However, when Device Guard is enabled, the functionality of WSH scripts is restricted by default.
|
||||
|
||||
<sup>2</sup> If you are using your reference system in a development context and use msbuild.exe to build managed applications, we recommend that you whitelist msbuild.exe in your code integrity policies. However, if your reference system is an end user device that is not being used in a development context, we recommend that you block msbuild.exe.
|
||||
|
||||
<sup>*</sup> Microsoft recognizes the efforts of those in the security community who help us protect customers through responsible vulnerability disclosure, and extends thanks to the following people:
|
||||
|
||||
<br />
|
||||
|
||||
|Name|Twitter|
|
||||
|---|---|
|
||||
|Casey Smith |@subTee|
|
||||
|Matt Graeber | @mattifestation|
|
||||
|Matt Nelson | @enigma0x3|
|
||||
|Oddvar Moe |@Oddvarmoe|
|
||||
|
||||
<br />
|
||||
|
||||
>[!Note]
|
||||
>This application list is fluid and will be updated with the latest vendor information as application vulnerabilities are resolved and new issues are discovered.
|
||||
|
||||
When an application version is upgraded, you may want to add deny rules to your code integrity policies for that application’s previous, less secure versions, especially to fix a vulnerability or potential Device Guard bypass. Certain vendors may or may not intend to update their software to work with Device Guard.
|
||||
|
||||
To block the listed applications, you can merge this policy into your existing policy by adding the following deny rules using the PowerShell Merge-CIPolicy cmdlet:
|
||||
|
||||
```
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
|
||||
<VersionEx>10.0.0.0</VersionEx>
|
||||
<PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>
|
||||
<PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
|
||||
<Rules>
|
||||
<Rule>
|
||||
<Option>Enabled:Unsigned System Integrity Policy</Option>
|
||||
</Rule>
|
||||
<Rule>
|
||||
<Option>Enabled:Audit Mode</Option>
|
||||
</Rule>
|
||||
<Rule>
|
||||
<Option>Enabled:Advanced Boot Options Menu</Option>
|
||||
</Rule>
|
||||
<Rule>
|
||||
<Option>Required:Enforce Store Applications</Option>
|
||||
</Rule>
|
||||
<Rule>
|
||||
<Option>Enabled:UMCI</Option>
|
||||
</Rule>
|
||||
</Rules>
|
||||
<!--EKUS-->
|
||||
<EKUs />
|
||||
<!--File Rules-->
|
||||
<FileRules>
|
||||
<Deny ID="ID_DENY_BGINFO" FriendlyName="bginfo.exe" FileName="BGINFO.Exe" MinimumFileVersion = "4.21.0.0" />
|
||||
<Deny ID="ID_DENY_CBD" FriendlyName="cdb.exe" FileName="CDB.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_KD" FriendlyName="kd.exe" FileName="kd.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_WINDBG" FriendlyName="windbg.exe" FileName="windbg.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_MSBUILD" FriendlyName="MSBuild.exe" FileName="MSBuild.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_CSI" FriendlyName="csi.exe" FileName="csi.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_DNX" FriendlyName="dnx.exe" FileName="dnx.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_RCSI" FriendlyName="rcsi.exe" FileName="rcsi.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_NTSD" FriendlyName="ntsd.exe" FileName="ntsd.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_LXSS" FriendlyName="LxssManager.dll" FileName="LxssManager.dll" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_BASH" FriendlyName="bash.exe" FileName="bash.exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_FSI" FriendlyName="fsi.exe" FileName="fsi.exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_MSHTA" FriendlyName="mshta.exe" FileName="mshta.exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
</FileRules>
|
||||
<!--Signers-->
|
||||
<Signers />
|
||||
|
||||
<!--Driver Signing Scenarios-->
|
||||
<SigningScenarios>
|
||||
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS_1" FriendlyName="Driver Signing Scenarios">
|
||||
<ProductSigners>
|
||||
<FileRulesRef>
|
||||
<FileRuleRef RuleID="ID_DENY_KD" />
|
||||
</FileRulesRef>
|
||||
</ProductSigners>
|
||||
</SigningScenario>
|
||||
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="User Mode Signing Scenarios">
|
||||
<ProductSigners>
|
||||
<FileRulesRef>
|
||||
<FileRuleRef RuleID="ID_DENY_BGINFO"/>
|
||||
<FileRuleRef RuleID="ID_DENY_CBD"/>
|
||||
<FileRuleRef RuleID="ID_DENY_KD"/>
|
||||
<FileRuleRef RuleID="ID_DENY_WINDBG"/>
|
||||
<FileRuleRef RuleID="ID_DENY_MSBUILD"/>
|
||||
<FileRuleRef RuleID="ID_DENY_CSI"/>
|
||||
<FileRuleRef RuleID="ID_DENY_DNX"/>
|
||||
<FileRuleRef RuleID="ID_DENY_RCSI"/>
|
||||
<FileRuleRef RuleID="ID_DENY_NTSD"/>
|
||||
<FileRuleRef RuleID="ID_DENY_LXSS"/>
|
||||
<FileRuleRef RuleID="ID_DENY_BASH"/>
|
||||
<FileRuleRef RuleID="ID_DENY_FSI"/>
|
||||
<FileRuleRef RuleID="ID_DENY_MSHTA"/>
|
||||
</FileRulesRef>
|
||||
</ProductSigners>
|
||||
</SigningScenario>
|
||||
</SigningScenarios>
|
||||
<UpdatePolicySigners />
|
||||
<CiSigners />
|
||||
<HvciOptions>0</HvciOptions>
|
||||
</SiPolicy>
|
||||
|
||||
```
|
||||
|
||||
### Disable Windows Script Host
|
||||
|
||||
If you are using Device Guard code integrity policies, the policies place constraints on PowerShell and WSH scripts. When Device Guard is enabled, by default, PowerShell scripts execute in “ConstrainedLanguage” language mode, in which neither wscript.exe and cscript.exe can invoke untrusted Active X controls or COM objects. However, signed PowerShell scripts are permitted to execute in “FullLanguage” language mode, and trusted or signed wscript or cscript scripts can invoke Active X controls or COM objects. For further information on PowerShell language modes, see [Language Modes](https://msdn.microsoft.com/en-us/powershell/reference/4.0/microsoft.powershell.core/about/about_language_modes).
|
||||
|
||||
Alternatively, though script hosts are safer with Device Guard enabled, if your reference PC does not require any scripting, you may want to completely disable WSH. Disabling WSH prevents all users from running any scripts, including VBScript and JScript scripts. Note that some applications may require WSH to be enabled. You can disable WSH by configuring Device Guard code integrity policies.
|
||||
|
||||
### Disable Windows Script Host using code integrity policies
|
||||
|
||||
To disable Windows Script Hosting, you can simply create further deny rules to add the script hosts (wscript.exe and cscript.exe) to the list of blocked applications in your code integrity policy as follows:
|
||||
```
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy" FriendlyName="Windows Recommended Deny List Policy">
|
||||
<VersionEx>1.0.0.0</VersionEx>
|
||||
<PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>
|
||||
<PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
|
||||
<Rules>
|
||||
<Rule>
|
||||
<Option>Enabled:Unsigned System Integrity Policy</Option>
|
||||
</Rule>
|
||||
<Rule>
|
||||
<Option>Enabled:Advanced Boot Options Menu</Option>
|
||||
</Rule>
|
||||
<Rule>
|
||||
<Option>Required:Enforce Store Applications</Option>
|
||||
</Rule>
|
||||
<Rule>
|
||||
<Option>Enabled:UMCI</Option>
|
||||
</Rule>
|
||||
</Rules>
|
||||
|
||||
<!--EKUS-->
|
||||
<EKUs />
|
||||
|
||||
<!--File Rules-->
|
||||
<FileRules>
|
||||
<Deny ID="ID_DENY_BGINFO" FriendlyName="bginfo.exe" FileName="BGINFO.Exe" MinimumFileVersion = "4.21.0.0” />
|
||||
<Deny ID="ID_DENY_CBD" FriendlyName="cdb.exe" FileName="CDB.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_KD" FriendlyName="kd.exe" FileName="kd.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_WINDBG" FriendlyName="windbg.exe" FileName="windbg.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_MSBUILD" FriendlyName="MSBuild.exe" FileName="MSBuild.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_WSCRIPT" FriendlyName="wscript.exe" FileName="wscript.exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_CSCRIPT" FriendlyName="cscript.exe" FileName="cscript.exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_CSI" FriendlyName="csi.exe" FileName="csi.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_DNX" FriendlyName="dnx.exe" FileName="dnx.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_RCSI" FriendlyName="rcsi.exe" FileName="rcsi.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_NTSD" FriendlyName="ntsd.exe" FileName="ntsd.Exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_LXSS" FriendlyName="LxssManager.dll" FileName="LxssManager.dll" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_BASH" FriendlyName="bash.exe" FileName="bash.exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_FSI" FriendlyName="fsi.exe" FileName="fsi.exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
<Deny ID="ID_DENY_MSHTA" FriendlyName="mshta.exe" FileName="mshta.exe" MinimumFileVersion = "65535.65535.65535.65535" />
|
||||
</FileRules>
|
||||
|
||||
<!--Signers-->
|
||||
<Signers>
|
||||
|
||||
</Signers>
|
||||
|
||||
<SigningScenarios>
|
||||
<!--Kernel Mode Signing Scenario-->
|
||||
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_KMCI" FriendlyName="Kernel Mode Signing Scenario">
|
||||
<ProductSigners />
|
||||
</SigningScenario>
|
||||
|
||||
<!--User Mode Signing Scenario-->
|
||||
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_UMCI" FriendlyName="User Mode Signing Scenario">
|
||||
<ProductSigners>
|
||||
|
||||
<FileRulesRef>
|
||||
<FileRuleRef RuleID="ID_DENY_BGINFO"/>
|
||||
<FileRuleRef RuleID="ID_DENY_CBD"/>
|
||||
<FileRuleRef RuleID="ID_DENY_KD"/>
|
||||
<FileRuleRef RuleID="ID_DENY_WINDBG"/>
|
||||
<FileRuleRef RuleID="ID_DENY_MSBUILD"/>
|
||||
<FileRuleRef RuleID="ID_DENY_WSCRIPT"/>
|
||||
<FileRuleRef RuleID="ID_DENY_CSCRIPT"/>
|
||||
<FileRuleRef RuleID="ID_DENY_CSI"/>
|
||||
<FileRuleRef RuleID="ID_DENY_DNX"/>
|
||||
<FileRuleRef RuleID="ID_DENY_RCSI"/>
|
||||
<FileRuleRef RuleID="ID_DENY_NTSD"/>
|
||||
<FileRuleRef RuleID="ID_DENY_LXSS"/>
|
||||
<FileRuleRef RuleID="ID_DENY_BASH"/>
|
||||
<FileRuleRef RuleID="ID_DENY_FSI"/>
|
||||
<FileRuleRef RuleID="ID_DENY_MSHTA"/>
|
||||
</FileRulesRef>
|
||||
|
||||
</ProductSigners>
|
||||
</SigningScenario>
|
||||
</SigningScenarios>
|
||||
|
||||
<UpdatePolicySigners />
|
||||
|
||||
<CiSigners />
|
||||
|
||||
</SiPolicy>
|
||||
|
||||
```
|
||||
<br />
|
||||
The June 2017 Windows updates resolve a vulnerability in PowerShell that allowed an attacker to bypass Device Guard code integrity policies. Powershell cmdlets cannot be blocked by name or version, and therefore must be blocked by their corresponding hashes. We recommend that you block the following PowerShell cmdlets and merge this policy into your existing policy by adding the following deny rules using the Merge-CIPolicy cmdlet:
|
||||
|
||||
```
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
|
||||
<VersionEx>10.0.0.0</VersionEx>
|
||||
<PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>
|
||||
<PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
|
||||
<Rules>
|
||||
<Rule>
|
||||
<Option>Enabled:Unsigned System Integrity Policy</Option>
|
||||
</Rule>
|
||||
<Rule>
|
||||
<Option>Enabled:Audit Mode</Option>
|
||||
</Rule>
|
||||
<Rule>
|
||||
<Option>Enabled:Advanced Boot Options Menu</Option>
|
||||
</Rule>
|
||||
<Rule>
|
||||
<Option>Required:Enforce Store Applications</Option>
|
||||
</Rule>
|
||||
<Rule>
|
||||
<Option>Enabled:UMCI</Option>
|
||||
</Rule>
|
||||
</Rules>
|
||||
<!--EKUS-->
|
||||
<EKUs />
|
||||
<!--File Rules-->
|
||||
<FileRules>
|
||||
<Deny ID="ID_DENY_D_0" FriendlyName="Powershell 0" Hash="1AC4D8D8B672A2D74AB1815E8A3FEF6952892D1E" />
|
||||
<Deny ID="ID_DENY_D_1" FriendlyName="Powershell 1" Hash="25C57E0305E7FFB4C259D741B87F90D66BDA9801AE68A0F589D9F15D95C15821" />
|
||||
<Deny ID="ID_DENY_D_2" FriendlyName="Powershell 2" Hash="AA085BE6498D2E3F527F3D72A5D1C604508133F0CDC05AD404BB49E8E3FB1A1B" />
|
||||
<Deny ID="ID_DENY_D_3" FriendlyName="Powershell 3" Hash="573129BCCA3C8492498C35E45676B3D348438464" />
|
||||
<Deny ID="ID_DENY_D_4" FriendlyName="Powershell 4" Hash="FBA274406B503B464B349805149E6AA722909CC9" />
|
||||
<Deny ID="ID_DENY_D_5" FriendlyName="Powershell 5" Hash="91459EF46223540305C42FD50DF0B3C62148A0DB70F6B588AB29D11C5750F784" />
|
||||
<Deny ID="ID_DENY_D_6" FriendlyName="Powershell 6" Hash="BACA825D0852E2D8F3D92381D112B99B5DD56D9F" />
|
||||
<Deny ID="ID_DENY_D_7" FriendlyName="Powershell 7" Hash="3AF2587E8B62F88DC363D7F5308EE4C1A6147338" />
|
||||
<Deny ID="ID_DENY_D_8" FriendlyName="Powershell 8" Hash="A9E655A96A124BC361D9CC5C7663FC033AA6F6609916EFAA76B6A6E9713A0D32" />
|
||||
<Deny ID="ID_DENY_D_9" FriendlyName="Powershell 9" Hash="8BC6761CDB3A2114DC04B3167C27CD9A8D3F8F08" />
|
||||
<Deny ID="ID_DENY_D_10" FriendlyName="Powershell 10" Hash="11F936112832738AD9B3A1C67537D5542DE8E86856CF2A5893C4D26CF3A2C558" />
|
||||
<Deny ID="ID_DENY_D_11" FriendlyName="Powershell 11" Hash="7DBB41B87FAA887DE456C8E6A72E09D2839FA1E7" />
|
||||
<Deny ID="ID_DENY_D_12" FriendlyName="Powershell 12" Hash="632CC37793AC704329C943765A684F9D22DBE50A1D951CAA576E72613F4BFC82" />
|
||||
<Deny ID="ID_DENY_D_13" FriendlyName="Powershell 13" Hash="FA2F82EAAE3E9F04E7ABCBF3BEA5403F3D7D67CE" />
|
||||
<Deny ID="ID_DENY_D_14" FriendlyName="Powershell 14" Hash="55A114886D75A8CAD1B8B8A867D42384CF6E337E" />
|
||||
<Deny ID="ID_DENY_D_15" FriendlyName="Powershell 15" Hash="DED853481A176999723413685A79B36DD0F120F9" />
|
||||
<Deny ID="ID_DENY_D_16" FriendlyName="Powershell 16" Hash="D027E09D9D9828A87701288EFC91D240C0DEC2C3" />
|
||||
<Deny ID="ID_DENY_D_17" FriendlyName="Powershell 17" Hash="46936F4F0AFE4C87D2E55595F74DDDFFC9AD94EE" />
|
||||
<Deny ID="ID_DENY_D_18" FriendlyName="Powershell 18" Hash="5090F22BB9C0B168C7F5E9E800784A05AFCCBC4F" />
|
||||
<Deny ID="ID_DENY_D_19" FriendlyName="Powershell 19" Hash="A920D0706FCEA648D28638E9198BCC368996B8FD" />
|
||||
<Deny ID="ID_DENY_D_20" FriendlyName="Powershell 20" Hash="93E22F2BA6C8B1C09F100F9C0E3B06FAF2D1DDB6" />
|
||||
<Deny ID="ID_DENY_D_21" FriendlyName="Powershell 21" Hash="943E307BE7B0B381715CA5CC0FAB7B558025BA80" />
|
||||
<Deny ID="ID_DENY_D_22" FriendlyName="Powershell 22" Hash="DDE4D9A08514347CDE706C42920F43523FC74DEA" />
|
||||
<Deny ID="ID_DENY_D_23" FriendlyName="Powershell 23" Hash="48092864C96C4BF9B68B5006EAEDAB8B57B3738C" />
|
||||
<Deny ID="ID_DENY_D_24" FriendlyName="Powershell 24" Hash="7F6725BA8CCD2DAEEFD0C9590A5DF9D98642CCEA" />
|
||||
<Deny ID="ID_DENY_D_25" FriendlyName="Powershell 25" Hash="AEBFE7497F4A1947B5CB32650843CA0F85BD56D0" />
|
||||
<Deny ID="ID_DENY_D_26" FriendlyName="Powershell 26" Hash="8FB604CD72701B83BC265D87F52B36C6F14E5DBE" />
|
||||
<Deny ID="ID_DENY_D_27" FriendlyName="Powershell 27" Hash="CE70309DB83C9202F45028EBEC252747F4936E6F" />
|
||||
<Deny ID="ID_DENY_D_28" FriendlyName="Powershell 28" Hash="DE6A02520E1D7325025F2761A97D36E407E8490C" />
|
||||
<Deny ID="ID_DENY_D_29" FriendlyName="Powershell 29" Hash="B663138BF1D91C74EB25C68378B3E68E3F9E936A" />
|
||||
<Deny ID="ID_DENY_D_30" FriendlyName="Powershell 30" Hash="79D5991CF1ED52C7E6AE7F5FDE3F0D9240BE62F3" />
|
||||
<Deny ID="ID_DENY_D_31" FriendlyName="Powershell 31" Hash="9D71AD914DBB2FDF793742AA63AEEF4E4A430790" />
|
||||
<Deny ID="ID_DENY_D_32" FriendlyName="Powershell 32" Hash="7484FD78A9298DBA24AC5C882D16DB6146E53712" />
|
||||
<Deny ID="ID_DENY_D_33" FriendlyName="Powershell 33" Hash="CE2DAA6B3E9F5DF9216F2060AFB48B7558033B66" />
|
||||
<Deny ID="ID_DENY_D_34" FriendlyName="Powershell 34" Hash="4C4847F430305B8BF755EB09F02F3DD229F6BC2D" />
|
||||
<Deny ID="ID_DENY_D_35" FriendlyName="Powershell 35" Hash="CC968868EDC6718DA14DDDB11228A04D5D5BD9A5" />
|
||||
<Deny ID="ID_DENY_D_36" FriendlyName="Powershell 36" Hash="78C3C6AEF52A6A5392C55F1EC98AF18053B3087D" />
|
||||
<Deny ID="ID_DENY_D_37" FriendlyName="Powershell 37" Hash="783FFB771F08BCF55C2EA474B5460EB65EA9444C" />
|
||||
<Deny ID="ID_DENY_D_38" FriendlyName="Powershell 38" Hash="7386F0FFAEED9F14CB087719A82633CE341AF18C" />
|
||||
<Deny ID="ID_DENY_D_39" FriendlyName="Powershell 39" Hash="D60BC43CAD0E2CD119F0F29BA3E85EDA6B6409B0" />
|
||||
<Deny ID="ID_DENY_D_40" FriendlyName="Powershell 40" Hash="B303D1689ED99613E4F52CE6E5F96AAEBC3A45C3" />
|
||||
<Deny ID="ID_DENY_D_41" FriendlyName="Powershell 41" Hash="DB5C6CB23C23BA6A3CD4FD4EC0A4DAEE3FC66500" />
|
||||
<Deny ID="ID_DENY_D_42" FriendlyName="Powershell 42" Hash="24F46E8804F5411A1EBE7CE8454AF87C7E93A310" />
|
||||
<Deny ID="ID_DENY_D_43" FriendlyName="Powershell 43" Hash="1194192ECDA6751D8261F17A491618E707152DA6" />
|
||||
<Deny ID="ID_DENY_D_44" FriendlyName="Powershell 44" Hash="789D0657689DB6F0900A787BEF52A449585A92B5" />
|
||||
<Deny ID="ID_DENY_D_45" FriendlyName="Powershell 45" Hash="C1E08AD32F680100C51F138C6C095139E7230C3B" />
|
||||
<Deny ID="ID_DENY_D_46" FriendlyName="Powershell 46" Hash="E89C29D38F554F6CB73B5FD3D0A783CC12FFEBC3" />
|
||||
<Deny ID="ID_DENY_D_47" FriendlyName="Powershell 47" Hash="AF37DB4C03EFB0AADB9A670FF9A656AEF8D92A2F" />
|
||||
<Deny ID="ID_DENY_D_48" FriendlyName="Powershell 48" Hash="7749D36155F967D01ED610C777F1B3AF9F6C225B" />
|
||||
<Deny ID="ID_DENY_D_49" FriendlyName="Powershell 49" Hash="5B5E7942233D7C8A325A429FC4F4AE281325E8F9" />
|
||||
<Deny ID="ID_DENY_D_50" FriendlyName="Powershell 50" Hash="926DCACC6983F85A8ABBCB5EE13F3C756705A1D5" />
|
||||
<Deny ID="ID_DENY_D_51" FriendlyName="Powershell 51" Hash="395ACEC4E5123A3EF2C5E88620F827E929CF6D32" />
|
||||
<Deny ID="ID_DENY_D_52" FriendlyName="Powershell 52" Hash="55A9B372FF02D16127AD7D5A9C32FC666D6397ED" />
|
||||
<Deny ID="ID_DENY_D_53" FriendlyName="Powershell 53" Hash="6FE6723A355DEB4BC6B8637A634D1B43AFA64112" />
|
||||
<Deny ID="ID_DENY_D_54" FriendlyName="Powershell 54" Hash="8D5599B34BED4A660DACC0922F6C2F112F264758" />
|
||||
<Deny ID="ID_DENY_D_55" FriendlyName="Powershell 55" Hash="F139A9B69295C115BDDA030ABD50354ACF90B4A6" />
|
||||
<Deny ID="ID_DENY_D_56" FriendlyName="Powershell 56" Hash="C10A9A496BAE83272BC7257BB11E15487A51F1B6" />
|
||||
<Deny ID="ID_DENY_D_57" FriendlyName="Powershell 57" Hash="CCFB247A3BCA9C64D82F647F3D30A3172E645F13" />
|
||||
<Deny ID="ID_DENY_D_58" FriendlyName="Powershell 58" Hash="E8EB859531F426CC45A3CB9118F399C92054563E" />
|
||||
<Deny ID="ID_DENY_D_59" FriendlyName="Powershell 59" Hash="3AE6766D1877340EA7F6DB1A4900501C794C3FC5" />
|
||||
<Deny ID="ID_DENY_D_60" FriendlyName="Powershell 60" Hash="7E9AE4038C626FC16C52F95F15A86B3A4183F172" />
|
||||
<Deny ID="ID_DENY_D_61" FriendlyName="Powershell 61" Hash="C92D4EAC917EE4842A437C54F96D87F003199DE8" />
|
||||
<Deny ID="ID_DENY_D_62" FriendlyName="Powershell 62" Hash="66681D9171981216B31996429695931DA2A638B9" />
|
||||
<Deny ID="ID_DENY_D_63" FriendlyName="Powershell 63" Hash="98A3F280667CE1F36AAF68B4336F2C2031002791" />
|
||||
<Deny ID="ID_DENY_D_64" FriendlyName="Powershell 64" Hash="054BBA5AB35A3F704D62F3119CD8B8C3CBD7AEEB" />
|
||||
<Deny ID="ID_DENY_D_65" FriendlyName="Powershell 65" Hash="9DCA54C85E4C645CB296FE3055E90255B6506A95" />
|
||||
<Deny ID="ID_DENY_D_66" FriendlyName="Powershell 66" Hash="D3D453EBC368DF7CC2200474035E5898B58D93F1" />
|
||||
<Deny ID="ID_DENY_D_67" FriendlyName="Powershell 67" Hash="F29A958287788A6EEDE6035D49EF5CB85EEC40D214FDDE5A0C6CAA65AFC00EEC" />
|
||||
<Deny ID="ID_DENY_D_68" FriendlyName="Powershell 68" Hash="84BB081141DA50B3839CD275FF34854F53AECB96CA9AEB8BCD24355C33C1E73E" />
|
||||
<Deny ID="ID_DENY_D_69" FriendlyName="Powershell 69" Hash="8D396FEAEED1F0CA709B62B1F27EDC9CCEFF95E3473C923624362A042E91D787" />
|
||||
<Deny ID="ID_DENY_D_70" FriendlyName="Powershell 70" Hash="7BF44433D3A606104778F64B11B92C52FC99C4BA570C50B70438275D0B587B8E" />
|
||||
<Deny ID="ID_DENY_D_71" FriendlyName="Powershell 71" Hash="6B3CB996EC5129D345830C3D6D5C7C009372FFD9F08837E8B2572AB31E9648A5" />
|
||||
<Deny ID="ID_DENY_D_72" FriendlyName="Powershell 72" Hash="C3A5DAB20947CA8FD092E75C25177E7BAE7884CA58710F14827144C09EA1F94B" />
|
||||
<Deny ID="ID_DENY_D_73" FriendlyName="Powershell 73" Hash="BE3FFE10CDE8B62C3E8FD4D8198F272B6BD15364A33362BB07A0AFF6731DABA1" />
|
||||
<Deny ID="ID_DENY_D_74" FriendlyName="Powershell 74" Hash="75288A0CF0806A68D8DA721538E64038D755BBE74B52F4B63FEE5049AE868AC0" />
|
||||
<Deny ID="ID_DENY_D_75" FriendlyName="Powershell 75" Hash="F875E43E12685ECE0BA2D42D55A13798CE9F1FFDE3CAE253D2529F4304811A52" />
|
||||
<Deny ID="ID_DENY_D_76" FriendlyName="Powershell 76" Hash="6D89FDD29D50C07801FB01F031CDB96E2E14288F066BD895356AE0517ABB09CE" />
|
||||
<Deny ID="ID_DENY_D_77" FriendlyName="Powershell 77" Hash="326669C4A31E2049E3750BCF4287241BB8B555B3670D31A1ACA74C3AC598DF81" />
|
||||
<Deny ID="ID_DENY_D_78" FriendlyName="Powershell 78" Hash="38DC1956313B160696A172074C6F5DA9852BF508F55AFB7FA079B98F2849AFB5" />
|
||||
<Deny ID="ID_DENY_D_79" FriendlyName="Powershell 79" Hash="C6C073A80A8E76DC13E724B5E66FE4035A19CCA0C1AF3FABBC18E5185D1B66CB" />
|
||||
<Deny ID="ID_DENY_D_80" FriendlyName="Powershell 80" Hash="9EA4BD3D8FB8F490E8099E0412F091E545AF028E3C4CAF179324B679124D1742" />
|
||||
<Deny ID="ID_DENY_D_81" FriendlyName="Powershell 81" Hash="CD83C3C293EC4D24D3328C74881FA04AAF9CCF73E099631A9EB100BD0F384F58" />
|
||||
<Deny ID="ID_DENY_D_82" FriendlyName="Powershell 82" Hash="74E207F539C4EAC648A5507EB158AEE9F6EA401E51808E83E73709CFA0820FDD" />
|
||||
<Deny ID="ID_DENY_D_83" FriendlyName="Powershell 83" Hash="148972F670E18790D62D753E01ED8D22B351A57E45544D88ACE380FEDAF24A40" />
|
||||
<Deny ID="ID_DENY_D_84" FriendlyName="Powershell 84" Hash="72E4EC687CFE357F3E681A7500B6FF009717A2E9538956908D3B52B9C865C189" />
|
||||
<Deny ID="ID_DENY_D_85" FriendlyName="Powershell 85" Hash="F16E605B55774CDFFDB0EB99FAFF43A40622ED2AB1C011D1195878F4B20030BC" />
|
||||
<Deny ID="ID_DENY_D_86" FriendlyName="Powershell 86" Hash="BD3139CE7553AC7003C96304F08EAEC2CDB2CC6A869D36D6F1E478DA02D3AA16" />
|
||||
<Deny ID="ID_DENY_D_87" FriendlyName="Powershell 87" Hash="71FC552E66327EDAA72D72C362846BD80CB65EECFAE95C4D790C9A2330D95EE6" />
|
||||
<Deny ID="ID_DENY_D_88" FriendlyName="Powershell 88" Hash="A1D1AF7675C2596D0DF977F57B54372298A56EE0F3E1FF2D974D387D7F69DD4E" />
|
||||
<Deny ID="ID_DENY_D_89" FriendlyName="Powershell 89" Hash="0D905709AB1174F8E12A063F259A52DABE85CAEB8018985F5411F1CE9C6C99C3" />
|
||||
<Deny ID="ID_DENY_D_90" FriendlyName="Powershell 90" Hash="939C291D4A2592209EC7664EC832670FA0AC1009F974F47489D866751F4B862F" />
|
||||
</FileRules>
|
||||
<!--Signers-->
|
||||
<Signers />
|
||||
|
||||
<!--Driver Signing Scenarios-->
|
||||
<SigningScenarios>
|
||||
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS_1" FriendlyName="Auto generated policy on 06-12-2017">
|
||||
<ProductSigners>
|
||||
<FileRulesRef>
|
||||
<FileRuleRef RuleID="ID_DENY_D_11" />
|
||||
</FileRulesRef>
|
||||
</ProductSigners>
|
||||
</SigningScenario>
|
||||
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="Auto generated policy on 06-12-2017">
|
||||
<ProductSigners>
|
||||
<FileRulesRef>
|
||||
<FileRuleRef RuleID="ID_DENY_D_0" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_1" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_2" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_3" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_4" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_5" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_6" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_7" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_8" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_9" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_10" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_11" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_12" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_13" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_14" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_15" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_16" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_17" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_18" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_19" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_20" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_21" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_22" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_23" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_24" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_25" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_26" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_27" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_28" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_29" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_30" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_31" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_32" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_33" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_34" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_35" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_36" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_37" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_38" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_39" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_40" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_41" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_42" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_43" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_44" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_45" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_46" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_47" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_48" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_49" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_50" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_51" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_52" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_53" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_54" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_55" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_56" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_57" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_58" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_59" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_60" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_61" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_62" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_63" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_64" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_65" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_66" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_67" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_68" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_69" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_70" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_71" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_72" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_73" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_74" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_75" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_76" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_77" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_78" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_79" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_80" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_81" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_82" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_83" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_84" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_85" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_86" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_87" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_88" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_89" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_90" />
|
||||
</FileRulesRef>
|
||||
</ProductSigners>
|
||||
</SigningScenario>
|
||||
</SigningScenarios>
|
||||
<UpdatePolicySigners />
|
||||
<CiSigners />
|
||||
<HvciOptions>0</HvciOptions>
|
||||
</SiPolicy>
|
||||
|
||||
```
|
||||
<br />
|
||||
> **Note** Before you begin this procedure, ensure that the reference PC is clean of viruses or malware. Each piece of installed software should be validated as trustworthy before you create this policy. Also, be sure that any software that you would like to be scanned is installed on the system before you create the code integrity policy.
|
||||
|
||||
To create a code integrity policy, copy each of the following commands into an elevated Windows PowerShell session, in order:
|
||||
|
||||
@ -502,7 +36,7 @@ To create a code integrity policy, copy each of the following commands into an e
|
||||
|
||||
` New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy –UserPEs 3> CIPolicyLog.txt `
|
||||
|
||||
> [!Notes]
|
||||
> **Notes**
|
||||
|
||||
> - 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.
|
||||
|
||||
@ -518,8 +52,7 @@ To create a code integrity policy, copy each of the following commands into an e
|
||||
|
||||
After you complete these steps, the Device Guard binary file (DeviceGuardPolicy.bin) and original .xml file (IntialScan.xml) will be available on your desktop. You can use the binary version as a code integrity policy or sign it for additional security.
|
||||
|
||||
> [!Note]
|
||||
> We recommend that you keep the original .xml file of the policy for use when you need to merge the code integrity policy with another policy or update its rule options. Alternatively, you would have to create a new policy from a new scan for servicing. For more information about how to merge code integrity policies, see [Merge code integrity policies](#merge-code-integrity-policies).
|
||||
> **Note** We recommend that you keep the original .xml file of the policy for use when you need to merge the code integrity policy with another policy or update its rule options. Alternatively, you would have to create a new policy from a new scan for servicing. For more information about how to merge code integrity policies, see [Merge code integrity policies](#merge-code-integrity-policies).
|
||||
|
||||
We recommend that every code integrity policy be run in audit mode before being enforced. Doing so allows administrators to discover any issues with the policy without receiving error message dialog boxes. For information about how to audit a code integrity policy, see the next section, [Audit code integrity policies](#audit-code-integrity-policies).
|
||||
|
||||
@ -527,8 +60,7 @@ We recommend that every code integrity policy be run in audit mode before being
|
||||
|
||||
When code integrity policies are run in audit mode, it allows administrators to discover any applications that were missed during an initial policy scan and to identify any new applications that have been installed and run since the original policy was created. While a code integrity policy is running in audit mode, any binary that runs and would have been denied had the policy been enforced is logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log. When these logged binaries have been validated, they can easily be added to a new code integrity policy. When the new exception policy is created, you can merge it with your existing code integrity policies.
|
||||
|
||||
> [!Note]
|
||||
> Before you begin this process, you need to create a code integrity policy binary file. If you have not already done so, see [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer), earlier in this topic, for a step-by-step walkthrough of the process to create a code integrity policy and convert it to binary format.
|
||||
> **Note** Before you begin this process, you need to create a code integrity policy binary file. If you have not already done so, see [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer), earlier in this topic, for a step-by-step walkthrough of the process to create a code integrity policy and convert it to binary format.
|
||||
|
||||
**To audit a code integrity policy with local policy:**
|
||||
|
||||
@ -536,7 +68,7 @@ When code integrity policies are run in audit mode, it allows administrators to
|
||||
|
||||
2. On the computer you want to run in audit mode, open the Local Group Policy Editor by running **GPEdit.msc**.
|
||||
|
||||
> [!Note]
|
||||
> **Notes**
|
||||
|
||||
> - The computer that you will run in audit mode must be clean of viruses or malware. Otherwise, in the process that you follow after auditing the system, you might unintentionally merge in a code integrity policy that allows viruses or malware to run.
|
||||
|
||||
@ -544,7 +76,7 @@ When code integrity policies are run in audit mode, it allows administrators to
|
||||
|
||||
3. Navigate to **Computer Configuration\\Administrative Templates\\System\\Device Guard**, and then select **Deploy Code Integrity Policy**. Enable this setting by using the appropriate file path, for example, C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 1.
|
||||
|
||||
> [!Note]
|
||||
> **Notes**
|
||||
|
||||
> - The illustration shows the example file name *DeviceGuardPolicy.bin* because this name was used earlier in this topic, in [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer). Also, this policy file does not need to be copied to every system. You can instead copy the code integrity policies to a file share to which all computer accounts have access.
|
||||
|
||||
@ -592,8 +124,7 @@ Use the following procedure after you have been running a computer with a code i
|
||||
|
||||
` New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt`
|
||||
|
||||
> [!Note]
|
||||
> When you create policies from audit events, you should carefully consider the file rule level that you select to trust. The preceding example uses the **Hash** rule level, which is the most specific. Any change to the file (such as replacing the file with a newer version of the same file) will change the Hash value, and require an update to the policy.
|
||||
> **Note** When you create policies from audit events, you should carefully consider the file rule level that you select to trust. The preceding example uses the **Hash** rule level, which is the most specific. Any change to the file (such as replacing the file with a newer version of the same file) will change the Hash value, and require an update to the policy.
|
||||
|
||||
4. Find and review the Device Guard audit policy .xml file that you created. If you used the example variables as shown, the filename will be **DeviceGuardAuditPolicy.xml**, and it will be on your desktop. Look for the following:
|
||||
|
||||
@ -603,8 +134,7 @@ Use the following procedure after you have been running a computer with a code i
|
||||
|
||||
You can now use this file to update the existing code integrity policy that you ran in audit mode by merging the two policies. For instructions on how to merge this audit policy with the existing code integrity policy, see the next section, [Merge code integrity policies](#merge-code-integrity-policies).
|
||||
|
||||
> [!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.
|
||||
> **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.
|
||||
|
||||
## <a href="" id="plug-ins"></a>Use a code integrity policy to control specific plug-ins, add-ins, and modules
|
||||
|
||||
@ -636,8 +166,7 @@ New-CIPolicy -Rules $rule -FilePath ".\BlockAddins.xml" -UserPEs
|
||||
|
||||
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 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.
|
||||
> **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:
|
||||
|
||||
@ -653,8 +182,7 @@ To merge two code integrity policies, complete the following steps in an elevate
|
||||
|
||||
` $CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"`
|
||||
|
||||
> [!Note]
|
||||
> The variables in this section specifically expect to find an initial policy on your desktop called **InitialScan.xml** and an audit code integrity policy called **DeviceGuardAuditPolicy.xml**. If you want to merge other code integrity policies, update the variables accordingly.
|
||||
> **Note** The variables in this section specifically expect to find an initial policy on your desktop called **InitialScan.xml** and an audit code integrity policy called **DeviceGuardAuditPolicy.xml**. If you want to merge other code integrity policies, update the variables accordingly.
|
||||
|
||||
2. Use [Merge-CIPolicy](https://technet.microsoft.com/library/mt634485.aspx) to merge two policies and create a new code integrity policy:
|
||||
|
||||
@ -670,8 +198,7 @@ Now that you have created a new code integrity policy (for example, called **New
|
||||
|
||||
Every code integrity policy is created with audit mode enabled. After you have successfully deployed and tested a code integrity policy in audit mode and are ready to test the policy in enforced mode, complete the following steps in an elevated Windows PowerShell session:
|
||||
|
||||
> [!Note]
|
||||
> Every code integrity policy should be tested in audit mode first. For information about how to audit code integrity policies, see [Audit code integrity policies](#audit-code-integrity-policies), earlier in this topic.
|
||||
> **Note** Every code integrity policy should be tested in audit mode first. For information about how to audit code integrity policies, see [Audit code integrity policies](#audit-code-integrity-policies), earlier in this topic.
|
||||
|
||||
1. Initialize the variables that will be used:
|
||||
|
||||
@ -683,8 +210,7 @@ Every code integrity policy is created with audit mode enabled. After you have s
|
||||
|
||||
` $CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"`
|
||||
|
||||
> [!Note]
|
||||
> The initial code integrity policy that this section refers to was created in the [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer) section. If you are using a different code integrity policy, update the **CIPolicyPath** and **InitialCIPolicy** variables.
|
||||
> **Note** The initial code integrity policy that this section refers to was created in the [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer) section. If you are using a different code integrity policy, update the **CIPolicyPath** and **InitialCIPolicy** variables.
|
||||
|
||||
2. Ensure that rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) are set the way that you intend for this policy. We strongly recommend that you enable these rule options before you run any enforced policy for the first time. Enabling these options provides administrators with a pre-boot command prompt, and allows Windows to start even if the code integrity policy blocks a kernel-mode driver from running. When ready for enterprise deployment, you can remove these options.
|
||||
|
||||
@ -702,8 +228,7 @@ Every code integrity policy is created with audit mode enabled. After you have s
|
||||
|
||||
` Set-RuleOption -FilePath $EnforcedCIPolicy -Option 3 -Delete`
|
||||
|
||||
> [!Note]
|
||||
> To enforce a code integrity policy, you delete option 3, the **Audit Mode Enabled** option. There is no “enforced” option that can be placed in a code integrity policy.
|
||||
> **Note** To enforce a code integrity policy, you delete option 3, the **Audit Mode Enabled** option. There is no “enforced” option that can be placed in a code integrity policy.
|
||||
|
||||
5. Use [ConvertFrom-CIPolicy](https://technet.microsoft.com/library/mt733073.aspx) to convert the new code integrity policy to binary format:
|
||||
|
||||
@ -719,8 +244,7 @@ Signing code integrity policies by using an on-premises CA-generated certificate
|
||||
|
||||
Before signing code integrity policies for the first time, be sure to enable rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath <PathAndFilename> -Option 9` even if you're not sure whether the option is already enabled—if so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Code integrity policy rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md#code-integrity-policy-rules) in "Deploy code integrity policies: policy rules and file rules."
|
||||
|
||||
> [!Note]
|
||||
> Signing code integrity policies is the last step in a code integrity deployment. It is much more difficult to remove a signed code integrity policy than an unsigned one. Before you deploy a signed code integrity policy to deployed client computers, be sure to test its effect on a subset of computers.
|
||||
> **Note** Signing code integrity policies is the last step in a code integrity deployment. It is much more difficult to remove a signed code integrity policy than an unsigned one. Before you deploy a signed code integrity policy to deployed client computers, be sure to test its effect on a subset of computers.
|
||||
|
||||
To sign a code integrity policy with SignTool.exe, you need the following components:
|
||||
|
||||
@ -740,8 +264,7 @@ If you do not have a code signing certificate, see the [Optional: Create a code
|
||||
|
||||
` $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
|
||||
|
||||
> [!Note]
|
||||
> This example uses the code integrity policy that you created in the [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer) section. If you are signing another policy, be sure to update the **$CIPolicyPath** and **$CIPolicyBin** variables with the correct information.
|
||||
> **Note** This example uses the code integrity policy that you created in the [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer) section. If you are signing another policy, be sure to update the **$CIPolicyPath** and **$CIPolicyBin** variables with the correct information.
|
||||
|
||||
2. Import the .pfx code signing certificate. Import the code signing certificate that you will use to sign the code integrity policy into the signing user’s personal store on the computer that will be doing the signing. In this example, you use the certificate that was created in [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md).
|
||||
|
||||
@ -755,9 +278,9 @@ If you do not have a code signing certificate, see the [Optional: Create a code
|
||||
|
||||
` Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update`
|
||||
|
||||
> [!Note]
|
||||
> *<Path to exported .cer certificate>* should be the full path to the certificate that you exported in step 3.
|
||||
Also, adding update signers is crucial to being able to modify or disable this policy in the future. For more information about how to disable signed code integrity policies, see the [Disable signed code integrity policies within Windows](#disable-signed-code-integrity-policies-within-windows) section.
|
||||
> **Notes** *<Path to exported .cer certificate>* should be the full path to the certificate that you exported in step 3.
|
||||
|
||||
> Also, adding update signers is crucial to being able to modify or disable this policy in the future. For more information about how to disable signed code integrity policies, see the [Disable signed code integrity policies within Windows](#disable-signed-code-integrity-policies-within-windows) section.
|
||||
|
||||
6. Use [Set-RuleOption](https://technet.microsoft.com/library/mt634483.aspx) to remove the unsigned policy rule option:
|
||||
|
||||
@ -771,8 +294,7 @@ If you do not have a code signing certificate, see the [Optional: Create a code
|
||||
|
||||
` <Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin`
|
||||
|
||||
> [!Note]
|
||||
> The *<Path to signtool.exe>* variable should be the full path to the SignTool.exe utility. **ContosoDGSigningCert** is the subject name of the certificate that will be used to sign the code integrity policy. You should import this certificate to your personal certificate store on the computer you use to sign the policy.
|
||||
> **Note** The *<Path to signtool.exe>* variable should be the full path to the SignTool.exe utility. **ContosoDGSigningCert** is the subject name of the certificate that will be used to sign the code integrity policy. You should import this certificate to your personal certificate store on the computer you use to sign the policy.
|
||||
|
||||
9. Validate the signed file. When complete, the commands should output a signed policy file called DeviceGuardPolicy.bin.p7 to your desktop. You can deploy this file the same way you deploy an enforced or non-enforced policy. For information about how to deploy code integrity policies, see [Deploy and manage code integrity policies with Group Policy](#deploy-and-manage-code-integrity-policies-with-group-policy).
|
||||
|
||||
@ -790,8 +312,7 @@ If the code integrity policy was deployed by using Group Policy, the GPO that is
|
||||
|
||||
Signed policies protect Windows from administrative manipulation as well as malware that has gained administrative-level access to the system. For this reason, signed code integrity policies are intentionally more difficult to remove than unsigned policies. They inherently protect themselves from modification or removal and therefore are difficult even for administrators to remove successfully. If the signed code integrity policy is manually enabled and copied to the CodeIntegrity folder, to remove the policy, you must complete the following steps.
|
||||
|
||||
> [!Note]
|
||||
> For reference, signed code integrity policies should be replaced and removed from the following locations:
|
||||
> **Note** For reference, signed code integrity policies should be replaced and removed from the following locations:
|
||||
|
||||
- <EFI System Partition>\\Microsoft\\Boot\\
|
||||
|
||||
@ -842,11 +363,9 @@ There may be a time when signed code integrity policies cause a boot failure. Be
|
||||
|
||||
Code integrity policies can easily be deployed and managed with Group Policy. A Device Guard administrative template will be available in Windows Server 2016 that allows you to simplify deployment of Device Guard hardware-based security features and code integrity policies. The following procedure walks you through how to deploy a code integrity policy called **DeviceGuardPolicy.bin** to a test OU called *DG Enabled PCs* by using a GPO called **Contoso GPO Test**.
|
||||
|
||||
> [!Note]
|
||||
> This walkthrough requires that you have previously created a code integrity policy and have a computer running Windows 10 on which to test a Group Policy deployment. For more information about how to create a code integrity policy, see [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer), earlier in this topic.
|
||||
> **Note** This walkthrough requires that you have previously created a code integrity policy and have a computer running Windows 10 on which to test a Group Policy deployment. For more information about how to create a code integrity policy, see [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer), earlier in this topic.
|
||||
|
||||
> [!Note]
|
||||
> Signed code integrity policies can cause boot failures when deployed. We recommend that signed code integrity policies be thoroughly tested on each hardware platform before enterprise deployment.
|
||||
> **Note** Signed code integrity policies can cause boot failures when deployed. We recommend that signed code integrity policies be thoroughly tested on each hardware platform before enterprise deployment.
|
||||
|
||||
To deploy and manage a code integrity policy with Group Policy:
|
||||
|
||||
@ -874,15 +393,13 @@ To deploy and manage a code integrity policy with Group Policy:
|
||||
|
||||
In this policy setting, you specify either the local path in which the policy will exist on the client computer or a Universal Naming Convention (UNC) path that the client computers will look to retrieve the latest version of the policy. For example, with DeviceGuardPolicy.bin on the test computer, the example file path would be C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 5.
|
||||
|
||||
> [!Note]
|
||||
> The illustration shows the example file name *DeviceGuardPolicy.bin* because this name was used earlier in this topic, in [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer). Also, this policy file does not need to be copied to every computer. You can instead copy the code integrity policies to a file share to which all computer accounts have access. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers.
|
||||
> **Note** The illustration shows the example file name *DeviceGuardPolicy.bin* because this name was used earlier in this topic, in [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer). Also, this policy file does not need to be copied to every computer. You can instead copy the code integrity policies to a file share to which all computer accounts have access. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers.
|
||||
|
||||
|
||||
|
||||
Figure 5. Enable the code integrity policy
|
||||
|
||||
> [!Note]
|
||||
> You may have noticed that the GPO setting references a .p7b file and this example uses a .bin file for the policy. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the client computer running Windows 10. Make your code integrity policies friendly and allow the system to convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other central repository.
|
||||
> **Note** You may have noticed that the GPO setting references a .p7b file and this example uses a .bin file for the policy. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the client computer running Windows 10. Make your code integrity policies friendly and allow the system to convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other central repository.
|
||||
|
||||
7. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. Restarting the computer updates the code integrity policy. For information about how to audit code integrity policies, see the [Audit code integrity policies](#audit-code-integrity-policies) section.
|
||||
|
||||
|
||||
@ -25,21 +25,12 @@ 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?<br>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?<br>A list of accepted applications can be used to help create a baseline code integrity policy.<br>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?<br>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?<br>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.
|
||||
|
||||
- Is there already a list of accepted applications?<br>A list of accepted applications can be used to help create a baseline code integrity policy.<br>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).
|
||||
|
||||
- As part of a threat review process, have you reviewed systems for software that can load arbitrary DLLs or run code or scripts?
|
||||
In day-to-day operations, your organization’s security policy may allow certain applications, code, or scripts to run on your systems depending on their role and the context. However, if your security policy requires that you run only trusted applications, code, and scripts on your systems, you may decide to lock these systems down securely with Device Guard code integrity policies.
|
||||
You can also fine-tune your control by using Device Guard in combination with AppLocker, as described in [Device Guard with AppLocker](https://technet.microsoft.com/itpro/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies#device-guard-with-applocker).
|
||||
|
||||
Legitimate applications from trusted vendors provide valid functionality. However, an attacker could also potentially use that same functionality to run malicious executable code that could bypass code integrity policies. For operational scenarios that require elevated security, certain applications with known Code Integrity bypass vulnerabilities may represent a security risk if you whitelist them in your code integrity policies. Other applications whose older versions have vulnerabilities also represent a risk. Therefore, you may want to deny or block such applications from your code integrity policies. Once applications with vulnerabilities are fixed, you can create a rule that only allows the fixed version or newer versions of that application. The decision to allow or block applications depends on the context and on how the reference system is being used.
|
||||
|
||||
Security professionals collaborate with Microsoft® continuously to help protect customers. With the help of their valuable reports, Microsoft has identified a list of known applications that an attacker could potentially use to bypass Device Guard code integrity policies.
|
||||
Depending on the context, you may want to block these applications. To see the list of applications, and for use case examples such as disabling Windows Script Host (WSH) or disabling msbuild.exe, (See [Deploy code integrity policies: steps](https://technet.microsoft.com/itpro/windows/keep-secure/deploy-code-integrity-policies-steps)).
|
||||
|
||||
4. **Identify LOB applications that are currently unsigned**. Although requiring signed code (through code integrity policies) protects against many threats, your organization might use unsigned LOB applications, for which the process of signing might be difficult. You might also have applications that are signed, but you want to add a secondary signature to them. If so, identify these applications, because you will need to create a catalog file for them. For a basic description of catalog files, see the table in [Introduction to Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md). For more background information about catalog files, see [Reviewing your applications: application signing and catalog files](requirements-and-deployment-planning-guidelines-for-device-guard.md#reviewing-your-applications-application-signing-and-catalog-files).
|
||||
|
||||
## Getting started on the deployment process
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user