Educause Security Discussion mailing list archives

Re: What's wrong with application whitelisting?


From: Brad Judy <win-hied () BRADJUDY COM>
Date: Tue, 6 Apr 2010 08:55:04 -0400

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






Current thread: