Managing AppLocker in Windows Server 2012 and Windows 8/8.1 (Part 3)

If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our WindowSecurity.com Real-Time Article Update newsletter.

If you would like to read the other parts in this article series please go to:

• Managing AppLocker in Windows Server 2012 and Windows 8/8.1 (Part 1)
• Managing AppLocker in Windows Server 2012 and Windows 8/8.1 (Part 2)

Introduction

In part one of this series, we began with an overview of AppLocker, how it differs from SRP, system requirements, and how to get started configuring it and in Part 2, we took you through the process of planning your AppLocker policies. Now in Part 3, we’ll dive deeper into more of the details of how to create your AppLocker rules and policies.

Configuring AppLocker Policies

Remember that the Application Identity Service must be started before you can use AppLocker to enforce policies, because this is the component that figures out the identity of each application. Obviously the system can’t block or allow applications without first identifying them. You can start the service manually, through the Services tab in Task Manager as shown in Figure 1.

Figure 1

It is more convenient to configure the service to start automatically, which you can do via the Group Policy Management Console (GPMC), under the following path:

Computer Configuration\Windows Settings\Security Settings\System Services

In the right details pane, double click Application Identity and in the Properties box, configure the service to start automatically.

You can configure your AppLocker policy for audit only, as we discussed in the planning section in Part 2 of this series, or you can configure it to enforce your rules. The first option gives you information about how users are using applications and the second controls how users can use applications. Note that all events are audited when rules are enforced, too.

First we’ll look at how to configure your AppLocker Policy for audit only, which can be a useful step to see the potential effects of your rules prior to implementing enforcement.

Configuring AppLocker auditing

There are a couple of different ways to set up AppLocker policies for auditing, depending on whether you want to do this for all the computers in a Group Policy Object or you just want to audit for a local computer. In an enterprise environment, you most likely will be auditing a group of computers in a GPO, so we’ll address that scenario first.

1. Log on with an account that belongs to the Domain Admins, Enterprise Admins or Group Policy Creator Owners group.
2. Open the Group Policy Management Console (GPMC) and navigate to the GPO where the rules collection is located.
3. Right click the GPO and select Edit.
4. Double click Application Control Policies.
5. Right click AppLocker.
6. Click Properties.
7. Click the Enforcement tab in the Properties dialog box.
8. Find the rule collection you want to audit and check the Configured check box.
9. Select Audit only in the list for the rule collection.
10. Click OK.

You can, of course, repeat the procedure if you want to audit more than one rule collection.

To configure a local computer for auditing of AppLocker policies, the procedure is similar, except that you would need to be a member of the Local Admins group and you go through the Local Security Policy snap-in which you can access by typing secpol.msc in the Search Programs and Files box. Then follow steps 4 through 9 in the list of steps above.

Configuring enforcement of AppLocker policies

To prevent users from running applications that could present security risks or diminish work productivity, you will want to configure your policies to enforce the rules you’ve created. The procedure is very similar to setting up policies for auditing only.

First, follow steps 1 through 8 above, but on the Enforcement tab of the AppLocker Properties dialog box, select Enforce rules instead of Audit only.

Configuring AppLocker Rules

Before you can audit or enforce AppLocker rules under the policies you’ve created, of course you must have one or more rules to enforce. In this section, we’ll show you how to create the different types of rules. You might recall that you can create five different types of rules. Which one will work best for a given application depends on the type of files used. These types include executable rules, script rules, Windows installer rules, DLL rules and Packaged app/installer rules. The different rule types are separated into rule collections.

The other consideration is the type of conditions that are to be evaluated by a rule to determine whether an application will be allowed or blocked. Here you have three choices: rules that use hash conditions, rules that use path conditions and rules that use publisher conditions. Let’s look at how to create each condition type.

And with configuring AppLocker policies, you can create AppLocker rules using Group Policy or through the Local Security Policy. We’ll focus on using Group Policy because that’s the most efficient and most common method in the business network environment.

Creating hash condition rules

A cryptographic hash of each file is created by the system. Each file has its own unique hash. The up side of hash rules is that this is a secure type of rule, especially for files that aren’t digitally signed. The down side is that whenever a file gets updated, its hash will change and you’ll have to update the hash rule manually, which can be a pain with applications that are updated often.

To create a hash condition rule, perform the following steps:

1. In the GPMC, find the GPO where the policy you want to use is located, and select Edit, or open the Local Security Policy console.
2. Double click Application Control Policies.
3. Double click AppLocker.
4. Select the rule collection for which you want to create a rule (for example, Executable rules).
5. Right click the collection or click the Action menu, and choose Create New Rule. This will start the new rule wizard, as shown in Figure 2.

Figure 2

6. Click Next on the Before You Begin page. You can set the wizard to skip this page by default so you won’t have to see it every time you create a new rule.
7. On the Permissions page, you select whether you want this rule to allow or deny the file to which it applies, and select the user or group to which you want the rule to apply, as shown in Figure 3.

Figure 3

8. On the Conditions page, select File hash as the condition type for this rule, as shown in Figure 4.

Figure 4

9. On the File Hash page, click Browse and find the executable file for the application to which you want this rule to apply. Use Browse Files if you want to select just one specific file or use Browse Folders if you want the system to calculate a hash for all of the executable files in a folder.
10. Click Next.
11. On the Name and Description page, type a name for the rule that will make it easy for you to remember what it is,      and then click Create to generate the new rule.

Creating path condition rules

Path condition rules use the application file’s location in the file system to identify the file to be allowed or blocked. To create a path conditions rule, follow the same steps 1 through 7 above, then select Path on the Conditions page and again, browse the files to find the file or folder where the application resides. You can also type the path directly into the Path box.

The path conditions rule has the advantage of making it easy to control multiple directories (or just one file) and you can use the wildcard character (*) within path rules. However, you must know and specify the full path, and if the path has subdirectories for which non-admins have write permissions, this can pose a security risk.

Creating publisher condition rules

Publisher condition rules have a number of advantages. You can use just one rule to allow an entire suite of products (assuming they all have the same digital signature information) and you don’t have to update the rule frequently as you do with hash rules. You can use the wildcard character here, too, to represent any publisher, any product name, any file name or any file version within the rule. The drawback is that this type of rule only works with files that are digitally signed by the publisher.

To create a publisher condition rule, follow steps 1 through 7 above, then on the Conditions page, select Publisher as the rule condition. This one is a little different in that after you browse to select a signed file, you can then use a slider bar interface to control the scope of the rule.

Default rules

Default rules are included for each rule collection that will automatically create rules to allow the Windows system files to run. You need to be an Administrator to generate the default rules. In the Local Security Policy console, double click Application Control Policies and then double click AppLocker, and right click the rule type (executable, Windows Installer and/or script rules). Select Create Default Rules and these rules will be automatically created.

Summary

In this, Part 3 of our 4-part series on managing AppLocker in Server 2012 and 2012 R2, we showed you how to configure the AppLocker policies and create AppLocker rules. You might have noticed that the DLL rule collection did not show up in the list of rule collections in the console tree. In Part 4, we’ll wrap up the series by discussing how to enable the DLL rule collection, how to create exceptions to rules, how to edit and delete rules, and how to import and export AppLocker policies between computers.

If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our WindowSecurity.com Real-Time Article Update newsletter.

If you would like to read the other parts in this article series please go to:

• Managing AppLocker in Windows Server 2012 and Windows 8/8.1 (Part 1)
• Managing AppLocker in Windows Server 2012 and Windows 8/8.1 (Part 2)