OPSWAT, a California-based company that includes product certification among its range of products and services, asks What Can We Learn from Anti-malware Naming Conventions?
The short answer is, not very much.
Jianpeng Mo points out, quite correctly, that:
Using naming conventions to track the detection of viruses can be difficult because vendors often report the same virus with completely different names, even if they otherwise agree on the format.
The question is, why would you want to track detection this way? Well, I can see why OPSWAT might: its Metascan Online service flags the most searched-for threats on Metascan Online over the past 7 days, and I can see that wide range of names used by various companies might be frustrating for them, but I don’t know how many people use Metascan as an aid to ‘parse and execute their next action’, or indeed why. I can see that an end user – or a security vendor’s corporate customers – might want to know about their chosen product’s ability to detect a given threat, but this doesn’t really tell them. It might be different if each threat name represented a single sample, but that hasn’t (in general) been the case in many years, at least among mainstream anti-malware vendors.
When managing malware first became part of my job (long before I started working directly with security vendors), it was at least feasible to harmonize on the names of specific threats, because a single threat name might still represent a single sample, and identical samples might continue to turn up for months and years. CARO long ago acknowledged that ‘making sure each virus has the same name across all vendors is impossible’, and its 1991 naming scheme, even in its far-from-recent updated form, was not intended to address the ‘complex task’ of ‘co-ordinating family names across products’. The scheme is still followed closely enough by mainstream vendors, at least part of the time, to give some guidance as to what a generic threat name actually indicates, but that information was always of limited use to anyone outside the security industry and those who test its products. Researchers were well aware of the desirability of standardization in naming (if only to address the criticism from journalists and others who couldn’t understand why naming wasn’t standardized), but were understandably sceptical of attempts from outside the anti-malware industry to impose a naming standard. CME at least tried to reduce confusion for the highest-profile threats, but was bound to fail at a time when threats were already fragmenting into innumerable short-lived samples. While its effectiveness in the real world has been patchy at best in recent years, VGrep at least still addresses the problem of name harmonization. MAEC addressed quite a different information-sharing issue, and while I haven’t been even peripherally involved with it for several years now, I’ve never seen it as being of much use or interest to people outside the security industry.
Nowadays, anti-malware labs process hundreds of thousands of samples a day, and a single threat name can represent a hierarchy of variants and sub-variants that might easily represent tens of thousands of individual samples, or more. But perhaps hierarchy is a misleading term, suggesting that malware families are rigidly and universally defined. If only… The fluid and complex nature of modern threats ensures that two anti-malware labs may generate equally effective (or ineffective!) detection of a given sample yet allocate names that reflect a very different understanding of which family it belongs to.
Leaving aside the marketing issues that sometimes lead to highly-visible but information-poor naming – though soundbite-as-nomenclature often derives from the media and the wider security industry rather than from specialist anti-malware companies –
I’m afraid I’m going to quote from a Virus Bulletin paper I wrote with Pierre-Marc Bureau.
If your product of choice detects malware, does it matter what identifier it uses? The sheer volume of malware variants nowadays means that it’s more efficient to use more generic detection techniques such as static and dynamic analysis and generic signatures wherever possible. This has been represented as a detection failure [16], but it’s unlikely that botnets and other threats would have a significantly smaller impact if all companies used the same identifier. It could be seen (and no doubt is) as an illustration of the problem this industry has with naming. The time and resources needed to cross-match all the samples seen, so that each vendor can use the same name for each variant or sub-variant, is simply not available in a time of glut, when it’s sometimes estimated that the number of new samples for analysis runs into several thousand per hour [16]. In real life, the actual name used by any product might vary widely according to which variant it might have picked up, not to mention when and where the detection was triggered.
As I believe I said when we presented it, though I don’t have the slide-deck to hand, the ‘true’ name of a malware sample is its hash, not its detection name. I expanded on that thought in another paper the following year.
In brief, why is consistent naming a problem? If it’s not a problem, identification by naming is just background noise, and we can filter most of what plagues us without naming every last subvariant. (Of course, for PR purposes we need to reassure our customers occasionally that we really are filtering it, or they might start to think they don’t need the product…)
Why do I feel it necessary to refer back to these papers from 2008 and 2009? Well, because they do offer some sort of answer to the questions raised by OPSWAT, of course. But also because I’m mildly disturbed that the OPSWAT article suggests that four products ‘are all comparable for detection rates and virus naming conventions.’ That’s kind of interesting, and might even be the basis for some useful – well, interesting, at least – research using a larger sample population. But if testers started to use conformance with virus naming conventions as a test criterion, I can see scope for massive confusion and misinterpretation. As I also said in that 2009 paper:
Does all this matter to the end user? Only if the user thinks it does.
David Harley
Anti-Malware Testing 
Leave a Reply