Introduction
There are some key concerns about using whitelisting in your organization to control which applications users can use. In my opinion, whitelisting can be a very powerful tool to help reduce the overall attack surface within your organization. That is, to have the ability to control, one by one, which applications can run and which can’t. However, some issues arise when you start to put the rubber to the pavement in your configuration and implementation of a whitelisting solution. If you can overcome the hurdles that come with deploying a whitelisting solution, I suggest you implement it as soon as possible. If you can’t overcome the hurdles, there are some other settings that I always suggest along with whitelisting that I think should be done at a minimum.
Whitelisting in a Nutshell
Whitelisting (and blacklisting) is a way to create a master list of applications that you want to allow and deny within your organization. Let’s say for example that you are an accounting firm and you run very few applications. The whitelist that you create might just be:
- Word
- Excel
- Quickbooks
- Internet Explorer
However, you know that there are some other applications that you do not want your employees to run, so you also create a denial list, referred to as a blacklist. That might include
- Cain
- Dumpsec
- Ldp
From this example, it is clear what the employees can run and what they can’t run.
Hurdles with Whitelisting
Looking at our simple accounting firm example, we can start to create a list of potential hurdles for our whitelisting solution, even with such a small organization and set of applications.
Missed Applications
Let’s say for example, that the owner of the accounting firm runs a special application to check for stock quotes. That application is called AcmeStock. When you roll out your whitelisting solution based on the above lists, you have forgotten to include the AcmeStock and that application no longer works for the CEO. After rolling out your whitelisting solution, you find that many applications are missed, as each user seems to run “odd, non-disclosed” applications which are now failing and not allowing them to work fully.
Defined, but Not Desired Applications
In a typical whitelisting solution, you will not be able to just list the applications individually due to the fact that there are so many applications that are located in Program Files and System32 that need to be included as part of routine operating system functionality. Thus, you will need to include these folders in your whitelist. When you do that, someone might place a malicious application in one of the folders, which allows them to run the application.
Missing Malicious Applications
There are thousands, if not tens of thousands, of malicious applications that you can download from the Internet. Not to mention home grown malicious applications that can be run on an endpoint. There are very few blacklists that can be created to catch them all. Thus, solving this hurdle becomes difficult and somewhat of a moving target.
Whitelisting Does Not Elevate Applications
If the user is running on the endpoint as a standard user (no local administrator privileges), the whitelist does not elevate them to run applications that require local administrator, like Quickbooks, which in our case will stop Quickbooks from running. Granting the user local administrator privileges to run one application causes a significant attack surface (both to the endpoint and outward from the endpoint), so granting local administrator privileges is not a solution.
Overcoming the Hurdles
As you can see, there are many hurdles to overcome with a whitelisting implementation. Many of the more sophisticated whitelisting solutions have answers to many of these hurdles, but not all.
In order to solve the issue of missed applications, most solutions have some form of application monitoring and reporting service. This produces a list of all applications that are being used on all endpoints, so even seldom used applications can be caught and added to the whitelist.
As for the hurdle with undefined or missed applications, this is a difficult issue to tackle. Most solutions require you to add all of the not desired applications to a blacklist. In my opinion, if you have a least privilege, standard user, endpoint, the applications that might be run which are not defined on the blacklist will not be very useful in an attack or security scenario, so the risk is minimal to have every application listed on the blacklist.
As for the elevation of application issue, I have yet to see a whitelisting solution that includes a technology to handle elevation. Elevating of applications for endpoints is a very common dilemma, which until about 6 years ago was not truly solved. Working with Windows security for the past 10 years, I find that solutions like PowerBroker from BeyondTrust provide the most robust suite of solutions for privilege management and even whitelisting with the newest release of PowerBroker Windows Desktops 5.2.
If you don’t Whitelist, What Is Minimum Endpoint Security?
Due to the overhead for gathering and deploying whitelists and blacklists, many organizations stay away from implementing a whitelist solution to protect endpoints and networks. If you fall into this category, my suggestion for minimum configurations on the endpoint is to use a privilege management solution in combination with an anti-virus solution.
What the privilege management solution provides is a way to force the user to be a standard user, which will negate them from installing and running any application that requires local administrator privileges, except for what you configure them to run. Unlike a whitelist/blacklist solution, privilege management solutions, like PowerBroker, only need to have a list of applications that need elevation, as applications not listed, which require elevation, simply will fail by default.
What the privilege management solution lacks when implemented alone is the ability to deny applications which can be run by a standard user and are not desired. However, creating a list of just those applications which require elevation, compared to the multiple lists of allowed and denied applications, is a small fraction.
Summary
Ideally, organizations will benefit from a comprehensive endpoint security solution. Usually this means privilege management, firewall, security settings, anti-virus, and whitelisting. With a Windows 7 endpoint, firewall and security settings come free. Anti-virus is usually a de-facto standard within a corporation and that solution is already purchased. That leaves privilege management and whitelisting. As we investigated above, whitelisting does not provide a way to elevate applications, so a privilege management solution is a must. On the flip side, privilege management provides a dramatically reduced attack surface, where a whitelist solution in conjunction with it will only provide a small percentage increase in security.
