Incident Response, TDR

Whitelisting – White horse or white lie?

Some people are talking about a technique called “whitelisting” as if it were the knight on a white horse that is going to save the world. It the fantasy novels.

I think I can lay claim to a certain amount of expertise when it comes to whitelisting. Whitelisting was fundamentally my job at Microsoft for over seven years. My job was to make sure that Microsoft didn't release or digitally sign any infected code. How did I do that? I used a heck of a lot of, you guessed it, anti-virus software. I used NOD32 to give me the absolute best shot at detecting unknown threats that no one had ever seen before and there were no signatures for.

Here's how the whitelisting fan club story goes. Anti-virus cannot protect you against new threats because they don't have signatures for them yet. Whitelisting only allows good programs to run, so it prevents zero-day attacks.

To start with, NOD32 has been detecting and blocking threats we have never seen before for several years now. We, like many other AV companies, use a technique called heuristics that allow us to identify unknown threats without signatures. The whitelist fan club hasn't looked at anti-virus technology since Windows 95 was a shiny new operating system.

Whitelisting does not only allow good programs to run, it allows any program you claim is good to run. If you put a bad program on a whitelist it will run and do bad things, regardless of whether or not anti-virus products can detect it heuristically or with signatures.

There are a variety of types and approaches to whitelisting, so let's look at some of them.

Digital signatures are designed to whitelist programs and websites. The idea is that if a program or website has a digital signature from a trusted “certificate authority” then you can safely use the program or website. Microsoft uses digital signatures on many of their executable files. If the file is changed, the digital certificate breaks and you don't run it. If you trusted the wrong certificates you could be had. That is one attack against this type of whitelist.

Whitelisting websites is another approach to security. The idea is that you only go to good web sites. This falls apart completely when a good website is hacked, as was the Miami Dolphins' website around the time of the last Super Bowl. Hackers placed an exploit on the site that would download a trojan to compromise users' computers. There have been thousands of good websites that have been compromised. MSN,, and recently all come to mind as high-traffic, high- profile, “good” web sites that would certainly appear on such a white list.

Whitelisting programs is yet another type of whitelisting. Some would say that this is the Holy Grail. Even if you go to a whitelisted website, the bad program that is being downloaded will not run because it isn't on the white list.

The obvious way to get passed this whitelist is to use an exploit that patches an in-memory process. There is no need for a file and the technique is used by non-persistent rootkits and other threats that can disable security software, such as anti-virus, firewalls, white listing programs, or most anything else.

How do companies whitelist programs? Why, they use a ton of anti-virus software, that's how. The approaches used for whitelisting are flawed in that they don't verify that a program is good, they verify that they trust the publisher and that no known threats have been found in the software by programs that they claim can't detect new threats. The only way to know that a program is actually good is to have access to the source code and review that, or disassemble it and go through the entire file to see what it is doing. This is not done by whitelisting companies and cannot be done by these companies so they fall back on trusting the publisher and using anti-virus software.

In practice, bad programs are whitelisted all of the time. Wouldn't you call a program with a serious or even critical security vulnerability “bad?” Of course you would, but all of the programs, such as Acrobat, QuickTime, and a slew of operating system files from Microsoft, Apple, Linux and others would be whitelisted. The problem is that you can't patch these files until the patched file is also whitelisted. Do you keep the unsafe file on the whitelist or remove it? In some cases a company may want to keep on using the flawed file for legitimate business reasons, but if it isn't whitelisted then they need to create exclusions and roll those out.

The sheer number of new programs that are genuinely good and are being developed each day makes keeping a whitelist a very time intensive and expensive task.

Whitelisting can be a valuable addition to a defense-in-depth strategy, but it is not a complete defense. Can you imagine telling someone that since airbags add safety to cars you don't need to wear your seatbelt any more? Well, the person who tells you that whitelisting replaces anti-virus is like an airbag calling a seatbelt obsolete.

- Randy Abrams is director of technical education, ESET

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.