In recent weeks I have had the misfortune of dealingwith a number of malware incidents, not necessarily all these were at work. What I found interesting was the reason for the call to me and how easily the call could have been avoided.
It isn’t the Helpdesk’s fault.
See… I am a Network Security guy. I don’t do Desktops; in fact, you don’t want me doing desktop support! Calling me in for a virus or malware issue, is along the lines of bringing a Vulcan cannon to a diplomatic dispute – i.e. not the most appropriate solution, until things escalate.
In this age of technology and Al Gore’s Internet (don’t laugh I’m from Tennessee), everyone runs an updated anti-virus software package (enough with the laughs already). Most of the anti-virus software will detect a high percentageof the garbage you’re likely to encounter (no laughing!); unless you are a retailer and someone wants your credit card data! So if the software detects the threats and takes action, what is the problem?
I have been called on a number of occasions lately to find out why a number of computers are running slow (is Vista actually a trojan?) or the firewall logs show strange Internet traffic, or the developer’s laptop won’t shutdown properly, etc. After I suggest a pre-boot scan of the system or an external scan of the suspicious system’s hard-drive, it seems the on-host AV scanner wasn’t working and now we’re picking up 10’s, maybe 100’s of malware instances. What happened?
Funny thing about malware and automated processing by most AV engines. The AV solutions on the market today will either delete or quarantineany infected files they encounter, as a default when the infection cannot be cleaned. This is a great start, unless you wanted to have a look at the deleted software or the AV deleted a perfectly legitimate file. This is where the problemcomes in for the Helpdesk, remember the Helpdesk lives and dies by procedure and process.
AV software had its hayday back in the days of Melissa and the plethora of other Word macro viruses. Everyone was into this email thing (is email dying?) and everyone had Microsoft Word, so the bad guys loved nothing better than to send out a piece of garbage and see who all it took down. Granted the solution was rarely as simple as deleting the offending / infected Word file, this deletion process became the pat answer: if you have an infected Word file, don’t mess with it, just DELETE IT.
This solution survives today, but “Word” has been removed such that the solution to any detection of an infected file is to delete it. Your AV solution happily does that for you. So when the AV solution deletes the file but malware is already memory resident, you have yourself a problem. The Helpdesk is not going to respond to a single AV detection of Trojan.Backdoor; that is too resource intensive and often fruitless.
The Helpdesk’s response to single incidents is the cause for larger problems because although they can’t possibly react to a slow, steady stream of one or two infections per location over a week or two, those infections are laying the groundwork for a larger problem. No one asks the question, HOW did this infected file get on here or WHY is this infected file on here? Those questions aren’t the Helpdesk’s mission, instead their mission is keep tickets resolved, answer support calls, and meet SLA’s. Someone needs to be able to answer THOSE questions and take appropriate action.
Your Helpdesk, my Helpdesk, anyone else’s Helpdesk has a set of procedures they follow. Any AV solution worth its annual subscriptionfee (now start laughing), will feature centralized logging and reporting, so the Helpdesk and IT can be notified upon infections – mass infections, that is. One or two infections and those files being deleted isn’t going to raise suspicion in most organizations. Which leads me back to my opening paragraph…
All it takes is one piece of malware to get into memory. It isn’t a joke and it isn’t hypothetical. If you want to be next, just keep ignoring those “deleted” infected files your AV solution keeps finding! My hourly rates aren’t as bad as a front-page headline.
Newflash: Complexity does not mean or provide security.
Although there probably is a company out there that hasn’t purchased a firewall, isn’t running anti-virus software, and has no plans to implement intrusion prevention technology, there are plenty that have spent the equivalent of Ughanda’s GDP for the last 5 years on security technology. After 10 years of security work and countless conversations with peers, I have concluded all this spending is not solving the fundamental problem security set out to address: create safe and secure environments.
The answer lies in why many business don’t have many of the generally accepted mainstream security technologies deployed. Complexity.
The complexity of security solutions and the perceived inability of security to meet dynamic business needs because of that complexity are some of the key underminers of security.
It almost begins to sound like a popular comedian’s tagline:
- If your security solution or product requires a triple PhD from MIT to operate, you might have a complexity problem.
- If your security solution or product has not been updated since men walked on the moon, you might have a complexity problem.
- If a 5lb block of swiss cheese has fewer holes in it than your security solution or product, you might have a complexity problem.
Sure there are all manner of security schemes on the market from network-based defenses and host-based defenses to security policy frameworks and security intelligence services to meet an organization’s security needs, but technology has only brought us to the place where we now need a room full of security experts pouring over event data or some artificial intelligence, akin to that of Skynet from the Terminator franchise, in order to determine whether our security is working or if the bad guys have just dumped the contents of the customer billing information database to a botnet-based auction system via a partner’s VPN connection using valid credentials they obtained through an infected email to an outsourced developer.
Fired up? Come back for part 2…