In this “End User” IT world, viruses are more feared than ever. People value their Facebook and Twitter accounts more than their bank accounts, meaning that a “hacked” FB account can cause some serious emotional pain to the victim. In industry, the boundary between corporate and personal machines and networks is blurring, with employees using their own mobile devices for email/VPN access – it’s a potential “data theft” time bomb for some companies. If a worm virus with a Win32 payload manages to use iOS or Android to propagate, there’s no telling what could happen.
The media have been quick to add hysteria to the mix of security risks, citing that most virii are created by “international terrorist organisations” (although, according to other sources, so are counterfeit cigarettes, pirated films, and the endless slew of pizza shop flyers that cascade through everyone’s letterboxes). Others reckon viruses are created by the very companies offering products to protect against them – and to be honest, what a business model that is!
As an IT Guy, I’ve seen hundreds of viruses, and have had to manually remove dozens more. The first virus I ever had to deal with was a boot sector one, transmitted from an infected 3.5″ floppy disk on my DOS 3 PC. Back then though, virus checkers weren’t a necessity, or readily available, but then again, nor were heatsinks for CPUs!
At this point, most people would trot out a statistic about the mean time until infection on a non-protected PC, usually 30 minutes for an up-to-date Windows rig. Personally, I ran a fully-patched and “hardened” Windows XP (basically with as little apps as possible to reduce “attack vectors”, which in itself is a fantastic little phrase!) without AV for many months, although I did avoid many video and game websites on this virtual machine. Bear in mind that whenever anyone has a go at breaking into an MS OS remotely, it’s usually vulnerabilities in Adobe Flash that are the first to be attempted – and breached.
I’ve been tasked with smartening up our corporate anti-virus solution. There isn’t anything much wrong with the application itself – it is a respectable product that has a central console, deployment options, deployment points for distribution across a WAN, etc etc etc. I think the main issue is “opaqueness” to the rest of my department, and the policies being tough on older machines. The administrator, a back-office lad far-removed from the userbase, released a new version across the WAN. Since this update was about 200Mb – double the size of the original – it gobbled up the bandwidth to our main offices and ADSL-connected remote sites. An unreleased change released to the live environment, from a single point in the WAN. Hand slaps.
Most of the tasks I need to do shouldn’t be too taxing. Documentation and a bit of training to those in support, good communication and notification when updating, and methods of installing new clients is first on the list. However, there is one main gripe with this product, and that is the huge performance hit when doing the weekly full scan. Which is the crux of this post.
When an anti-virus product installs onto a machine, it has a real-time scanner, the idea is that any viruses loading into the memory or passing through the network interfaces will be caught and quarantined/deleted before it can start executing its dastardly machinations. Granted, no AV product is going to catch ALL viruses, especially zero-day ones (basically newly-released viruses the AV doesn’t have a record of in the definitions database, and takes advantage of a previously-unknown vulnerability of an app/OS), but let’s assume that my particular product will catch anything going active on a machine. Therefore, is it necessary to perform a weekly full disk scan? In fact, is it necessary to do any form of disk scan? If the real-time service watches data passing through the memory and the network cards,which incidentally will check any files being copied from network locations and external media, what’s the chances of a virus being delivered to the hard disk by any other method? In fact, if a virus manages to get copied onto my hard drive, it’s not going to pose a risk until it goes live, which the real-time scan would then pick up. So if the virus lies dormant on my hard disk, what’s the risk to my machine? I don’t think there’s any risk whatsoever. As long as a virus-infected file lies dormant on a disk, then it poses no harm as long as a real-time scanner is active in the machine’s memory. I could be wrong, but that’s the way I see it.
Therefore, I am contemplating disabling the scheduled scan on our corporate machines completely, and leaving the real-time scanner to protect our machines. Sure, best practise says to go A-1 paranoid about viruses and scan everything every few minutes, but I am a great believer in simplicity and efficiency. Having a few thousand hard disks churn through every file, every week, in the very unlikely scenario that a virus-infected file is lying dormant there, copied from a source other than external drives or the network, AND managing to bypass the memory/real-time scanner doesn’t feel right with me, and is probably putting unnecessary strain on all these hard disks.
My problem with all this is that I’m flying in the face of popular opinion and expert (maybe read that as overly-cautious) advice from the vendors. Sure, I could caddy-up a hard disk, copy a virus-infected file from my machine to the drive, then put the drive back into the laptop, but even in that scenario, a threat only exists if the file is accessed, at which point the real-time scanner would catch it. Personally, I don’t see much point in AV scheduled disk scans on anything other than file servers, and even then they should have real-time scanners checking the data passing through their network cards.
I would absolutely love to hear from anyone else who has an opinion on this. Oh, and for what it’s worth, keep yourself protected – use Microsoft Security Essentials. It;s free, has a tiny memory footprint, and isn’t full of bloatware unlike the “premium” products seen on TV.