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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: AV Naming Convention

"Randal, Phil" to "Todd Towles":

> I have thought about it, every time this issue is raised.  To do what is
> proposed at first glance seems eminently sensible, but even a post-hoc
> renaming exercise requires additional "vendor" resources, and leads to
> customer confusion.

Indeed.

Also, as I just explained in another post, the "worst" confusion tends 
to come in the first few hours after something new and fast-spreading 
is first isolated.  Thus, post-hoc renaming does little to help the 
_worst_ of the "problem" from the user's perspective.  If we settle on 
a solution that is heavily dependent on post-hoc renaming, it means 
that most of the early confusion will still be experienced -- the media 
will report four different names for the same new thing and  
productivity will be lost while IT admins work out if the reports of 
FooBar.AB, FooBar.AD, FooBar-AD and Foo.AC are actually all different 
names for precisely the same thing or not, and if not, whether the 
scanners they use from different vendors at different layers in their 
protective strategy detect all of the however many variants that naming 
bundle actually represents (and don't think that is unlikely -- several 
times just this year we have had two or more new variants of large 
families of successful mass-mailers released within hours of each 
other, and in the bot arena, some families are seeing several new 
variants released (or at least isolated by AV researchers/analysts) 
_nearly every day_).

To remove the bulk of the inconvenience naming inconsistency causes we 
really need to address naming consistency up front, during the initial 
analysis period and leading up to the vendors putting up web pages 
naming and describing the variant and/or shipping updated DAT/DEF/etc 
files to detect it.  A "solution" to the naming inconsistency problem 
that is, say, 90% effective at this point in the process should have a 
huge impact on the overall problem...


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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ