deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-14 14:27:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge pull request #46 from JanKeller1/DGDGupdate

Browse Source 
Updated 2 lines of Tbl 3, added headings
This commit is contained in:
Brian Lich 2016-06-23 14:42:38 -07:00 committed by GitHub
commit 556f2b4a44
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
windows/keep-secure/device-guard-deployment-guide.md
View File

@ -752,7 +752,7 @@ To modify the policy rule options of an existing code integrity policy, use the
You can set several rule options within a code integrity policy. Table 2 lists each rule and its high-level meaning.
Table 2. Code integrity policy - policy rule options
#### Table 2. Code integrity policy - policy rule options
| Rule option | Description |
|------------ | ----------- |
@ -769,15 +769,15 @@ Table 2. Code integrity policy - policy rule options
| **10 Enabled:Boot Audit on Failure** | Used when the code integrity policy is in enforcement mode. When a driver fails during startup, the code integrity policy will be placed in audit mode so that Windows will load. Administrators can validate the reason for the failure in the CodeIntegrity event log. |
File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as low as the hash of each binary and as high as a PCA certificate. File rule levels are specified both when you create a new code integrity policy from a scan and when you create a policy from audit events. In addition, to combine rule levels found in multiple policies, you can merge the policies. When merged, code integrity policies combine their file rules. Each file rule level has its benefit and disadvantage. Use Table 3 to select the appropriate protection level for your available administrative resources and Device Guard deployment scenario.
Table 3. Code integrity policy - file rule levels
#### Table 3. Code integrity policy - file rule levels
| Rule level | Description |
|----------- | ----------- |
| **Hash** | Specifies individual hash values for each discovered binary. Although this level is specific, it can cause additional administrative overhead to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. |
| **FileName** | Specifies individual binary file names. Although the hash values for an application are modified when updated, the file names are typically not. This offers less specific security than the hash level but does not typically require a policy update when any binary is modified. |
| **SignedVersion** | This combines the publisher rule with a file version number. This option allows anything from the specified publisher, with a file version at or above the specified version number, to run. |
| **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 PCA certificate and the common name (CN) on the leaf certificate. In the scenario that a PCA certificate is used to sign multiple companies’ applications (such as VeriSign), this rule level allows organizations to trust the PCA certificate but only for the company whose name is on the leaf certificate (for example, Intel for device drivers). This level trusts a certificate with a long validity period but only when combined with a trusted leaf certificate. |
| **FilePublisher** | This is a combination of the publisher file rule level and the SignedVersion rule level. Any signed file from the trusted publisher that is the specified version or newer is trusted. |
| **FilePublisher** | This is a combination of “FileName” 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. |
| **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. Using this level, no policy update would be needed to run the new version of the application. However, leaf certificates have much shorter validity periods than PCA certificates, so additional administrative overhead is associated with updating the code integrity policy when these certificates expire. |
| **PcaCertificate** | Adds the highest certificate in the provided certificate chain to signers. This is typically one certificate below the root certificate, because the scan does not validate anything above the presented signature by going online or checking local root stores. |
| **RootCertificate** | Currently unsupported. |