Challenges with Traditional White Listing

White Listing is not a new concept. It has been around for a long time and refers to the ability to run only a known white list of “good” programs on a device. Traditionally the security solutions such as anti-virus have focused on the black list concept where they look for known “bad” stuff. A big part of the both a white list and a black list approach is that the lists need to be constantly updated. We have all experienced this with our anti-virus solutions which download updates and signatures of newly discovered malware to add the black list.

White listing has not been widely adopted because of the difficulty in creating a white list. If you fail to enumerate all the “good” software in the white-list the device may fail to function. Note this is different than a black-list as in a black-list if you omit something, the device will still function but some malware may run. Given that the white-list has to be complete poses a big challenge as the machine is updated. Every time the machine is updated the list needs to be updated.

The most recent approaches for white-listing include repositories of known good software collected either by the US Department of Defence (http://www.nsrl.nist.gov/ ),  or from the National Drug Information Center (http://en.wikipedia.org/wiki/HashKeeper/). These have formed the basis for white-listing approaches provided by companies such as Bit9 etc. It is very difficult to lock down a machine based on these white-lists as they are not complete. The best you can do is use them to report programs which are running but not in the “known” list. In addition just because something is in a global whitelist does not mean that it should be allowed to run in your enterprise.

Most vendors punt on this problem by creating a “gray” list. What ends up happening is that the gray list grows over time and essentially the system is not secure.  Another manifestation of both the issues highlighted above is think about a program which is in the whitelist and it gets updated: what should happen? should the updated program be allowed to run? Solutions like Bit9 and others don’t maintain integrity of the machine, for example write protect the binaries in the whitelist, so a malware can overwrite these binaries and either cause a denial of service attack (system won’t boot) or the whitelisting software will quitely push the binary into the gray list and voila the system will run but compromised. (Note: some vendors may say you can set up write protection file by file, but this is useless as no-one is going to do this manually and unless it is integrated and automatic with the whitelist it is not effective)

Another challenge with solutions like Bit9 is that they don’t protect the integrity of the running program. So if a whitelisted program is running and is compromised (buffer overflow), not only can the “external code run” but it can also make changes. Any whitelisting solution without system integrity (on-disk & in memory) is not a good security solution.

The other dimension that all whitelisting vendors today (except solidcore & now MFE) ignore is what to do with scripts, java  etc. Bit9, Symantec etc  only tend to cover OS images or application binaries. It is outside the scope of most of these solution to cover custom applications or to cover applications that are written in languages such as Java (several POS applications tend to be Java based). So you can use whitelisting from Bit9, but it can be bypassed by writing a Java application or a vbscript?  For most enterprise desktops again this is not a viable solution. The breadth of the solution is not a nicety, its a necessity.

Continuing along the same theme: Bit9 or Symantec don’t provide whitelisting of kernel mode components. Thus you can add a device driver to the kernel or something during bootup.  This is something that is architecturally very difficult and is not something that can be retro-fitted in.

To summarize, does your whitelisting solution breadth (scripts, binaries, libraries), does it lead to a large gray list, if it works of a global list: how good is the list, which country is it compiled in, if its good in the list should you run it?, does the whitelisting solution guarantee system integrity (on-disk and in memory)?Does the whitelisting cover kernel components?

In the next part we will look at a more technical view of how you need to carefully assess how the solution is built and how easy is to bypass?