Re: What's wrong with application whitelisting?

[Leo Song <song () UOGUELPH CA>]

To identify good guy or bad guy, which one is more difficult, I would pick the latter. Giving the poor catching up rate 
of commercial A/V products, clients are asking "why bother?" and incline to adapt DeepFreeze technology rather than 
CCA+A/V to mitigate viruses, trojans, etc. 


It's hard for me to believe that approach will work, but I'd like to hear your comments, successes or lessons, that's 
something I really like to know and learn, and we can assume DeepFreeze is doable on clients Laptops. thanks. 


Leo Song, Cluster Lead - Networking and Security 
(519) 824-4120 x 53181 CCS, University of Guelph 

----- Original Message ----- 
From: "Gene Spafford" <spaf () CERIAS PURDUE EDU> 
To: SECURITY () LISTSERV EDUCAUSE EDU 
Sent: Tuesday, April 20, 2010 3:15:42 PM GMT -05:00 US/Canada Eastern 
Subject: Re: [SECURITY] What's wrong with application whitelisting? 

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