Whitelists / Blacklists and AppLocker Goodness

It so happens that the topic of Whitelists vs. Blacklists comes up a lot when I’m talking to clients. The questions seem to always revolve around the pros and cons between these two methods of protection. Sadly, for some reason, there seems to be fear around implementing Whitelists in relation to how applications/code is executed on systems. That being said, I thought this might be a good discussion…

By definition, a Whitelist is a list of entities that are granted a set of privileges (access, services, validity, etc.) within an environment. Conversely, a Blacklist is also a list of entities. However, in this case they are denied a set of privileges. To better define these concepts in relation to how they are implemented to control the execution of applications and code. A Whitelist is solely used to define what is allowed to be executed. Whereas, anything that is not included on the Whitelist cannot be executed. On the other hand, a Blacklist is solely used to define what cannot be executed. Therefore, anything can be executed provided it hasn’t been “Blacklisted”.

After reading the previous paragraph, you must have already spotted the two glaring issues that are the topics for discussion. First, most organizations are apprehensive about going the Whitelist route because of the impact it might have users and the associated increase in IT resources to manage the list. On the flip side, most organizations also see that explicitly denying things via a Blacklist is neither the most effective nor proactive way to protect their environment. So the question always boils down to: What to do, and why?

As always, my answer to such a question is that the best approach depends on the solution that is being used to prevent the execution of applications and code. For example, if the solution contains a very basic enforcement method that implements rules as a literal yes or no statement based on the executable name or hash, then the best choice might be to solely use Blacklists. After all, using a Whitelist with such an enforcement method can be a nightmare to manage while also dramatically impacting end-user productivity.

However… I might also make the statement that using such a feature limited solution set is a bunch of hogwash. While this is a strong statement, it is one that I have to make given that the year is 2009, and not 2000. Therefore, as we quickly close in on 2010, it’s important to note that there is a plethora of end-point protection solutions/technologies now present in the marketplace. Luckily, the engineers of these solutions/technologies are bright individuals and have also provided ways to implement execution rules such that the Whitelist approach can easily be taken.

A really great example of this can be found with Microsoft’s AppLocker. With this solution the methodology for defining rules is flexible enough to effectively balance enforcement, management, and productivity. Now, I wouldn’t say that AppLocker is the end-game in end-point protection. But as a built-in targeted solution for Windows, it has the ability to get the job done. To expand on this notion, let’s pretend that I want to define a set of AppLocker rules such that the following is enforced:

1. Administrators can execute and install all applications.
2. Power Users can execute all applications.
3. Users can only execute the applications that are allowed.
   • All Windows related binaries.
   • Microsoft Office 2007 or later.
   • Internet Explorer IE8 or later.
   • Explicit Binaries for Third-Party applications.

Well… all of this is possible, and fairly easy to achieve. For example, use the following steps to allow the execution of All Windows related binaries:

1. Using the AppLocker interface, create a new rule.
2. Set the permissions to Allow – Everyone.
3. Select the condition as Publisher.
4. Next, find a Windows related executable. My suggestion is to use explorer.exe.
5. After selecting the reference executable, change the rule’s properties so that enforcement is determined by product name (MICROSOFT® WINDOWS® OPERATING SYSTEM).
6. Click Create.
7. Done…

See… setting up the rule is not that hard. And, given the fact that you can build-in a certain amount of flexibility based on a user’s rights, I see no reason why end-users cannot be limited to execution only allowed applications. Just my two cents…

If you like this, check out some other posts from Tyson:

• When a computer science degree matters, and when it doesn’t
• Since when did cloud computing become/need a manifesto?
• Why would one phish using a Certificate Authority (CA) as bait?
• Would I trust you, if everyone else trusted you?
• Here is a good question: Is scripting programming or just systems administration?
• PowerShell boy and the case of the missing cmdlets!
• Fun with PowerShell 2.0 Eventing!
• Creating a custom 404 page to handle link redirection for ASP.NET web applications

Or if you want, you can also check out some of Tyson’s latest publications:

• Windows PowerShell Unleashed (2^ndEdition)
• Windows Server 2008 Unleashed (Yes, I did help on this book)

Lastly, visit the Microsoft Subnet for more news, blogs, and opinions from around the Internet. Or, sign up for the bi-weekly Microsoft newsletter. (Click on News/Microsoft News Alert)