From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: AV Naming Convention

nobody@...alhost to "Randal, Phil":

> > This completely misses the point.  When a new virus is discovered, it is
> > essential that there is a RAPID response to the threat.  The idead of
> > handing the critter over to a committee to decide it's name is, quite
> > frankly, plain bonkers.
> 
> I think you missed some of his point, his is not saying a committee 
> should name it, he is saying whoever gets there first gets to name it.

Ahhh, well regardless who else already missed (some of) the point, you 
clearly now must be added to that list.

You see, the "first in" process is basically what we have now and, 
correct me if I've misinterpreted something here, but I thought the 
whole point of this thread was to point out what a terrible mess we 
have now (and to air everyone's pet theories of how to make it better).

> > I for one would rather all the antivirus
> > vendors came up with their own names if it meant that
> > detection/disinfection patterns came out hour earlier.
> 
> Actually, I was thinking the exact same thing, I'd like to set up a AV 
> vendor neutral, FD style virus repository. I'd require a user cert for 
> anyone who wants to "deposit" a new virus and the first to deposit the 
> new virus would get to name it. It would be assigned a GUID, so that a 
> computer friendly identifier was available.

And how would your "repository" determine that what UserY just 
deposited as FooBar.Y was not, in fact, just another sample of Foobar.X 
that UserX deposited a few minutes, days, weeks, etc ago??

And don't say something like "file hash" as that shows you have no idea 
what parasitic viruses are or what "variant samples" of invariant 
malware are...

And don't say "by scanning it with all other virus scanners" because 
that shows you have no idea how much known virus scanning is a 
probabilistic, rather than deterministic process (if you think virus 
scanners are simply "grep on steroids", much like the OpenAntiVirus 
project and its cousins, you really should not be taking part in this 
discussion other than reading and learning from it).

> There would be an RSS feed as well as various push feeds.
> Lineage could be discussed and mapped.
> Other vendors could add their names to that record with information 
> about what virus def file name the virus first appears in.

Doesn't allowing others to list "alternate" names really obviate the 
purpose of _consolidating_ naming???

> If it turns out that more than one group submits the same virus, then 
> those "dups" would be discarded from the db, thus encouraging AV vendors 
> and other groups to post new viruses asap so that everyone has a chance 
> to download them and start researching them.

I agree that speed of information flow is at the core of many current 
naming problem issues, but speed of access to samples need not be (and 
proposing a system that depends on such will likely see that system 
boycotted by many of the top AV professionals and the rest of their 
companies for a whoile raft of professional ethics reasons.  That does 
not mean the entire idea is without merit though.  For example, with 
Word and Excel VBA macro viruses, there has been a very successful 
project running for years within part of the  AV community whereby 
competent researchers can exchange identification data for new VBA 
malware without having to distribute samples, _and_ in many cases 
recipients of this ID data can actually add specific detection of that 
malware sight-unseen to them.  This means that folk who may not hold 
requisite trust levels for sample sharing can co-operate equally in 
announcing and naming new VBA malware.  This approach has kept the 
naming of Word and Excel VBA malware very consistent among the vendors 
who have staff actively involved in this project (which is not all 
vendors for many reasons I'll not get into here).  Sadly, that model 
cannot easily be extended to most other forms of malware as the 
complexity of devising suitably flexible identification mechanisms 
skyrockets with the removal of various constrictions imposed by the VBA 
model, the size and complexity of its op-code set, and so on.  However, 
a sufficiently useful, while somewhat constrained form of this approach 
may be possible for the more complex platforms, but no-one has had the 
time and funding, and the vendors don't have the motivation, to 
investigate what may be possible and how effective such an approach 
could be.

> Fear of the government labeling me a terrorist gives me pause though...

8-)


-- 
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854

Powered by blists - more mailing lists