As Aaron Margosis points out, running anti-virus software which requires you to be a local administrator to work properly is fairly pointless. You have the rights required to turn off, disable and uninstall your AV, so any malware that gets past your defences can do this too, rendering the AV potentially useless. The same applies of course to running well-written anti-virus which does not require admin rights, but then running as admin anyway.

Recommendations for your business

I recommend to all my clients that they run some form of anti-virus software, as well as ensuring that they are set up to use non-admin user accounts. Ultimately, I can’t totally control their actions and stop them using an administrative account when they don’t need to, and despite my best advice they may inadvertently click on something, download something or otherwise put themselves at unnecessary risk. Anti-malware software adds a valuable layer in their “defence in depth” model. If I had complete control, or could always be on hand at a moment’s notice to answer their questions every time they get a prompt to install something, then they could perhaps loosen this approach. Frankly, for the small cost of a reasonable anti-virus solution, they get more protection, and greater peace of mind.

Whitelisting

Using software restriction policies to control what programs people use can help in the fight against malware by attacking the problem from the other end. By using a whitelist, you dictate what applications can be run on your network. To do this you have to make a list of all the ‘good’ programs, which is often easier, shorter and changes less frequently than the anti-malware approach of trying to list all the bad things out there, of which there are probably more, and this is certainly a moving target. However, I still don’t see businesses using whitelisting as a replacement for anti-virus, but as a useful complement in a managed environment.

What about those elephants?

Well, I met a guy on the bus the other day who was very carefully tearing small squares from his newspaper and throwing them out the window. I asked him why he was doing this, to which he replied “to keep away the wild elephants”.
When I pointed out that there are no wild elephants in the UK, he smiled and said “see – it’s working”.

Next time someone tells you that the AV product they use is better than some other one because they have never been infected, remind them of this story and ask how many times they have seen their anti-virus actually stop an infection and give them some kind of warning or log to show for it. In many cases you will find it is none. Thus proving that product X not only stops all known malware, but is equally effective at keeping away the elephants.

Share this post :

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.