Share via

Default Code Integrity policy for Windows Server

  • Article

After Windows Defender Application Control (WDAC, formerly known as Code Integrity) was released in Windows Server 2016, I wrote a blog post on it, it was a very effective way to do application whitelisting, and get secure!

When engaging with customers to get their feedback and help deploy WDAC, the consistent feedback has been “it’s great, but it’s too hard to deploy it.” We listened, and created a few default policies, which balance the security and operational management effort.

Those policies are stored under “C:\Windows\schemas\CodeIntegrity\ExamplePolicies” on any Windows OS post 1709 release. I recommend two policies for Windows Server:

AllowMicrosoft: this CI policy allows all the files signed by Microsoft. If you are running Server applications such as SQL, Exchange, or the server is monitored by agents published by Microsoft, you should start with this policy.

DefaultWindows: this policy only allows the files which are shipped in Windows and doesn’t permit other applications released by Microsoft (such as Office). This is a good policy to use if the Server is dedicated for inbox server roles/features, such as Hyper-V.

There are known applications in Windows that might be used to bypass WDAC, the full list is published on this page. I recommend adding them to the deny list in the Code Integrity policy. Please note, the list is updated periodically with newly identified applications, you should review the list and add them to your CI policy if determined fit.

To make it easy for you, I created two copies of the default CI policies that you can download (the follow CI policy is designed for the next release of Windows Server, you can also modify it to remove the new policy rule options for Windows Server 2016:

AllowMicrosoft_DenyBypassApps_Audit.xml DefaultWindows_DenyBypassApps_Audit.xml

One of the new rule options in the above policy file is “Update policy no reboot”. On generic servers, it’s often user needs to be add software, when do so, the CI policy might require a change to cover the application, this rule option allows the CI policy to be updated without machine reboot. This option is added post Windows Server 2016. If you want to use the policies on Windows server 2016, you will need to remove them.

Adding additional publishers

Most of the customers have their own applications developed internally or acquired externally to manage the servers, i.e. the above default policies are not enough. To allow these apps (or even drivers) to load, you will need to modify the CI policy to cover them. There are a couple of approaches:

  1. Adding publisher: If you want to trust all the applications created by the vendor, you can add their publisher to the CI policy. Run the following cmdlet to extract the publishers to an xml file:
 New-CIPolicy -FilePath <appCI.xml> -Level Publisher -ScanPath <the path which the app is installed>  -UserPEs
  1. Adding FilePublisher: If you want to only trust the installed application (not all the applications from this vendor), you can add FilePublisher to the CI policy to the CI policy. Run the following cmdlet to extract the file list and its publisher to an xml file:
 New-CIPolicy -FilePath <appCI.xml> -Level FilePublisher -ScanPath <the path which the app is installed>  -UserPEs

You can mix and match different applications (from different vendors) with the two approaches described above.

For example, you have an active development team internally, you want to add your enterprise signer/publisher in the CI, so that all the enterprise signed applications can run in the environment; you can also enable a device driver by adding the FilePublisher rule for that driver.

For the same publisher, you need to choose between to trust the publisher or trust the FilePublisher. For example, if you contracted a vendor company to develop an application, and you decide to trust the vendor company by adding their publisher to the CI, later if you want to change to trust only that application, you should remove the vendor publisher from the CI first, then add the application FilePublisher rule.

Merge CI policies

With all the CI files generated to cover the additional file/publisher information, you will then merge them with the default CI policies by running:

 Merge-CIPolicy -OutputFilePath ‘Serverdefault-audit.xml’ -PolicyPaths ‘.\AllowMicrosoft_DenyByPassApps_Audit’,’additionalCI1.xml’, ‘CI2.xml’

Deploy CI policy

CI deployment and ongoing monitoring is covered in this blog post. You can also reference this page for group policy deployment. Below is a quick reference for your convenience:

The created CI policy is in audit mode, you can change it to enforced mode by running:

 Set-RuleOptions -FilePath C:\CI\FilePublisher.xml -Option 3 -Delete

The XML file created by New-CIPolicy can’t be consumed by the system yet. To deploy the policy, it needs to be converted to binary format and copied to the CodeIntegrity folder under System32.

Run the following cmdlet to convert the xml file:

 ConvertFrom-CIPolicy C:\CI\FilePublisher.xml C:\CI\FilePublisher.bin

Deploy CI policy:

 Copy-Item C:\CI\FilePublisher.bin C:\Windows\System32\CodeIntegrity\SiPolicy.p7b

Reboot the server to allow code integrity service to load the policy.

 

I hope the default server CI policies can help you to speed up the deployment, and as always, you can share your feedback by email with us or submit and vote on requests through the User Voice.