full-disclosure - AV Naming Convention

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <411A235B.591.A4D9DA00@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: AV Naming Convention

Glenn_Everhart@...kone.com to Todd Towles:

> > Maybe a foundation should be created. This foundation could give a
> > seal of approval to all AV corporations that join in. We are
> > starting to make rules for patch management over at
> > patchmanagment.org. Why couldn't a group work with AV names and the
> > first company that finds and IDs it correctly gets to name it in the
> > foundation. Just a dream, I would guess. 
> 
> So isn't this the reason CVE was created some time ago now?

For security vulnerabilities, yes.

It almost certainly is too slow a process, as is, to be adopted 
usefully for virus naming.

Naming confusion is usually "worst" and most costly/disruptive in the 
first few hours after a new fast-spreading virus is isolated.  During 
this period corporate IT admins (and journalists) start getting reports 
of something new that sounds much like other reports, but often the 
variant ascriptions and occasionally the family names, are not in 
agreement.  The corporate IT admins then have to convince themselves 
that FooBar.AB, FooBar.AD, FooBar-AD and Foo.AC are actually all the 
same thing reported with slightly different names (note I'm assuming 
these folk are smart enough to know how to ignore, or normalize, all 
the other optional and/or non-standard stuff that can be in reported 
malware names -- things like platform precursors (such as "Win32/" or 
"W32/" and their common, but non-standard variations "Win32." and 
"W32."), vendor-specific non-standard "extension" precursors (such as 
"I-Worm."), optional modifiers (such as "@mm", ":Fr"), etc, etc).

> Give the AV companies a bit of mercy though: they are called upon to
> analyze virii with ever less lead time, and need to pick names sometimes
> before full behavior is even known (as it seems to me from watching
> them).

Quite right, and that is a part of the "problem", though not a terribly 
insoluble part once you can get a commitment to attempt better naming 
consistency from the AV developers.

> Given the time allowed to do this work, it seems a cross reference after
> the fact is probably the best one can hope for.

Well, if usefully better naming consistency is to be achieved, the 
structural changes needed in many AV companies' internal processes will 
mean that "after the fact" renaming to achieve better consistency will 
be easier than it is now and possibly more likely.  However, those same 
structural changes have the added benefit of allowing much better 
"before the fact" naming consistency too and I can imagine that 
happening...  (We'd never have perfect before the fact consistency, but 
I can see that rate easily surpassing the current after the fact rate.)

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