An Introduction to AppLocker (Part 1)

by [Published on 25 Aug. 2009 / Last Updated on 25 Aug. 2009]

Why software restriction policies are ineffective and how AppLocker can help.

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


A new Windows 7 feature called AppLocker attempts to address everything that is wrong with software restriction policies in previous versions of Windows. This article series explains why software restriction policies are ineffective and how AppLocker can help.

Over the last several generations of Windows, if you wanted to restrict which applications users were allowed to run, your only real options were to use Software Restriction Policies, or a third party utility such as Bit9’s Parity. The problem with using software restriction policies is that, to be perfectly frank, they really are not very good. While it is possible to lock down user workstations using software restriction policies it tends to be very difficult to create policies that the users can’t easily circumvent.

I will never forget a conversation that I had with someone in Redmond many years ago. Software restriction policies were about to be introduced for the first time, and I had just seen them demonstrated for the first time. During the demo I had noticed that it would be fairly easy for a user to get around most of the types of policies that could be created, and I asked the presenter what good software restriction policies were if they were so easy to circumvent. I was told that software restriction policies were in their first generation form, and that they would get better over time. I was also told that even though users could circumvent some of the policies that users wouldn’t be able to do so by accident. They would have to perform deliberate actions to get around the policies, and at that point you could terminate them for violating your corporate security policy.

I have to tell you that the answer that I was given to my question really didn’t make me feel any better, but I accepted the fact that software restriction policies were brand new, and assumed that they would be greatly improved in the next version of Windows. To my disappointment, Microsoft only made minor changes to software restriction policies in Windows Vista and in Windows Server 2008. They added a new type of rule called network zone rules, and introduced a new security level called Basic User, but that was pretty much the extent of the changes.

The good news is that in Windows 7, Microsoft has finally redesigned software restriction policies. This newly redesigned feature has also been renamed to AppLocker. Do not expect AppLocker to be as comprehensive as third party desktop lockdown solutions, but it is quite a bit better than software restriction policies were.

Software Restriction Policy Shortcomings

Before you can really appreciate AppLocker, you need to understand what it was about software restriction policies that made them so terribly ineffective. Besides, AppLocker still supports the same types of rules as the software restriction policies did, so I think that it makes sense to spend the rest of this article giving you a quick crash course in software restriction policy rules.

Software restriction policies are made up of various types of rules. You can create certificate rules, hash rules, path rules, internet Zone rules, and network zone rules.

Certificate Rules

Certificate rules are probably the most secure of the available rule types. They allow you to either permit or to deny applications based on the application’s digital signature. The problem with this type of rule is that when software restriction policies were first introduced with Windows XP, almost nobody signed their code. Even today you will find software vendors that do not attach a digital signature to their applications.

Another problem with certificate rules is that they have too broad of a scope. If I choose to allow applications that have been signed by Microsoft, then all Microsoft applications will be allowed unless I create a separate rule with a higher priority that blocks a specific unwanted Microsoft application.

Hash Rules

The second type of rule that software restriction policies support is a hash rule. The idea is that Windows can create a mathematical hash of executable files, and use that hash to uniquely identify the application. I have to admit that hash rules were a good idea at the time that they were first introduced, but today they are impractical. Anyone who is responsible for match management within an organization knows that we are bombarded by patches at an alarming rate. Any time that you patch an application, the hash changes for any files that have been replaced, rendering previously existing hash rules obsolete.

Path Rules

Path rules are one of the weaker types of rules. They allow or block applications based on the path in which the application has been installed. This can be a file system path or a registry path. The problem with this type of rule is that if a user has sufficient rights to install an application, then they also have sufficient rights to move that application to a location that is not going to be affected by path rules.

Internet Zone Rules

Internet zone rules are classic examples of a good idea that was poorly implemented. The basic idea behind Internet zone rules was to keep users from downloading and installing applications from the Internet by taking into account the Internet zone that the site that the file was downloaded came from… There are a few problems with this though.

For starters, Internet zone rules only apply to MSI files (Windows installer packages). Another problem is that Internet zone rules only apply at the time that the file is downloaded. This means that if a user downloads a ZIP file containing an application, then an Internet zone rule will not prevent that application from being installed.

Network Zone Rules

Network zone rules are similar to Internet zone rules, except that rather than examining the Internet zone that a file is being downloaded from, they examine the network location where the file currently exists. For example, you could create a policy that only allows users to run applications that are installed on the local computer. The big problem with this type of rule is that before it can be engaged, the application in question has to already be somewhere on your network.

The Heart of the Problem

I have talked about some of the shortcomings of the various types of rules, but the real heart of the problem involves the fact that software restriction policies are designed to block various types of applications. The reason why this is a problem is because there are an infinite number of applications that are not authorized for use on your network, but a finite number of applications that are authorized. It is easier to permit a specific set of applications than it is to try to block a large number of unknown applications. Thankfully, AppLocker provides this capability through the use of whitelisting. I will introduce you to this and other new features in Part 2.


In this article, I have explained that software restriction policies tend to be a less than ideal solution for controlling applications on network desktops. In Part 2 of this series, I will begin explaining how AppLocker addresses these shortcomings.

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

See Also

The Author — Brien M. Posey

Brien M. Posey avatar

Brien Posey is an MCSE and has won the Microsoft MVP award for the last few years. Brien has written well over 4,000 technical articles and written or contributed material to 27 books.


Featured Links