Re: What's wrong with application whitelisting?

["Howe, Joe" <joe.howe () MAIL UTEXAS EDU>]

Along the lines of Brad's comments, "path whitelisting" is often more feasible than "application whitelisting".  For 
some areas, this could be the right balance between security and usability.

We have begun live deployment of AppLocker/SRP for path whitelisting for Windows machines in Active Directory.  
Admittedly we are initially deploying to an administrative staff but the longer term rollout will include enough 
faculty and researchers to have a good idea of how it works in these environments.  There are few extra locations we 
had to whitelist - SYSVOL on the domain controllers and a few specific places that are part of application 
virtualization packages.

Our users had been seeing the effects of "fake AV" both at home and work so we moved ahead more quickly with our 
testing and implementation.  We already had users running without admin rights.  Some users have a secondary domain 
account with admin privileges when they need this level of access (typically laptop users on the road).  There has been 
very little impact - although it is the first place we jump to blame when there is an error (human nature) and it is 
yet another thing for techs to understand and check (adding to AV, firewall, disk encryption, config mgmt, privilege 
issues and now Applocker).

We consider the *risk* of users deliberately installing unapproved software to be a separate issue than what we are 
trying to protect against with these measures.  They are definitely ways that malware could make its way to the machine 
with admin level consent, but we are focused on negating the impact of user mode malware from website downloads, email 
and similar vectors.

This incremental approach is based on "the perfect is the enemy of the good" - as we play the chess game of information 
security,

Joe Howe


UT Austin
Cockrell School of Engineering

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Brad Judy
Sent: Tuesday, April 06, 2010 7:55 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] What's wrong with application whitelisting?

Application "whitelisting" doesn't have to be a long list, but it does tie into removing admin rights.  If you use the 
native software restriction policies in Windows GPOs, you can simply allow all applications residing in C:\Windows\* 
and C:\Program Files\*, and allow link files from anywhere (for those shortcuts on the desktop and start menu).  
Naturally, if you have applications running from other locations, you'd have to add those paths too.  While not as 
tightly locked down as hashes, it should be way easier to maintain and still address the core issues *if* users do not 
have admin rights.  This means they cannot write to the Program Files or Windows directories, nor can malware running 
under their account.  Malware is forced to execute from somewhere writable, like their profile, which is forbidden by 
the policy.   This article goes into details on setting up SRP and the different options (hash, certs, path, etc) - 
http://technet.microsoft.com/en-us/windows/cc507878.aspx   and this page describes the basics of this arrangement - 
http://www.mechbgon.com/srp/  Note that it doesn't mention adding Windows and Program Files because this is part of the 
default configuration (the two built-in rules for the registry paths that point to the systemroot and programfilesdir 
paths), but it does mention adding the extra Program Files directory for 64-bit systems.

I expect many of the third-party options also have path-based software policy options.

As with any software restriction policies, lots of testing is required to see if any legit software placed executables 
in a user's profile or other location.  You can put in broad exceptions on file space that isn't user-writable, but it 
should be very specific for user-writable space.

Brad Judy

Emory University

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Eric Case
Sent: Monday, April 05, 2010 5:22 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] What's wrong with application whitelisting?

Hi Lewis,

My responses are in line below . . .


Eric Case, CISSP
eric (at) ericcase (dot) com
http://www.linkedin.com/in/ericcase

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Watkins, 
Lewis
Sent: Monday, April 05, 2010 11:23 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: [SECURITY] What's wrong with application whitelisting?

Colleagues,  Please help me understand something, that I have been trying to make sense of for awhile and just don't 
get.   What's wrong with "application whitelisting"?   As best I can tell, application whitelisting has very low 
penetration in higher education, and I simply do not understand this.   There must be issues and dynamics of which I am 
unaware to explain this.   My confusion is based on the following:

-  Security professionals seem to agree that anti-virus software is no longer working.   No single product does the 
job, and it is not feasible to run multiple products on each device.
-  Any executable that anti-virus software will stop should also be stopped by a whitelist, since the application would 
not be on the approved list.
[Eric Case]  The whitelist will be long; it will have to cover every exe, dll, ocx, etc. for all versions in use, were 
in use and might become in use.  Could you put a whitelist on the CS workstations were students are building apps?  
What about research computers also building custom apps?  Maintaining the list will take a lot of time, money and 
effort.

-  Zero-day attacks are a major threat.   Anti-virus is particularly bad at stopping zero-day attacks.   Application 
whitelists are particularly good at stopping zero-day attacks.
[Eric Case]  I don't think so.  You whitelisted the app with the 0-day vulnerability.  If the exploit does not upload a 
new binary your whitelist only gave you a false sense of security.  When the patch for the 0-day comes out, you will 
have to add it to the whitelist before you push the patch.

-  Universities use whitelisting on firewalls (i.e. we don't shut down just the ports that prove themselves to be bad - 
we open only those that are needed. )
-  Universities use whitelisting for people (i.e. we don't let everyone in the world have an account until they prove 
to be bad.  We maintain a list of approved users.)
-  However, universities use blacklisting for applications.   We tend to allow any application that can find its way 
onto our desktop computers to run.   When a program proves to be bad, we spend lots of labor and effort re-imaging the 
computer - then we do it again later.    To the extent that application whitelisting would help prevent this, costs 
would be reduced and IT could concentrate more on value added efforts.
[Eric Case]  We know that security is about tradeoffs, but what are they with whitelisting?  (just a few off the top of 
my head)

*         In institutions where users have admin access:

o   Would the users also be able to whitelist anything they wanted?  If not, does whitelisting remove some of their 
admin access?

o   Does allowing users to whitelist anything negate the whole point to whitelisting?

*         In institutions that have locked down admin access:

o   What and how much is gained from whitelisting?

o   What and how much is lost in maintaining the list?

In "The Psychology of Security<http://www.schneier.com/essay-155.html>" by Bruce Schneier, talks about the Prospect 
Theory.  (I think this theory is a game changer for how we should present (frame) risk.)  Schneier says:
What does prospect theory mean for security trade-offs?  . . .  First, it means that people are going to trade off more 
for security that lets them keep something they've become accustomed to--a lifestyle, a level of security, some 
functionality in a product or service--than they were willing to risk to get it in the first place.  Second, when 
considering security gains, people are more likely to accept an incremental gain than a chance at a larger gain; but 
when considering security losses, they're more likely to risk a larger loss than accept the certainty of a small one.

Applied to whitelisting, I read that as, People will accept a smaller gain (AV software) than a chance at a larger gain 
(and expense (whitelisting)).

I think, as other have pointed out, whitelisting has it use in labs (that are locked down) and in business areas that 
are more static.  I do not see it being used anywhere users have admin access or where IT cannot respond to installs in 
a timely manner.

Does this help?
-Eric