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] [thread-next>] [day] [month] [year] [list]
Message-ID: <343561e90408101059155aca77@mail.gmail.com>
From: abaker at gmail.com (ASB)
Subject: AV Naming Convention

All collaboration with the naming should occur in subsequent revisions
of their signature files.

Upon initial release, each vendor should call the virus:  
VendorName-VirusCodeName.    Once the initial releases of the updated
signatures are out, and the necessary documentation on the effects of
the virus has been produced, the appropriate liasons for each vendor
should get together and determine the correct global name.

Then, each vendor can update the subsequent releases of their
signature files to include the standardized name in conjunction with
their own (e.g. VendorName-VirusCodeName [StandardizedName])


-ASB

On Tue, 10 Aug 2004 11:18:05 -0500, Todd Towles
<toddtowles@...okshires.com> wrote:
> How would a name stop an AV company from protecting its customers? A name is
> only a name. AV companies should do their job and stop viruses. But do we
> really care what they are called in the first couple of hours, no? I am
> trying to encourage sharing of some information between AV companies to
> better protect the public.
> 
> I really don't care what they name them as long as they stop them. But the
> idea would be nice. If each company is going to have names for stuff..they
> can just use long strings of numbers. Would it really matter what one
> company names a virus in the first couple of hours?
> 
> Maybe it will never happen because of money and the desire to be the first
> to discover it. But all the corporations of the whole have to deal with
> multiple AV engines, confusing names and variants.
> 
> Maybe the idea wouldn't work, but to just throw it off without thinking
> about change is sad.
> 
> 
> 
> -----Original Message-----
> From: full-disclosure-admin@...ts.netsys.com
> [mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of Randal, Phil
> Sent: Tuesday, August 10, 2004 10:07 AM
> To: full-disclosure@...sys.com
> Subject: RE: [Full-Disclosure] AV Naming Convention
> 
> > I have to agree with Todd, the naming convention is now right
> > useless for the normal population and make keeping up with
> > viruses on a corporate level that much harder. AV companies
> > are always trying to beat the other company and this leads to
> > very little information sharing between the companies on new
> > viruses, etc.
> >
> > 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.
> 
> 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 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.
> 
> Cheers,
> 
> Phil
> 
> ----
> Phil Randal
> Network Engineer
> Herefordshire Council
> Hereford, UK
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ