AppLocker in Windows Server 2008 R2 and Windows 7

Windows Server 2008 and Windows Vista include the BitLocker feature, which provides volume-level encryption for bits stored on Server 2008 and Vista computers. Windows Server 2008 R2 and Windows 7 include AppLocker, which is an application locker that lets Windows administrators provide application access control to restrict which applications can run on their domain’s workstations and servers.

AppLocker is an enhanced version of Windows Server 2003’s Software Restriction Policies. SRPs and AppLocker tackle the problem of execution of malicious code on Windows platforms. You can also use SRPs and AppLocker to block user access to games such as Minesweeper, or to prohibit the startup of a browser that isn’t standard in your organization.

In this article I compare AppLocker with SRPs, concentrating on the caveats and pitfalls you must be aware of in evaluating AppLocker for use in your environment. Table 1 lists the main differences between SRPs and AppLocker.

Table 1: SRPs vs. AppLocker

Blacklisting and Whitelisting

Malware-protection programs such as antivirus and antispyware software often use a technique referred to as blacklisting to protect computers. Programs that employ blacklisting allow everything to be stored on a computer other than files that are infected with threats listed on the blacklist. If a file is infected, these programs will either delete or quarantine it.

An emerging approach to combating malware is whitelisting. Whitelisting takes an opposite approach to blacklisting—that is, the protection program blocks everything except the files that are on its whitelist.

When it comes to protecting computers against the execution of unwanted malware, whitelisting is preferable to blacklisting. Whitelisting eases the life of the administrator, because in today’s interconnected world, users are typically allowed to run fewer applications than they should be blocked from running—including an almost unlimited number of unknown malicious executables that users might download from the Internet. However, whitelisting creates the risk of locking yourself out if you don’t use it properly. For example, you might neglect to add your management applications to the whitelist. In addition, you can inadvertently prevent your users from working if you forget to add one of their applications to the whitelist.

SRPs and AppLocker both support whitelisting and blacklisting, although they have different default policies. AppLocker uses whitelisting by default, thereby blocking everything; the administrator must explicitly define the applications that can run. The default SRP configuration uses blacklisting, which allows all applications to run; the administrator must define exceptions for any applications to be blocked. Setting up whitelisting with SRPs is difficult, which is why most admins use it only for blacklisting applications. AppLocker is much better suited to provide whitelisting-based protection for controlling applications.

Setting Up AppLocker Rules

To begin, you must know how to configure application restriction rules in AppLocker. As with SRPs, you can use Group Policy Object (GPO) settings to configure and enforce AppLocker rules. You can also use PowerShell cmdlets to configure AppLocker rules (this option isn’t available for SRPs). (For information about using PowerShell cmdlets with AppLocker, see the MSDN Windows PowerShell Blog entry “Getting Started with AppLocker management using Powershell.”)

As Figure 1 shows, the AppLocker GPO is in the Computer ConfigurationWindows SettingsSecurity SettingsApplication Control Policies container. Notice that you can also configure rules in the Software Restriction Policies container. The two technologies can coexist—you can leverage SRPs on all Windows platforms after Windows XP and Windows Server 2003, but AppLocker is available only on Server 2008 R2 and Windows 7 Ultimate and Enterprise. Because the policy rules that the two technologies use are so different, Microsoft doesn’t provide an automatic conversion from SRP to AppLocker policies (e.g., if you upgrade a Server 2008 machine to Server 2008 R2).

AppLocker supports three rule types: Executable Rules, Windows Installer Rules, and Script Rules. These rule types are grouped in rule collections and appear as subcontainers of the AppLocker container in the GPO settings, as Figure 1 shows.

When you right-click one of the three rule collection containers, AppLocker gives you three options for creating rules: Create New Rule, Automatically Generate Rules, and Create Default Rules.

Create Default Rules. The preferred option for getting started with AppLocker rule definitions is Create Default Rules. Default rules are generated automatically; these rules are tailored to let Windows run and to let you do your administrative work—both of which are important, considering AppLocker’s default whitelisting approach and the risk of locking yourself out. As a safety net, AppLocker prompts you to automatically create the default rules if you try to create a new rule and haven’t yet created the default rules.

AppLocker’s default rules are relatively open. For example, they include a rule that gives members of the local administrators group access to all local files. An AppLocker best practice is to first create default rules, then refine them using more restrictive rules that you create manually through the Create New Rule option (which I explain later). Default rules can be created separately for each of the three rule types: Executable Rules, Windows Installer Rules, and Script Rules.

Automatically Generate Rules. With the Automatically Generate Rules option, AppLocker basically generates a whitelist for you. Based on the file folder you provide in the automatic rule generation wizard, AppLocker will propose a set of rules for the files in that particular folder. This important new AppLocker feature isn’t included in SRPs. With SRPs you must define the whitelist yourself. To create an AppLocker whitelist for a certain category of machines, I recommend that you use a reference computer. Sharing such a whitelist with other computers and importing the whitelist into a GPO is relatively simple thanks to AppLocker’s easy-to-use export/import mechanism.

To automatically generate a rule set, select Automatically Generate Rules from the Executable Rules, Windows Installer Rules, or Script Rules context menu. On the wizard’s first screen, select a file system location on the reference machine, indicate the users or groups you want the whitelist to apply to (an important option that isn’t available in SRPs), and provide a name for the resulting rule set.

Next, select whether you want to create rules based on the file’s hash or path. Using the hash thumbprint is the most unique way to identify a file, but it has the disadvantage of requiring revisions of the rule when the file is updated (e.g., after a patch cycle). In addition, using hashes can negatively affect system performance.

The wizard also gives you the option of reviewing the list of files that it analyzed (including cancelling creation of a rule for a given file), previewing the rules list, and searching the list. Figure 2 shows the final step of actually creating the rules list.

Create New Rule. Another approach to creating AppLocker rules is to define them manually, through the Create New Rule option. You’ll typically use this option as a last step to refine the rules AppLocker created for you using one of the options that I discussed previously.

From the rule creation wizard, you can create new allow or deny rules for files, select the group or user you want the rule to apply to, and choose whether you want AppLocker to identify the files using the file’s hash, the file path (file system location), or the file’s publisher. AppLocker refers to these identification options as primary conditions. You can then further narrow down the identification of files by specifying exceptions to the primary condition in the wizard (hash-based, path-based, or publisher-based).

If you choose publisher-based identification, AppLocker will identify the file through the file’s digital signature that was applied by the publisher as part of its software signing process. Figure 3 shows the options for publisher-based identification. You can use the slider bar to limit the identification of files to only the publisher name (most general) or expand identification as far as the exact file version (most specific). The wizard also lets you specify custom values for the publisher, product name, file name, and file version fields.

Note that AppLocker doesn’t offer the network zone (aka Internet zone) file identification option that SRPs provide, which lets you use the Internet zone of the website from which code was downloaded to identify the code.

Enforcing AppLocker Rules

Like SRPs, AppLocker isn’t enabled by default. Even when you’re done creating rules, AppLocker won’t immediately enforce them on your clients. Rule enforcement requires two additional steps. First, you must specify whether you want to enforce your rules or run them only for auditing purposes. Second, you must ensure that the Application Identity Service is running on the targeted machines.

You can set AppLocker’s enforcement options through the AppLocker GPO’s properties. As Figure 4 shows, you can specify whether a rule is configured (the default is not configured) and indicate whether the rule should be enforced or run only in audit mode, for each of the three main rule collections (i.e., Executable rules, Windows Installer rules, and Script rules).

The Audit only option is a useful new feature that isn’t available with SRPs. When a rule collection is set to Audit only mode, the rules within that rule collection aren’t enforced, but any time a user runs an application that’s affected by a rule, information about the rule and the application write to the local machine’s AppLocker event log container.

I recommend that you select the Configured check box and choose Audit only in the drop-down menu for each of the three rule collections. Not only does this protect against locking yourself out, but it also lets you see whether your rules are catching the correct applications, as well as whether they’re too permissive or too restrictive. I also recommend that you use the Audit only mode until you’ve recorded and evaluated all the rules’ effects and side effects.

Note that the Advanced tab of the AppLocker container’s properties refers to a fourth AppLocker rule collection: DLLs, to cover the *.dll and *.ocx file formats. Microsoft set this rule collection apart in the Advanced tab because of the performance impact DLL checking has when it’s enabled. In addition, the process of whitelisting all the allowed DLLs creates a significant amount of administrative overhead. You should enable AppLocker DLL protection only in organizations with extremely critical IT security (e.g., government or defense organizations).

The last step in guaranteeing AppLocker enforcement is to make sure the Application Identity Service is enabled on your Server 2008 R2 and Windows 7 machines. This service is set to manual startup by default. To properly use AppLocker, you must set the service to start up automatically. You can use GPO settings to configure all your machines at once. Because anyone with local administrator rights can stop the service and therefore bypass AppLocker policy enforcement, you need to keep tight control over your administrator accounts.

A Major Step Forward

Like SRPs, AppLocker requires regular rule updates to properly deal with patches and new versions of protected applications. AppLocker can’t yet deal with software updates in a dynamic and silent fashion. For this purpose, certain third-party whitelisting applications (e.g., Coretrace’s Bouncer, Bit9’s Parity) will perform better. In addition, these applications provide broader platform and file-type support. However, AppLocker is a major step forward for application whitelisting in Server 2008 R2 and Windows 7, compared with SRP blacklisting. Windows administrators will appreciate AppLocker’s ability to automatically create whitelists, to run in audit-only mode, and to limit rule application based on user and group accounts.