Re: it\'s all about timing

[full-disclosure () lists netsys com (full-disclosure () lists netsys com)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


It is very unclear as to what it is that you are really after. Who are these people "Vulnerability researchers", who's 
label is this?  Is this a profession of some sorts?

Are thes professionals now not adhereing to some suitable reporting method where they do in fact alert the vendor in 
private, work with that vendor  in private, and then release the advisory? Is this not the case already? If so, what is 
the need for this to be set out in stone?

Or do you mean the one-off vulnerabilty report, the one that some individiual stumbles upon and sends it off to the 
lists. Are you trying to harness them? Do you think some standard setout on what do do with the reporting is going to 
trickle down to the individual man in the street and he's going to (a) know about it (b) be bothered to follow the 
method if he did.

Let us say you have two sets of bug hunters

(a) professionals. certainly they know what they are doing, why they are doing it and how best to leverage it to bring 
business to their company. They WILL report them the  reponsible way

(b) one-off individuals who are fly-by-nighters. find a bug, report it to a list and see you later. No time no interest 
to seek out some rule or protocol on how to report the bug. They have no interest in getting involved in some laborious 
process with a vendor. They can either do nothing with it or they can submit it to the nearest mailing list and be done 
with it.

a) above doesn't need a guidline and b) above you have no hope in harnessing or educating as the interest is simply not 
there.

Is there then a third set out there that needs this guidence everyone is hollering about?

On Fri, 2 Aug 2002 14:07:53 -0400 (EDT), full-disclosure () lists netsys com wrote:
> > It is interesting that the people screaming loudest for some sort of
> > order in the submission of bugs, are in fact non-bug hunters at
> > all. Rather a vocal group academics who intent of have their name on a
> > draft or ratified document they came up with. Sure some may have
> > posted a few findings but none are consistently doing so, and the bug
> > hunters, sure don't sound like they need some else telling them what
> > to do. You don't hear them crying to for order.
> >
> > Wonder why that is.
>
> I think it's because there are more "consumers" of vulnerability
> information than just other bug hunters, for example, people who want
> to remove those bugs from their vulnerable systems.  I would be very
> interested in hearing the experience of bug hunters who are also
> responsible for the security of large, diverse networks; they may see
> this situation from both angles.
>
> The audience for a security advisory includes individuals and
> organizations with many different needs for security information.
> Having some order to disclosure can make it easier for people to
> identify the vulnerabilities that they care about, and to secure their
> systems.
>
> The audience includes:
>
> - System administrators, who often need to manage or support dozens of
>  products
>
> - Security administrators, who need to research and understand
>  hundreds of vulnerabilities across their enterprise, and who may not
>  fully understand all the products that have been deployed at their
>  enterprise.
>
> - Vulnerability database maintainers, who need to research,
>  understand, and/or verify thousands of vulnerabilities.  Since
>  databases are relied upon by many people, errors or inconsistencies
>  in your own advisories will be multiplied greatly.
>
>  For a list of some of the challenges in vulnerability database
>  maintenance, see my post at:
>  http://lists.netsys.com/pipermail/full-disclosure/2002-July/000568.html
>
> - Vulnerability researchers, who may have specialized research
>  interests that require greater detail (or different types of detail)
>  than most of your audience.
>
> - Potential customers, or the consultants that they rely on
>
> - Existing customers who care about security issues but do not
>  regularly read advisories
>
>
> Sysadmins and security admins often have time pressures that may make
> it difficult for them to sift through "noisy" vulnerability
> information - incomplete, inaccurate, etc.  If an advisory is released
> without a vendor patch, the admins then have to keep track of which
> bugs are outstanding, and figure out which researchers they can trust
> when there is no vendor patch.
>
> One of the roles of vulnerability databases is to sift through the
> "noise" and make it easier to access vulnerability information.  But
> since it's resource-intensive for experienced vulnerability database
> maintainers to manage the noise, it seems reasonable to assume that
> admins may have difficulty managing the same information... or at
> least figuring out which information is actually correct.  The job is
> only going to get harder with the increasing de-centralization of
> vulnerability information.
>
> In my experience, the most informative and accurate security
> advisories offer a mixture of the details that researchers provide,
> along with the correct version, fix and actual cause of the problem,
> as is often best known by vendors.
>
> High-quality information may not be needed by everyone, and some
> people may not think it's important, but better information means
> better security overall.
>
> - Steve
> _______________________________________________
> Full-Disclosure - We believe in it.
> Full-Disclosure () lists netsys com
> http://lists.netsys.com/mailman/listinfo/full-disclosure

-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wmYEARECACYFAj1K0fsfHGNob29zZS5hLnVzZXJuYW1lQGh1c2htYWlsLmNvbQAKCRDT
5JkCl0iMkPAqAJkBOo3qKq5TgVaAvHRX3zJ3DHVX+gCglYKof6O+KpQ04nyoSA1rHwvH
5Gg=
=kqdi
-----END PGP SIGNATURE-----


Communicate in total privacy.
Get your free encrypted email at https://www.hushmail.com/?l=2

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople