Whitelisting applications versus Anti-virus
June 28, 2007 7 Comments
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.