The question of whether or not application whitelisting has an important role in the future of endpoint security is officially over. It does. Not only that, it is clear that legacy blacklist antivirus has lost the ability to provide any protection to endpoints and instead is relegated to an after the fact role geared at detecting infections and cleaning them up. I highlighted many of these trends toward application whitelisting and the changing role of antivirus in my intro to this series of blog posts. More evidence of this trend came yesterday when Symantec announced that they are adding application whitelisting capabilities into new reputation based technology code-named Quorum. The bottom line in all of this is that if you are responsible for the endpoint security of your company’s PCs and you aren’t thinking about how whitelisting changes things, you should start now.
So if application whitelisting is important in the future how will that transition play out? There are three critical elements of a good whitelisting solution; baselining and protection, cleaning of the device, and finally change management. This post will discuss the first step, baselining and protection.
The most urgent step that every business needs to take to defend its endpoint resources is to provide them protection against new threats that emerge every day with a minimum of impact on IT and the end user. We feel the best way to accomplish this goal is through the use of client side whitelisting. In this approach, a dynamic whitelist is created for each individual PC that whitelists all current executables and protects the system from any unauthorized changes to that list.
This approach provides the most streamlined approach toward implementing a shift toward application whitelisting. In a transition toward this new technology to fight PC viruses, worms and other malware, it is good to take a lesson from the real world medical community that fights infections; “primum non nocere”, translated “first, do no harm.” It is critically important that the cure is not worse than the disease. If a transition to this new technology comes with significant operational costs and enduser disruption, then it will fail. Client side whitelisting addresses this by providing the protection against all new threats without major work disruptions.
The alternative to this approach is through the maintenance of yet another centrally managed list. This list will contain a master list of all known and approved applications and will be used to baseline devices that are adding whitelisting. There are two approaches to the maintenance of this list that can loosely be categorized as cloudlisting or crowdlisting respectively. Both maintain a centrally managed list, but the way new applications get on the list is different. With cloudlisting, the vendor takes responsibility for the care and feeding of the list and validation of applications on that list. This is analogous to today’s blacklisting but for good applications not bad. With crowdlisting applications get submitted to the master whitelist by approved individuals and vetted by the company maintaining the list and other contributors.
The drawback of both of these approaches, especially when getting started, is that the lists will necessarily be incomplete. There is no way, in this rapidly evolving world of applications, that a list can be up to date on all applications. What happens, then, is that inevitably unknown applications will be given a score or reputation assignment and a decision will have to be made about their validity. This process during deployment incurs costs and can result in disruption of important applications if a wrong decision is made.
A second drawback to these approaches, but is more acute in crowdlisting, is that malware can make it onto the whitelist. Given the vast amount of maintenance required to keep a list like this up to date, it is inevitable that malware will make it onto the whitelist that will need to be cleaned and checked by blacklist technology to prevent this from happening.
It is no surprise that the antivirus companies favor this latter approach because it preserves their business model for list subscriptions. The drawback that is highlighted toward client side whitelisting is that when you baseline it it may already contain malware that makes it onto the list. The first point to consider here is that this concern is significant evidence that blacklist antivirus simply isn’t doing its job and that a change to a protective technology is more critical than ever. The second point to make is that we agree that some malware will get listed, what we disagree with is how and when to get that off the device to purify the system.
How and when this happens is the topic for the next post in this series focusing on getting to a clean device. Ultimately we don’t believe that this step is best executed at the outset when so many people will be getting used to a new technology and when the philosophy “primum non nocere” is most critical.
[...] Step 1 Protect – Organizations desperately need to implement a system that can protect their systems against zero day attacks. [...]
[...] without ever having to know about them. This was the focus of a recent blog entry titled “Endpoint Protection – A Case For a Rational Transition to Whitelisting: Step 1 Protect.” Protecting critical endpoint systems against unknown threats is possible today with [...]
[...] to move toward a system that can prevent infection in the first place. As we highlighted in our Rational Transition to Whitelisting series of posts, we think the answer to that problem is application [...]
[...] An easy adoption process that implements protection and does no harm. The first goal of an application whitelisting solution should be to stop new threats without disrupting any existing applications. [...]
[...] Protect – First we must baseline our systems to prevent any new infections [...]