Incident Response: The Importance of Anti-Virus
Heading home from the CSS Security Global Summit on Friday, I got stuck in Cincinnati’s airport. While walking through baggage claim, I saw this displayed on the arrivals board:
(I didn’t have a proper camera with me so, if that’s hard to read, it’s a Symantec AntiVirus Auto-Protect notification of a trojan horse found. Symantec was unable to quarantine it due to an access denied.)
Now, I suspect that this was a false positive; however, I’m just a guy walking by their wall of monitors. Even if it is a false positive, it was first detected at 4:26PM…and it was 8:30pm when I was walking by. (CORRECTION: It occurred to me, when I looked back at the picture, that this was detected on THURSDAY at 4:26PM. This was, apparently, displayed for over a day.) Even if there is no risk, I think it would have been wise for somebody to react to this faster just so that you don’t have smart-alec security guys walking by taking pictures…
This reminded me of a common thread that I’ve seen in security incidents lately: You can’t ignore your anti-virus software. Your AV software is whispering softly in your ear, telling you that something bad has happened – if you ignore it, you may go on (for months, sometimes) not knowing that something bad has happened.
What about if it’s a false positive? Do something about it. You paid for AV software and it’s an important factor in early detection of security incidents, so don’t just accept that it’s generating noise. If there’s not a clear resolution, contact your AV vendor and get them to help figure it out.
The same thing is true of errors -- “Unable to scan file X because of reason Y”, for example. Either this is a valid error that should be solved or it’s noise which shouldn’t be bubbling up to you as an error. In some cases, this is an indication of an attacker who is circumventing your AV software. If you can’t easily fix these, talk to your AV vendor and get their help in resolving them.
Another important thing, in regards to AV vendors, is their ability to react quickly in an emergency. Make sure that you know how to contact them and get samples to them if you have something rampant in your environment that isn’t caught by their current signatures. Also, be sure to understand how the vendor would deliver a new signature and how you would deploy it as quickly as possible. Include disaster scenarios such as “What if my network was completely down?” and “What if my enterprise had no Internet connectivity?” in your planning.
In general, make sure that you have an excellent relationship with your AV vendor and that they are a company that you can rely on, especially in a crisis.
AV isn’t a perfect solution but, then again, neither is any other single part of your security strategy. In some cases, it may be the difference between responding quickly to an incident and not responding until significant damage has been done.
I’ve often discussed these concepts with customers; however, two specific incidents that I’ve seen recently have made me think more about this topic.
In the first incident, a company was first penetrated by a remote-access trojan that their AV software didn’t detect; however, when I looked at each of the machines that this was installed on, I saw that the AV software had logged failures to scan various files on every machine that was compromised. (There might be a high volume of these errors in the enterprise; however, I doubt it since none of these machines had errors except where they correlated with specific malware being dropped on the system.) Additionally, some of the other tools did cause AV detections – for example, PWDump was detected on one of the compromised workstations. The attackers went on to use a different password hash dumping tool that was not detected…
Had these issues been remediated immediately, the company could have stopped the incident before it really started. Instead, the company didn’t discover the incident until months later from unrelated symptoms.
The second incident was large enough to take the company entirely off the Internet and turn off most of their Windows machines as a precaution. The company had an outbreak of a piece of malware similar to Conficker (in that it impersonated users to spread to machines that were otherwise not vulnerable) but different enough that its AV vendor didn’t have signatures that covered it. It was 50+ hours between when the initial infections were discovered and when signatures that were considered to be totally effective were deployed.
In this case, the AV vendor wasn’t a ‘trusted advisor’ to the company. The company was unable to effectively deliver on the promise of AV software to contain and remove malware at the time that it counted most to them.