Re: What's wrong with application whitelisting?

["Everett, Alex D" <alex.everett () UNC EDU>]

Doesn’t work against mebroot.
I am not a big fan of ‘let the computer get compromised, then, later reboot’ in general, however.
It makes sense for some cases, but I am not sure about on client laptops.

Sincerely,

Alex Everett, CISSP, CCNA
IT Security Engineer
University of North Carolina
Chapel Hill
919.445.9393

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Leo Song
Sent: Thursday, May 13, 2010 12:56 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] What's wrong with application whitelisting?

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