Creating Device Guard Polices from a Golden Image

Contents

Introduction

Device Guard is a system built into Windows 10 that can help mitigate the effects of a breach by controlling which applications are allowed to run, both processess in userland and drivers in the kernel. After Windows 10 1709 Device Guard is now known as Windows Defender Application Control, however, in this post it will be refereed to as Device Guard.

This post will aim to show the steps taken to configure a Device Guard policy based on a golden image, this is a computer that is configured and has all the needed software installed. The configuration will be done on a Windows 10 LTSC build 17763.

Two configuration polices will be created for the software installed on the system, the rule level used in these examples will be Publisher with a fallback of hash. This means we will be whitelisting applications based on their root CA along with the publisher CA, if that fails a hash of the file will be used.

The post will take two different approaches to creating a policy from a golden image:

  • The first approach will scan for user applications and will add their signature or hash to a policy file.

  • The second will start with a default Windows policy from Microsoft, this will allow all the certificates present on a default Windows installation. User activity will then be performed with this policy, and from new a new policy will be generated in order to whitelist the applications used.

Generating Policy from Installed Software

Generating Initial Policy

In order to begin creating the initial policy the directories to scan must be decided, for this example I will be using the system32 and programs folders. The following shows the commands used with the New-CIPolicy Cmdlet. Please note that all the polices generated will be in audit mode by default, this means that if you enable Device Guard with this policy it will only generate audit information about what could happen rather than actually blocking an application. We need this for the beginning, it will be turned off later on.

These three commands will generate three seprate XML files that will define which CA’s are allowed. The following code snippet shows an example of a possible field, here we can see that a CA with the Common Name of Mozilla Corporation will be allowed if it is signed by DigiCert.

1
2
3
4
<Signer ID="ID_SIGNER_S_2FD" Name="DigiCert SHA2 Assured ID Code Signing CA">
  <CertRoot Type="TBS" Value="E767799478F64A34B3F53FF3BB9057FE1768F4AB178041B0DCC0FF1E210CBA65" />
  <CertPublisher Value="Mozilla Corporation" />
</Signer>

Now, you may have noticed that the last run of New-CIPolicy gave an error saying it was unable to generate rules for all scanned files. This can happen at times, when it does you must check the log file in order to see which files are affected.

Looking at the log file we can see that the Firefox uninstaller binary is affected, however, for this example it will not change much so we will just leave it.

After the three seperate polices have been created, they must be merged into a single XML file. This can be done using the Merge-CIPolicy Cmdlet.

In order to make use of the polices generated they must be converted into a binary format, this is done to make parsing the policy quicker for the computer. In order to convert it to a binary format use the ConvertFrom-CIPolicy Cmdlet, make sure to take note of the location of the binary policy.

Enable Device Guard

Now that a code integrity policy has been created Device Guard must be enabled. Start by navigating to Computer Configuration -> Administrative Templates -> System -> Device Guard in the Group Policy editor.

Next, enable Virilization Based Security. This is a feature of Windows 10 that Device Guard can make use of, select the code integrity portion of the settings and enable it.

Lastly, enable and place the path to the policy binary under the Device Guard configuration.

After these settings are enabled restart the computer and when it boots up Device Guard should be running, depending on the policy it will either be in audit mode or enforcing. In this case it will be in audit mode.


Device Guard Policy not in Effect After Reboot

NOTE: In some cases you may notice that the Device Guard policy is not in effect after reboot, this has happened a few times during my testing. In order to solve this reboot the computer a second time, and the policy should be in effect.


View Audit Logs

Now that the policy is running in audit mode you can view audit information in Event Viewer, head over to Microsoft-Windows-CodeIntegrity in EventViewer in order to view the logs.

The most important log is Event ID 3076, this is the event that will show any applications that are run which do not meet the code integrity policy. In other words, if the policy was set to enforcing these applications would be blocked from running.

Below we can see that a WinRAR executable has been prevented from running. The goal here is to perform user activity and watch the logs to see if any undesired applications have been blocked, after the policy can be altered in order to meet the requirements.

Set Policy to Enforcing

Once the policy has been configured to meet the applications requirements it is a good idea to do a test run with the policy in enforcing mode. In order to do this use the Set-RuleOption and delete option 3, which is the option that enables audit mode.

After the option is deleted reboot the computer, the policy should now be enforcing. If you attempt to run any applications that do not meet your code integirty policy you will be greeted with a message that looks like the following screenshot.

Generating Policy from Audit Logs

Fetch Default Windows Policy

We will begin by using the default Windows audit policy, this can be found in the C:\Windows\schemas\CodeIntegrity\ExamplePolicies folder. Copy the desired file to the location where you will be creating the polices in.

Convert Default Policy to Binary

Next, convert the policy into a binary format using the ConvertFrom-CIPolicy Cmdlet.

Enabling Device Guard

Now enable Virtualization Based Security and Device Guard, you can see how this is done in the section above .

Generate Policy from Audit Logs

Once you have booted into the system using the default Windows policy in audit mode the real work begins. The goal here is to use a system exaclty how a regular user would, this includes using all the applications that they would have. This will end up generating many log files regarding all the applications that the code integrity policy would not allow, from this we can generate a new policy to whitelist them.

Once all user activities have been completed use the New-CIPolicy Cmdlet with the -Audit parameter in order to generate a new policy from the audit logs. You may see text that refers to programs that are no longer present, in most cases this is nothing to worry about.

Create Final Policy

Finish by merging the default Windows policy with the new audit policy. Depending on what stage you are in, you may wish to either keep or remove the audit option.

Convert the policy to a binary format and reboot the computer to test it out.

References