Why Antivirus is unnecessary in a controlled environment that uses DriveShield

This is a short essay-style piece I wrote on my own time a few weeks ago to defend my position of not putting antivirus in our computer labs. I presented this to a group of lab managers here, and I lost the battle with them for political reasons and because they focused on macro viruses too much, which I didn’t look into at first because of they barely exist anymore!! Notwithstanding, I think the technical merits of my argument can stand fairly well anyways, and is a good read anyways. Keep in mind that this is talking about tightly managed machines with something like DriveShield or Deep Freeze on the computer. For perspective, the antivirus vendor we use is Symantec antivirus (which I despise). This paper does not reflect the position or opinions of anyone except myself.

Common Windows security wisdom says that anti-virus protection is necessary. In fact, some people have declared that “as professionals, we should install anti-virus to protect our users/machines“. As professionals, we should protect our users, but I assert that anti-virus (AV) does not always need to be a part of this protection. The problem is, anti-virus makes a computer unnecessarily slow, and some AV (Symantec) tend to worsen the state of the computer more than they help it by causing mysterious problems. Additionally, they can become vulnerable to viruses themselves and be the cause of the problem (Symantec again). Or, a mistake in virus signatures can disable hundreds of thousands of computers, just like what happened recently in China [1].

In cases where the User is Administrator and DriveShield has not been installed, in many cases it makes sense to run an Anti-virus program. This document does not refer to those cases. I am referring specifically to machines that are in a tightly controlled environment, such as our computer labs.

Why DriveShield makes antivirus unnecessary

DriveShield is a technology that protects computers from damage. When the computer reboots, then the computer reverts back to its initial state, and any changes to the operating system are completely wiped away. So, if a virus is able to infect a computer, then upon reboot the virus immediately disappears, and the computer is clean.

Why antivirus is useless against common methods of infestation

The most compelling argument against using antivirus is the amount of time that it takes antivirus vendors to release new virus definitions. It is important to note that most anti-virus protection is incapable of detecting viruses that they are not previously aware of [2], especially popular anti-virus software [3]. As a result, there is around a 1-2 week ‘incubation period’ that AV is ineffective against new viruses.

Below is a discussion of some common virus infection methods, and why anti-virus won’t significantly help a computer that already has DriveShield on it.

1. Remote Exploits

This is the most common way that viruses spread. In general, remote exploits are caused by security problems in Windows core operating system files. The only ways to fix these types of problems are either through a firewall, or by applying the Windows Update patch that fixes the specific problem.

If you keep your Windows Updates current, then the you will not be vulnerable to remote exploits, and therefore viruses will not be able to use those particular exploits to infect the machine. Additionally, having strong passwords on all accounts will prevent exploits using Windows hidden administrative shares such as C$.

If a machine that hasn’t been patched yet does get a ‘new’ remote exploit virus, then machines with AV are just as vulnerable to the virus as machines without AV — until the machine is patched, or the AV definitions are updated. Therefore, a machine with AV is vulnerable to a ‘new’ virus for a period of 1-2 weeks. By the time the AV definitions are released that can detect the ‘new’ virus, administrators of machines with AV and without AV will need to do maintenance (windows updates) on the affected machines anyways. This shows that having AV on the machines does not help. This 1-2 week window in which machines can be infected is by FAR the most compelling argument against anti-virus in my opinion.

There is no excuse for a machine to be vulnerable to a widespread remote exploit that the anti-virus software can actually catch, given the 1-2 week incubation period of AV software. Administrators should apply windows updates and other software updates regularly.

2. Physical transfer (Floppies, bootable USB, CD-ROM)

These threats are insignificant in today’s computing environment. There are very few modern viruses which attempt to spread through bootable devices. Even if the risk was higher, they are easily defended against in a computer lab environment. You can prevent users from booting to any device except the hard drive by changing settings in the BIOS, so this will not ever be an issue in a properly setup machine.

3. Physical transfer (autorun on CD/USB)

This is not a common means of infection. Even if it were, there are two big problems with this method that make it irrelevant.

1. CD Autoruns

This requires a user to create a CD that has a virus on it — which is difficult to do by accident. Even if it infects, when the computer reboots the virus will disappear due to DriveShield restoring the hard drive back to its original (uninfected) state.

2. USB key autorun

This is more likely to happen — a virus could technically copy itself to a USB key and create the autorun.inf file on it. However, autoruns do not work properly on a USB key. It is not possible to run an executable automatically by inserting a USB key into a computer, without willful user interaction [4]. Users are given an option to run the program or not, and you are presented with all the other options XP shows you as well. Even if it infects the computer, when the computer reboots the virus will disappear due to DriveShield restoring the hard drive back to its original (uninfected) state. Independent testing has confirmed this.

Additionally, if you really did think that autorun is a security risk in your workstations, then you can configure windows to disable autorun completely, and this will no longer be an issue.

3. Email Attachments

This can be a problem for many users, since they can be uninformed about the dangers of unknown email attachments. In a lab environment, a user could download a virus and execute it, and it would disable the machine. However, there are a number of reasons why email attachments are not a significant security threat to lab computers:

1. Running as a limited user

In a properly setup machine, if the user is running as a limited user, then they are not able to do things that allow the entire machine to be infected. If a user downloads a virus infected email attachment, then the user will have an annoying virus on their hands; until they reboot the lab machine (see below). However, this will not affect other users.

2. DriveShield

Even if the user IS running as Administrator, DriveShield will kill the virus on reboot, and it will no longer affect any users on that machine. In our labs at least, computers are rebooted regularly.

3. It won’t affect other properly protected computers

If the virus happens to have a remote exploit capability, then machines that are properly protected will not be affected (see Remote Exploits, above). If they are vulnerable, then they could have also been infected by a personal laptop someone was using on campus — which is a far greater threat.

4. ActiveX Controls/Browser exploits

In general, lab administrators should keep their browsers updated. Many modern browsers are now being exploited in various ways. Many of the sites that have these malicious exploits on them are those that users should not be visiting anyways (warez, adult content, etc).

Limited users are not allowed to install ActiveX controls by default, so that will not be a problem if you are running users as limited users.

Exploits and viruses that do manage to get on a computer through a browser exploit are subject to the same conditions that email attachment viruses are subject to (see the points about ‘DriveShield’ and It won’t affect other properly protected computers ‘, above) and will only affect that individual user.

5. MS Office Macro Viruses

These types of viruses are not as common as they used to be, but can still pose a serious threat if allowed to propagate. However, modern versions of Microsoft Office by default have unsigned macros disabled – and warn users before it executes them. If you’re really paranoid, you can completely disable macros on your machines. If a computer is affected by a macro virus, it too will be wiped out when the computer reboots.

Conclusion

Strictly controlled lab machines with DriveShield installed are not a big threat to campus security. There is more risk to users from their home computers than there ever would be from using a lab computer without anti-virus. Computers on our networks are more at risk from laptops or personal computers that are connected to the network, because many people are ignorant of proper securing of their computers and have all sorts of badness on them.

In the period of time that I have maintained the computer labs in the [labs], there have been zero virus infections on the computers that I actively maintain. I have not had antivirus installed on the computers for at least a year. Our network staff tends to be very paranoid about viruses, and let us know anytime there is suspicious activity on the network. Ever y incident has always turned out to be false positives.

References

[1] Millions of Chinese Hit by Symantec Foul-Up. http://www.pcworld.com/article/id,132050-c,antivirus/article.html

[2]. The New Virus Fighters. http://www.pcworld.com/printable/article/id,124163/printable.html

[3]. Why popular antivirus apps ‘do not work’. http://www.zdnet.com.au/blogs/securifythis/soa/Why-popular-anti-virus-apps-do-not-work-/0,139033343,139264249,00.htm

[4]. Autorun an executable from a USB key in Windows XP. http://www.exponetic.com/blog/2006/07/

License

©2007 Dustin Spicuzza. This article is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 License (http://creativecommons.org/licenses/by-nc-sa/3.0/us/).

Leave a Reply