Windows 7 and AppLocker

Global Knowledge | Knowledge Centre | White Papers | Microsoft White Papers | Windows 7 and AppLocker

Windows 7 and AppLocker

Author: Glenn Weadock

Abstract

AppLocker represents some significant improvements to Software Restriction Policies. The ability to use digital signature information, the ability to use greater-than and less-than operators for version numbers, letting administrators create rules based on group membership, and being able to autoscan a "standard" workstation to automatically generate rules for all certified applications, all work together to reduce some of the key objections to SRPs in Server 2003 and Server 2000. Of course, AppLocker isn't perfect. And there are several things to consider before deciding to leverage it. This white paper introduces you to AppLocker and makes a few key points about how it differs from earlier software restriction technologies.

Introduction

Anyone who has ever worked in the IT support field knows that the help desk analyst's job is made much tougher if he or she doesn't know which software the user has installed. This has been a problem since the early days of personal computing. Unbeknownst to IT, employees install new programs on their PCs, and that can complicate troubleshooting efforts when problems arise. For example, if a user wants to know how to configure his or her system to selectively block browser popups, it's that much harder to advise that person if he or she has installed multiple browser toolbars, each of which has its own separate setting!

But the problem doesn't stop there. Apart from introducing a level of inconsistency to the supported environment, "annoyware" - that is, applications that create unwanted side effects on the company network - can have a performance impact too. Excessive network bandwidth usage can result from software that autodownloads graphics for screen savers, wallpaper, etc. Unauthorized applications can hijack file suffix mappings, so that corporate-certified applications no longer run when a user double-clicks a certain file type.

All this boils down to a simple axiom: organizations want to run the apps they want, and not run the apps they don't want. Sounds simple, but it can be surprisingly challenging in the real world. One of the tools Microsoft has given Active Directory administrators to help in this regard, Software Restriction Policies (SRPs), has been re-engineered in Windows 7 as AppLocker. This white paper introduces you to AppLocker and makes a few key points about how it differs from earlier software restriction technologies. It will cover:

Background of SRPs
The Path Rule
The Hash Rule
The Publisher Rule
Audit mode
Configuring AppLocker
Experimenting with AppLocker

Background of SRPs

SRPs and XP/2003/2000. Ever since Active Directory 1.0 (Windows 2000), Windows has sported a capability called Software Restriction Policies or SRP's for short. SRP's allowed administrators to configure their Active Directory networks in one of two ways: a blacklist (by far the most common) and a whitelist. The blacklist method involves setting the "default rule" to unrestricted; that is, unless otherwise specified, users can run any program. Then the annoyware products are specified using "additional rules."

Conversely, the whitelist method involves setting the default rule to disallowed. This is a lot more work, because you have to create an "additional rule" for every program a user legitimately might need to run. You will forget a lot of these, I guarantee it. (Calculator!) Of course, if you don't mind the work, the whitelist method represents the highest degree of security. But not only is it a great deal of work up front, it also represents an ongoing commitment to continue adding exceptions every time any user in the organization has a legitimate need to run a new application.

SRP's were configured in Group Policy and applied to the Computer Configuration side of the console: that is, they affected computer accounts, but not user accounts.

The Path Rule

Software Restriction Policies included four types of rules: path; hash; certificate; and zone. AppLocker has three: path; hash; and publisher. Let's look at these rule types (see Figure 1).

The path rule (available both in SRPs and AppLocker) lets you state that it's OK for users to run applications in a specific folder location. This was never particularly practical with SRPs, and it is generally impractical for most organizations with AppLocker, too. It's just not the case in the real world that all application executables live in a single folder on the user's workstation (or, for that matter, on the network). Creating multiple path rules is possible but becomes unwieldy after a certain point.

Microsoft has pointed out that if the path rule is used with an actual path - for example, "It's OK to run apps that live in \\SW\GOODAPPS" - any user with write permissions can just copy an application to the "good" path and then run it. Of course you can restrict write operations via NTFS permissions as well as with share permissions, so that isn't too serious an objection in my view.

Often, the path rule is often used (ironically) without any path at all, at which point it becomes simply a "name rule." Name rules are easily circumvented: just rename the executable. This simple fact was enough to turn-off many network administrators from the entire concept of SRPs.

In AppLocker, default path rules exist to permit running applications in the Windows folder and the Program Files folder.