False positives. Every anti-malware vendor’s worst nightmare. The European publisher Heise, apparently recently reinvented as The H, has pointed out that both GData and Bitdefender were inaccurately flagging winlogon.exe as Trojan.Generic.1423603. In case you were wondering, this doesn’t mean the whole anti-malware industry has gone mad: GData’s product uses two engines, one of which is
False positives. Every anti-malware vendor’s worst nightmare.
The European publisher Heise, apparently recently reinvented as The H, has pointed out that both GData and Bitdefender were inaccurately flagging winlogon.exe as Trojan.Generic.1423603. In case you were wondering, this doesn’t mean the whole anti-malware industry has gone mad: GData’s product uses two engines, one of which is Bitdefender’s.
In fact, it doesn’t mean that Bitdefender have gone crazy, either. False positives – diagnosing an infection where none actually exists – is one of those regrettable issues from which no vendor (or AV customer) is safe. Sometimes it’s a major inconvenience for customers, and that’s why Heise have been characteristically abrasive on the issue: “This latest case gives rise to the assumption that false alarms caused by anti-virus software will continue to unnerve users. ” But the point is well taken: FPs can be alarming, confusing, inconvenient and downright expensive for customers (especially where innocent but essential files are quarantined or deleted), which is why we go to considerable lengths to minimize the risk (but even ESET can’t eliminate it altogether, and it really is an issue we work very hard on!)
In fact, high profile misidentifications are surprisingly rare, given the complexity and sophistication of the technology. There are probably quite a few instances of low-profile FP, affecting applications less commonly used, that are hardly noticed. Despite the anger that antivirus and antispam FPs sometimes inspire, much of the security industry is founded on the idea that for some organizations and individuals, a degree of inconvenience caused by sensitive filters (in the broadest sense of the word filter) is acceptable.
For example, it’s common for mail filters to block whole swathes of executable filetypes. It’s unlikely that a filename like something.lnk would ever be attached to a legitimate email file attachment (the suffix denotes a shortcut rather than a “real” executable file), so blocking that suffix hardly ever results in misidentification. However, there are a great many innocent files that have the .EXE suffix, yet we often accept the filtering of .EXE attachments because we consider the risk from malicious attachments worth the risk of not receiving a legitimate .EXE through the mail, or the inconvenience of finding an alternative mode of transportation. In fact, some organizations have been doing this for at least ten years (and similar considerations apply in the world of spam management, as I discussed more recently in a Virus Bulletin article).
The fact is that the industry has had to move on from the early days of exact identification and one sighature to one threat. Nowadays, products use combinations of approaches that are nearer to what we used to call generic detection like change detection: whitelisting, filtering by filetype, change detection, heuristics, behaviour analysis, and so on. (Of course, products vary widely in terms of which techniques they use, how they are implemented, and so on.)
Our labs are now seeing over 100,000 unique samples a day. Other vendors may use different ways of counting, but they all face the glut problem, which is why there is so much emphasis in the industry on automation, distributed processing, and dynamic analysis. The miracle is, in the face of these difficulties, that significant false positives are so rarely encountered.
But there you go: problems attract far more attention than a product doing pretty much what it was designed to do, especially an antimalware product…
Director of Malware Intelligence