Re: What's wrong with application whitelisting?

[Gene Spafford <spaf () CERIAS PURDUE EDU>]

I missed the earlier discussion here, but as the designer of  whitelisting solutions, I wanted to throw in some 
comments.

First of all, malware and attacks are increasingly polymorphic and built to cloud some security checks.  As such, any 
of the older blacklisting approaches are increasingly insufficient.  Repeated test results I've seen indicate that 
commercial anti-virus only catches 40%-60% of current threats, and that number is not likely to get better.

There are (loosely speaking) 9 general kinds of whitelisting approaches that I have seen, along two axes:
  Axis 1:
        * scan/compare and warn (this is akin to current and traditional virus and vulnerability scanners )
        * compare and replace/quarantine (akin to integrity shells such as what Cohen described in the 80s, and used in 
many current anti-virus)
        * compare and block (e.g., stop execution of unrecognized/allowed items, as is done with Core Trace)
 Axis 2:
        * compare against prior states (e.g., such as done with Tripwire)
        * compare against some database of values that are common or claimed to be authentic (e.g., bit9)
        * compare against vendor-supplied, high-assurance, signed signatures (e.g., SignaCert)

You can get all 9 possible combinations, and it possible for all 3 activities on Axis 1 to be paired with any of the 
whitelists generated in Axis 2; any 2 or all 3 of the actions on Axis 1 can be combined, too. 

The highest level of protection is to use the best (signed, high-assurance) signatures coupled with something that 
replaces (fixes) or quarantines questionable binaries before they can be run. 

Whitelisting can be applied against groups to ensure that the latest patches are in place, and that the group has 
compatible patches and versions applied. 

One of the most important qualities for assurance is the quality of the whitelist -- both in gathering and in 
protecting it.  Many years ago, I did an initial design of a system that would involve collection of signatures of all 
production binaries (including all patch levels) from all vendors **at the vendors** to derive a high-quality database 
of signatures.  These would be protected cryptographically.   I came up with this after realizing that Tripwire might 
not work properly when someone installed it on a system that might have already been compromised (and thus, its set of 
signatures would not be of uncontaminated software).   This idea was then developed by Wyatt Starnes (former CEO of 
Tripwire) into the SignaCert solution with me as an advisor to the company.   Wyatt has obtained agreements from a 
broad range of vendors (including Micrososft, Sun, Oracle, Red Hat, Cisco, Intel, etc) to obtain signatures for every 
bit of software from the "golden master" stage, often before the product goes to market.  A "trust score" is also 
associated with these measures to represent different levels of confidence (to accommodate signatures that might be 
collected from other sources).    Some other companies harvest signatures from net repositories and software they 
purchase or download; obviously, these do not have the same assured provenance.

A second quality of the use of whitelisting is the user interface -- who uses the solution and what are the 
alternatives involved.   Scanners used by system admins are very different from end-users trying to execute programs.  
(This is my Axis 1, above.)  It is important to realize that this is also a factor in blacklisting -- who runs the 
checks against the list, when, and what happens on a match.  Whitelists can actually be combined with blacklists in 
existing interfaces to provide an even greater level of protection; some companies such as McAfee are doing this.

So, in the service of full disclosure, I did the original conceptual design of both Tripwire and SignaCert products and 
have some financial interest in both, so read the above through that lens.

--spaf

Attachment: smime.p7s
Description: