Device guard is quite powerful in blocking unwanted software to run on Windows Server (or Windows 10 client), and it is complex.
This page is intended to help answer some common questions.
For basics, please check out this TechNet page: https://technet.microsoft.com/en-us/itpro/windows/keep-secure/device-guard-deployment-guide
Eventlog from CodeIntegrity event channel is the primary logging for Code Integrity violations on the machine. However, there are many types of Eventlog monitoring software (a.k.a. SIEM Security Information and Event Management). OMS is one of them.
The CI policy is defined by the C:\Windows\System32\CodeIntegrity\Sipolicy.p7b file. There are two ways to deploy it. You can either use a signed policy or unsigned policy. If you use an unsigned policy, it can be removed by an admin, but it does require a reboot, if you are using TPM attestation, this change can be detected.
If you use a signed policy, the information about the policy is stored in a UEFI boot variable (in the firmware basically). When the policy is being deleted, the machine will fail to boot. There are overhead in managing signed policy file, however, if the server is in a very locked down state, and rarely change any binaries on it, it could be the right solution.
There are two settings when you enable VBS: with UEFI lock or without. With UEFI lock, you can not simply disable VBS even if you have the admin credentials. If VBS is disabled, the secret held in VBS would not be accessible. The machine can boot normally, but if the machine is attested, the change can be detected.
Device Guard has hardware requirement. If you are not sure if your machine is capable of running Device Guard (or Credential Guard), you can run this tool to check it before turning it on.
There are a few ways you can sign your applications. If your company has PKI solutions deployed, you can sign it, or use PackageInspector with Windows Store for Business.
You can deploy device guard using regkeys. Without UEFI lock, administrators on the machine will be able to turn device guard off. With UEFI lock, it requires physical presence to the machine to change the settings.
'REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 1 /f'
'REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 1 /f'
'REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 1 /f'
'REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Locked" /t REG_DWORD /d 0 /f'
'REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v "LsaCfgFlags" /t REG_DWORD /d 2 /f'
On some newer HP and Dell computers, you can switch between version 1.2 and 2.0.
TPM upgrade is possible but dependent on hardware vendor and model of PC. Commands to configure/Utilities are provided by the hardware vendor, though it's possible to integrate them into deployment solution such as SCCM or MDT, depending on the utility/commands.
Windows do not support a TPM upgrade without a reinstall.
Dell: http://en.community.dell.com/techcenter/enterprise-client/w/wiki/11850.how-to-change-tpm-modes-1-2-2-0
HP: http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c05192291
When Secure Boot setting is selected, if the hardware doesn't support IOMMU, VBS will start without DMA protection; if the hardware supports IOMMU, VBS will start with DMA protection. When Secure Boot with DMA is selected, VBS will only start if the hardware supports IOMMU.
Credential Guard = a credential protection feature that also uses the VBS environment to protect user credentials from being accessible from the OS