How to use Microsoft Windows 7 AppLocker for whitelisting applications

    Requires Free Membership to View

From user-installed greyware to drive-by Trojan downloaders, a shocking percentage of business PCs are plagued with unwanted applications. With Windows 7 AppLocker, Microsoft fires another salvo in the ongoing battle to secure business PCs by limiting the programs they run. In part one of this two-part technical tip, we will explore how AppLocker differs from Windows XP/Vista Software Restriction Policies and how to define AppLocker rules.

The desire to block execution of unwanted or unknown applications is nothing new. For years, admins have searched to strike a workable balance between desktop security strength and flexibility, effectiveness and maintainability.

Stripping administrative privileges from end users has met with mixed success and does nothing to block non-business programs that do not require privileges to run. Brute force techniques such as verifying each program's cryptographic hash prior to execution kick off an endless race to keep up with software patches, but easily maintained approaches such as blocking greyware based on registry key or filename/path are trivial to circumvent.

These reasons are why few admins bother with Windows XP/Vista Software Restriction Policies (SRP). Businesses that do use SRP usually develop blacklists: Group Policy Objects (GPOs) that block known malware based upon source network zone, path name, hash or signed certificate. Specifically, SRP rules override a defined default security level by removing restrictions (if the default is "disallow") or adding restrictions (if the default is" unrestricted"). However, because robust SRP rules are hard to define, most businesses default to "unrestricted," giving any program not explicitly disallowed a free pass.

Microsoft's replacement for SRP is AppLocker, now available in Windows Server 2008 R2 and Windows 7 Enterprise and Ultimate editions. For backwards compatibility, GPOs can include both SRP and AppLocker rules. In such cases, AppLocker rules are only applied to PCs running Windows 7, while SRP rules are only applied to older PCs.

Like SRP, AppLocker can allow or deny program launch. However, AppLocker turns policy definition inside out by imposing a default "disallow" stance. After you start the Application Identity (AppID) service and apply even a single AppLocker rule, any program not encompassed by AppLocker rules will fail to launch, displaying the message: "The program is blocked by group policy."

In this way, AppLocker strongly encourages businesses to define whitelists rather than blacklists. Although AppLocker whitelists still require maintenance, they make it easier to reliably identify all of the programs you wish to permit than to exhaustively identify all unknown and potentially harmful programs that wish to block. To understand why, let's look at how AppLocker rules are defined.

SRP rules apply to all users (or all but administrators), but every AppLocker rule must be bound to specified users or groups, making it easier to assemble a collection of coarse and fine-grained rules to meet business needs. Most admins will start with a few coarse AppLocker rules that apply to everyone and then fine-tune with rules that permit "typical user" programs with very selective exceptions.

SRP rules were based on methods that were easily bypassed, too limited for practical use, or too difficult to maintain. AppLocker drops two of those methods, extends the most useful method, and strikes a better balance between effectiveness and maintainability. Specifically, AppLocker rules allow or deny program launch based upon three methods: publisher rules (recommended), hash rules (for programs without signatures), and path rules (as a last resort for everything else).

Publisher Rules allow or deny program launch by checking digital signatures found on signed executables (exe files), installers (msi and msp files), scripts (including batch, javascript and VBS files) and libraries (dll files, eventually). A publisher rule is created by browsing to a reference copy of the program that you wish to allow or deny. The rule then is auto-populated with values obtained from that program's signature: software publisher, product name, filename and (file) version. Finally, a slider is used to adjust rule granularity -- enabling anything from denying all programs by a given publisher to allowing a minimum version of an individual product. As a result, publisher rules are far more flexible and can be applied to many more programs than SRP certificate rules.

Hash Rules can check the cryptographic digest for any program file against a fingerprint previously generated for that file, independent of its name or location. But unlike SRP hash rules, AppLocker can apply hash rules at a per user/group level, with specified exceptions. Although hash maintenance is still a headache, AppLocker reduces overhead by recommending hash rules only for programs that lack usable signatures.

Path Rules check a program file's actual location (local folder, network path) against a required path specification. This method is also used by SRP, but AppLocker path rules are considered a last resort, only for programs where publisher or hash rules would be too onerous or difficult to apply. A good example of a path rule is a one that allows everyone to execute any program in the Windows directory. Assuming that your end users don't have permission to add files to that directory, this is a safe-but-easy way to give everyone permission to run the operating system.

Finally, unlike SRP rules, every AppLocker rule can include specified exceptions. This tweak alone makes it much easier to enforce real-life security policies that so often apply to most (but not all) groups or users. However, note that AppLocker rules can only be applied to (or exclude) groups and users, not Internet zones or individual computers.

Lisa Phifer is vice president of Core Competence Inc. She has been involved in the design, implementation and evaluation of networking, security and management products for more than 25 years, and has advised companies large and small regarding security needs, product assessment, and the use of emerging technologies and best practices.

Send comments on this technical tip editor@searchmidmarketsecurity.com.

Join our IT Knowledge Exchange discussion forum; please use the midmarket security tag.

Windows 7 security guide: Best practices on security for Windows 7

  Introduction: Windows 7 learning guide
  How to use Microsoft Windows 7 AppLocker for whitelisting applications
  Understand the pros and cons of Microsoft Windows 7 DirectAccess
  A closer look at Internet Explorer 8 security features
  The value of booting from a VHD in Windows 7
  How to use BitLocker (and BitLocker To Go) in Windows 7
  A closer look at Windows 7 firewall settings
  How to use Windows XP Mode in Windows 7

This was first published in October 2009

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.