Microsoft learned in previous versions of its software that it is difficult to create code integrity (CI) policies (application control policies) under Windows Defender Application Control (WDAC) [1]. As a result, the vendor is now shipping a set of preconfigured CI policies in Microsoft Windows Server 2019 and Windows 10 v1709 that allow the execution of operating system files and applications such as Microsoft SQL Server but block executable files known to bypass the configured CI policies. Additionally, Windows Server 2019 now allows multiple CI policies to be nested to create a whitelist containing all nested CI policies, all without the need to reboot the system.

When a user runs a process, that process has the same access rights to data as the user, which means that confidential information is easily deleted or taken out of the organization. In this article, I show how you can use WDAC to create policies that block all access that is not specified in a configurable whitelist. WDAC is similar to AppLocker, which uses group policies to control access to applications in the form of path, hash, and StoreApps rules. Before Windows 10 v1709, these policies were known as configurable CI policies; Device Guard was the name of WDAC in earlier Windows versions.

Implementing WDAC

A successful WDAC implementation [2] requires extensive planning. You need to determine the necessary hardware and software and decide whether to work with whitelisting or blacklisting. Then, you need to inventory the software used in your departments to decide how many WDAC policies are required. Scanning reference PCs to identify the installed software and create WDAC policies accordingly is also recommended.

Because WDAC policies can also be used with applications and drivers signed with certificates, it is important that as many applications as possible are digitally signed. If you have applications that are not – or cannot be – digitally signed, you can use catalog files in WDAC deployment. To prepare WDAC policies that allow these trusted applications but block unsigned code, create a catalog file that contains information about the trusted applications. After signing and distributing the catalog, the trusted applications can be processed by WDAC in the same way as any other signed application. You can use catalog files [3] to block all unsigned applications and allow only signed apps and drivers to run.

WDAC Policies

Creating WDAC guidelines can be a bit complex at the start, because you first need to become familiar with the structure and setup. The best way to get started is to use the sample policies provided by Microsoft, which you will find in C:\Windows\Schemas\CodeIntegrity\ExamplePolicies [4].

To begin, look at the policy named DenyAllAudit.xml as an example. Here, Enabled:Audit Mode enables logging of application access; Enabled:UMCI means that WDAC policies restrict the binaries for kernel and user mode. By default, only the kernel-mode binaries are restricted. After enabling this option, WADC scans the user-mode executables and scripts.

In the section below </Rules> (Figure 1, line 23), you then set the rules for accessing the applications:

• <!--EKUS-->: EKU is the acronym for Extended Key Usage. Examples include Windows, early launch anti-malware (ELAM), Store, and others.
• <!--File Rules-->: Defines WDAC policies for file access.
• <!--Signers-->: Defines WDAC policies for signed drivers and applications.

Figure 1: This sample policy blocks and logs all access.

Creating Your Own WDAC Rules

After you have familiarized yourself with the sample rules in WDAC and developed an understanding of how WDAC will be used in your environment, you can create your own WDAC policies. You can store several CI policy rules in a single variable (i.e., $Rules in this example). To create your rules, use the New-CIPolicyRule cmdlet, and to create a new policy that uses the rules stored in the variable, use the New-CIPolicy cmdlet:

$Rules = New-CIPolicyRule -FilePathRule 'C:\Program Files\AdminMag\*'
$Rules = New-CIPolicyRule -FilePathRule 'C:\Program Files\MyApp\*'
New-CIPolicy -Rules $Rules -FilePath C:\CIPolicyStore\FilePathRule.xml -UserPEs

The WDAC policy is stored in an XML file. If you specify the -UserPEs parameter to include user-mode executables in the scan, the 0 Enabled: UMCI rule option is automatically added to the WDAC policy. In the future, WDAC then scans user-mode executables and scripts.

You also have the option to merge multiple WDAC policies:

Merge-CIPolicy -PolicyPaths C:\CIPolicyStore\FilePathRule.xml, C:\CIPolicyStore\DefaultWindows_Audit.xml -OutputFilePath C:\CIPolicyStore\FilePath-Audit.xml

This example merges the FilePathRule.xml and DefaultWindows_Audit.xml policies to create an XML file named FilePath-Audit.xml.