How to Create Windows AppLocker Rules (the Easy Way)

AppLocker is a native Windows tool that can help organizations prevent users from running unauthorized applications on their PCs. Although Windows AppLocker can be an effective tool for preventing the use of rogue software, it is notoriously difficult to properly configure. Setting up AppLocker usually means creating a complex set of rules for determining which applications are allowed to run. Even under the best of circumstances, this process requires a lot of trial and error. Thankfully, there is a shortcut to the rule creation process.

To ease the creation of Windows AppLocker rules, Microsoft makes it possible to build a reference device and then create rules automatically based on that device’s configuration.

With that said, the first step in the process is to create a reference device. To do so, you will need to install Windows 10 onto a physical or a virtual machine. Next, log into the device as an administrator and install all of the apps that you want to allow.

One important thing to keep in mind about the configuration process is that any apps that you install need to be of the same version, and reside in the same paths as they will on the production systems. If you happen to have a gold image that you use for operating system deployments, then it is a good idea to use that image to generate the reference OS.

Once all of the applications have been installed, log into the PC using an account with local administrative privileges (assuming that you aren’t already logged in). Next, open the local security policy by entering the GPEdit.msc command at the Windows Run prompt. Once the Local Group Policy Editor opens, navigate through the console tree to Computer Configuration Windows Settings Security Settings Application Control Policies AppLocker. You can see what this looks like in Figure 1.

AppLocker 1

Figure 1

You can access Windows AppLocker through the PC’s local security policy.

If you expand the Windows AppLocker container, shown in the figure above, the console will reveal four sub-containers, each of which are related to a specific type of rule.

The important takeaway is that, on any PC, there are likely to be multiple types of executable code (executable files, PowerShell scripts, and so on). Separate Windows AppLocker rules are needed for each one of these. In addition, the Windows operating system itself depends on the use of executable code, so AppLocker rules have to be structured in a way that does not prevent Windows from functioning properly.

As previously mentioned, however, there is a shortcut to creating Windows AppLocker rules. Right click on a rule type, and AppLocker will display a shortcut menu, similar to the one shown in Figure 2.

AppLocker 2

Figure 2

Windows AppLocker supports four different types of rules.

Before you do anything else, I recommend selecting the option to create default rules. As you can see in Figure 3, the default rules ensure that Windows is able to run. In the case of executable rules, for example, the default rules allow any executable file located in the Windows folder or the Program Files folder to run. Additionally, the default rules allow the BUILTINAdministrator account to run all files.

AppLocker 3

Figure 3

These are the default rules for executable files.

Once the default rules have been created, you can right click on a rules container again--this time selecting the option to automatically generate rules. What happens next depends on what type of rules you are creating. Generally speaking, however, you will see a dialog box asking you who the rules apply to, which folders should be analyzed, and what name you want to use to identify the rule set. Subsequent screens may prompt you to choose whether you want to base the rules on the application publisher or the file hash.

When you are done creating rules, you can export them by right clicking on the Windows AppLocker container and choosing the Export Policy command from the shortcut menu. You can then use the same technique to import the rules into a production system.

The most important thing to remember is that even though automatically generated rules generally work well, there can be unanticipated side effects associated with their use. As such, it is a good idea to initially log, but not enforce, rule usage. That way, you can make sure that the rules are working as they are supposed to, without causing problems for your users if a rule does something unexpected.