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:
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:
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:
Or if you want, you can also check out some of Tyson's latest publications:
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)
With more than ten years of experience in IT, Tyson Kopczynski has become a specialist in Active Directory, Information Assurance, Windows automation, PKI, and IT security practices. Tyson is also the founding author of the Windows PowerShell Unleashed series and has been a contributing author for such books as Microsoft Internet Security and Acceleration (ISA) Server 2006 Unleashed and Microsoft Windows Server 2008 Unleashed. He has also written many detailed technical papers and guides covering various technologies. As a consultant at Convergent Computing, Tyson works with and provides feedback for next generation Microsoft technologies since their inception and has also played a key role in expanding the automation and security practices at CCO. Tyson also holds such certifications as the Certified Information Systems Security Professional (CISSP), the SANS Security Essentials Certification (GSEC) and SANS Certified Incident Handler (GCIH), and the MCTS (Application Platform, Active Directory, and Network Infrastructure).
Certifications:
Publications:
Other Stuff:
The Leader in Network Knowledge
Better whitelisting
Applocker has improved Microsofts approach to white listing but it still requires creation of rules and for more complex environments those rules may not be as simple as the ones illustrated in the article.
More importantly applocker is not a security tool. Its focus is on giving permission to use applications. It does not (by default and recommends against)protect against a malicious process or user replacing a .dll or other executable file that is not a top level application.
White listing is a good idea and Savant Protection is a white listing product that whitelists all executable functions without requiring rules or requiring IT to manage the whitelists.
Post new comment