Whitelisting applications versus Anti-virus

There was an interesting article in The Register yesterday called “the decline of antivirus and the rise of whitelisting“. It discussed the relative merits of using a whitelist to allow only known good programs to run, versus using traditional anti-virus (AV) to let everything run except things you know are bad. The comments to this article also raised a number of valid points, some academic and some based on real-world experience.

The obvious flaw in the traditional AV approach is the difficulty in keeping up with new malicious software rapidly enough to avoid infection. Whitelisting gives you a little more control but still takes substantial effort in a large environment, and is harder to delegate out to a third party without leaving so many loopholes as to render it pointless.

Subscribing to some kind of global whitelist is only useful for making it easy to get the hashes for a bunch of apps, so you could say “let all the components of MS Office 2007 Premium run” without having to dig through them yourself. Delegating your entire rulebase to someone else does not make sense to me, as it would allow some apps to run for which you have no licenses and others which have no rightful place in your environment, such as spyware. Look at how many spyware ‘admin tools’ are not picked up by AV products due to threatened legislation, the same problem would hit whitelist suppliers.

With AV I am happy to accept that pretty much all the things they block are actually bad. I have never personally suffered from any real issue with a false positive. I don’t need to believe they do catch everything (that’s a different question) but I have great trust that what they do catch is right.

My own experience of whitelisting

Back when I was single-handedly running a network of about 100 Windows 98 machines I used policies to manage the environment (old school tattooing .pol file stuff before AD and proper Group Policies). I adopted a whitelisting approach to manage what was being used – anything not on the list simply could not be run by anyone on any machine.

The main point of this was not to stop accidental malware (although it certainly helped) but to prevent employees installing unlicensed, unmanaged software including games or (potentially) spyware, keyloggers etc. In a 2000/XP/Vista world this would be less of a problem, but don’t forget there was no ‘admin’ in 98, all users had all the rights they wanted, by default. Setup.exe was not on the whitelist, of course.

Anything not on my whitelist could not be run – obviously there were ways round this but the vulnerability was minimised as far as possible. The firm had a couple of weeks of minor pain after rollout while we found all those odd little bits of software that one user in accounts had, or the receptionist, but after those two weeks we had a solid solution. Catching these oddities was also useful in terms of checking what was in place, were we licensed, where did these apps keep their data and was it backed up?

One user found that when he tried to eject his CD tray to play a music CD he was told by an error message that this was banned by admin! This turned out to be because he had a CD burning  program which got hooked by the eject operation. This was not on the list so he could not run it. About ten minutes later his machine had an exception for this program and we carried on happily for about six months.

We also ran ‘traditional’ Anti-virus software (enumerating badness) and used heuristic scanning options in some cases. This was partly because these old ’98 policies could not tell the difference between ‘good’ winword.exe in the right folder and ‘bad’ Virus calling itself winword.exe.

What stopped us in the end?

A dumb supplier of forms software who changed from having their new form templates downloaded as zips and made them self extracting executable files – named differently for every form and every version (once a month in some cases). At first we just weakened security for one or two users, then it became three or four who needed to do this and the rot set in. An impending merger and major upgrade were the final nails in the coffin of a project I was proud to have done and which had helped enormously in controlling the network, getting a better handle on our licenses and generally reducing support headaches.

What barriers do you have to overcome for a whitelisting approach to work?

You must have a tightly controlled environment in the first place – a standard build image in which you know what is installed. Change management processes to get things added to the build or to your deployment tool (GPSI, SMS, SpecOps Deploy etc) should tie into the whitelist too. The larger and more distributed your environment becomes, this obviously gets exponentially harder to achieve just because of the variety and complexity that brings.

These days, do not let normal users have admin rights. At all. Ever. I was at a Microsoft conference recently when someone asked about the Vista group policies for whitelisting via executable name and said that someone could just trivially rename “virus.exe” to “mspaint.exe” (or whatever) and get round it. This of course presumes they have admin rights to alter the names of things in Windows or Program Files, which they should not have. Using a Linux distro CD could also get round this, which is where encryption technologies such as BitLocker and/or EFS come in. Protecting the front door while leaving the back door open is a waste of time. Whitelisting only works as one part of a an overall security policy, not a reason to ignore all the other vectors of attack.

About ukcrmguru
I'm an MVP for Dynamics CRM, consultant, Microsoft Certified Trainer and self-confessed geek. I also lead the UK CRM User group when I'm not too busy with all that.

7 Responses to Whitelisting applications versus Anti-virus

  1. Pingback: Using anti-virus software to keep the elephants away « Getting IT Right

  2. Idetrorce says:

    very interesting, but I don’t agree with you

  3. steve says:

    Interesting… the whole issue for me with supporting a large number of users is that I believe you have to have a multi-layered approach to security. You could have the following layers:

    Employee education
    anti virus
    white listing

    The point is that there isnt one solution for the issue of malware.

  4. argoran says:

    very interesting; I agree that with larger organisations it starts to fail – the weak link which is ” people ” kicks in; I have been working in an org of around 30,000 + and used one of the well known whitelisting applications out there – however the problem isn’t with the application it’s with the sheer number of files per application, and I know for a fact that no one will ever ( unless in the case of a disaster ) look into every single file, which leaves the door wide open to malware and spyware that come bundled with vendor’s software.
    The other issue is that we trust software vendors blindly when it comes to corporate software, it’s “unthinkable” that a vendor would “knowingly” put malicious code in their software as if the developers were saints – I as a developer know that that isn’t the case, infact one of my colleagues once told me that while he was working in a reputable software house, they were told not to fix all the bugs purposely so that they have another version to release and bug fixes ..i.e. money! if that isn’t malicious code then I don’t know what is – and with this problem whitelisting definitely fails.

  5. Keith says:

    Would whitelisting help with virus/apyware issues such as Internet Explorer BHO’s (browser helper objects)

  6. Adam Vero says:

    I don’t know of any tools to control those in a whitelist type fashion, although I think some of the anti-spyware solutions allow you to specify exceptions to prevent false positives

    If anyone does know of smart ways to manage these on an enterprise-wide basis then please post a comment to share these solutions (and please declare any interest if you are the software’s author, distributor etc).

  7. Kraig Godden says:

    Guys great article, its always that hard question to answer and one that i am most interested in. I have been testing an environment at our training centres to use whitelisting, and to be honest i completely agree with argoran. I also have a friend that used to work for a very big software company that and get told the very same thing, so know I don’t trust them


Get every new post delivered to your Inbox.

Join 57 other followers

%d bloggers like this: