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

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 3)

How AppLocker policies and rules are processed

Before you can plan for the implementation of your AppLocker policies, you need to understand how they work and are processed. AppLocker rules are controls that are applied to the types of files that are subject to AppLocker controls, which determine whether or not that file is allowed to run. AppLocker policies are sets of rules that are enforced on a computer via the Application Identity Service. The Application Identity Service is responsible for evaluating the policies. Remember that the service is required to be enabled and started in order to enforce AppLocker policies.

Figure 1

There are five types of rules, based on the type of file it controls. They are:

• Executable rules (applies to .EXE and .COM files)
• Script rules (applies to .PS1, .BAT, .CMD, .VBS and .JS files)
• Windows installer rules (applies to .MSI, .MST and .MSP files)
• DLL rules (applies to .DDL and .OCX files)
• Packaged app/packed app installer rules (applies to packaged apps and installers with .APPX extension)

Each rule contains an “allow” or “deny” access control entry (ACE), a security identifier (SID) to specify the user or group that the rule applies to, and a rule condition. There are three possible rule conditions. These are:

• Publisher conditions that allow or deny the running of files that have been signed by a particular software publisher.
• Path conditions that allow or deny the running of files stored in a particular file path.
• Hash conditions that allow or deny the running of files whose encrypted hashes match the one specified in the rule.

Note that deny rules are processed before allow rules.

It’s important to understand how the Group Policy settings impact the enforcement of AppLocker rules. There are three possible enforcement mode settings for each type of AppLocker rule:

• Not configured.
• Enforce rules
• Audit only

Figure 2

Although it might not seem intuitive, when the enforcement mode is not configured, any rules that are set up for that rule type will be enforced. The “enforce rules” mode also will obviously cause rules to be enforced. If you select to audit only, rules will not be enforced; however, if a user runs a program that would have been affected by the rule (if rules were enforced), that information will be recorded in the AppLocker event log.

Note that you can create exceptions for your rules. That is, you can specify particular files or folders that you do not want to be enforced by the rule. You do this through the Properties dialog box for the particular rule. We will discuss how to create rules and exceptions later in this article series, after we finish talking about planning your AppLocker deployment.

The planning process

There are a number of steps involved in planning your AppLocker deployment. These include:

1. Decide whether AppLocker will be used in conjunction with SRP.
2. Decide whether you will use allow rules only, or both allow and deny rules.
3. Decide where AppLocker will be deployed.
4. Determine what applications are installed.
5. Determine which applications you need to control.
6. Decide which of the five rule set types (executable, script, installer, DDL,packaged apps) you’ll use.
7. Determine enforcement settings for each of your OUs.
8. Create a plan for maintaining your AppLocker policies.

Remember to document your plan and the design process, as well as the actual deployment process.

Note:
AppLocker policies will only be enforced on those computers in your organization that are running a version of Windows that supports AppLocker. Client operating systems that support AppLocker include Windows 8/8.1 Enterprise edition and Windows 7 Enterprise and Ultimate editions. Server operating systems that support AppLocker include Windows Server 2012 R2 and 2012 Standard and Datacenter editions, Windows Server 2008 R2 Standard, Enterprise and Datacenter editions.

You have several different choices when it comes to designing your policies. You can use AppLocker in any of the following ways:

• Create policies to control all applications or specific applications by using an “allow” list. Only those applications on the list can be run. You can create exceptions.
• You can control only legacy (desktop) applications or only modern UI (Windows Store) apps or you can control both. Windows Store apps are categorized under the Publisher condition.
• You can control applications for specific users or groups by applying AppLocker policies to particular objects in an OU.
• You can control applications for specific computers.
• You can audit application usage without controlling/blocking any applications.

When planning your AppLocker deployment, you’ll want to consider whether you need to have different policies for different groups of users. If this is the case, your design process will be a little more complex. The best way to do this is to have different GPOs for the different groups; however, your Active Directory design might not have been structured in that way. The alternative way is to apply the AppLocker rules to individual user groups.

If you’re in that situation, be aware that each rule can only be applied to one user or one group. That is, you can’t add additional users/groups to the same rule. You can, however, create as many rules as you want for the same application. So if you have two groups that need to run the same application (or that need to be blocked from running the same application), you can create a rule for each of those groups that allows (or denies) access to that application.

You can create as many total rules as you like (there is no coded limit) but a large number of rules can slow down performance because they must all be evaluated and applied. There is an indirect limit on the number of rules that can be in a GPO based on the maximum size of the GPO.

Note:
It’s important to remember that there are some types of files that AppLocker cannot control, include scripts other than VBScript, Jscript, .bat, .cmd and PowerShell scripts (Perl, macros and other types of interpreted code cannot be controlled by AppLocker).

In addition, AppLocker cannot block specific 16 bit DOS programs that run in a NTVDM (NT Virtual DOS Machine). What you can do instead is set AppLocker policies to block running NTVDM.exe. This will prevent all 16 bit DOS binaries from running.

Planning for AppLocker and SRP together

If you have older systems in your organization, you need to plan for how they fit into your application control strategy. Ideally you will have upgraded any Windows XP computers before the end of support since they present a security risk in and of themselves with no more security updates. However, you might still have systems running Windows Vista or Server 2003.

In this case, AppLocker policies cannot be used to control software running on those machines. SRP can be used for them, which means you will have SRP and AppLocker coexisting on your network, so you’ll have a few additional planning considerations. Newer operating systems support both AppLocker and SRP, so you need to be aware that AppLocker policies take priority over SRP policies when both are applied to the same Group Policy Object (GPO) or linked GPOs, for computers that support AppLocker.

The best way to handle it is to create different GPOs for your AppLocker and SRP policies instead of applying them both to the same GPO. This can save many headaches in the future. When you want to deploy AppLocker and SRP in the same domain, you should test the policies before deploying them on a production network to make sure the effect is what you intend.

You can test the effects of AppLocker policies by using the Get-AppLockerPolicy and Test-AppLockerPolicy cmdlets in PowerShell, or you can use the Audit Only mode that will let you see, in the event log, what the effect of the policies would be. You can test the effects of SRP by using the Resultant Set of Policies (RSoP) tool, which is a snap-in for the Group Policy Management Console (GPMC).

Summary

In this part of our multi-part article on managing AppLocker in Server 2012 R2 and Windows 8/8.1, we hit on some of the most important highlights in the process of planning an AppLocker deployment, including deploying AppLocker and SRP in the same domain. In the next part of our series, Part 3, we’ll get into more of the meat of how to create your AppLocker rules and policies and how to create exceptions to the rules.

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 3)