Message-ID: <200208022353.g72NrZw03741@mailserver2.hushmail.com>
From: choose.a.username at hushmail.com (choose.a.username@...hmail.com)
Subject: Re: it\'s all about timing

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

I am afraid I still don't understand any of this. What is the actual point of this guideline? It looks to me like nothing more than a blueprint or template for future arbitration or litigation down the road.

What are the penalties now for not abiding by this guideline, or any other guideline that might be out there.

Pretend that your (as in this) guideline was already implemented. How on earth would you expect it to have stifled the release by both the individual in (or a part of) SnoSoft and ISS.

What exactly would have been done differently? Are you expecting either party to have been even more aware of some guideline or is this again, the benchmark by which the vendor will have recourse in the future? [read: litigation].

Based on an informal study I've done of about 350 researcher reports
from early 2002, approximately 50% of the vulnerabilities were
released without notifying the vendor, and about 20% of those reports
included full exploit code

Your informal study of 50% of 350 researcher reports. What exactly does that mean?

How many of those released were one-offs?  1 person never to be seen from again.
How many of them were "repeat offenders" 10 of the same people releasing the bulk of them?

In either case, how again, will the guideline apply or change that behaviour?

Your number 6 below:

"The Vendor MUST provide a facility for individuals or
   organizations who are not Customers to report vulnerabilities"

This to me sounds like it is acceptable that there are going to be vulnerabilities. Continue cranking out shodware because we have a set of guidelines that people who stumble across them are expected to adhere to.

Why not draft a guideline for release of software onto internet. Security guideline (defaults of configs. etc.) and Quality Guidelines (vendor (a) is a known creator of crudware etc.). if you want to connect to the interne or peddle your internet connect warest, you the vendor must follow these guidlines. Penalise them them if they fail. Fine them real money if the repeat.

Don't try to coral the victim of the vendor with guidelines on what he is expected to do if he is burnt by a vendors product. Expect to find garbage software out there. When you do this is how you must report. You are duty bound to do that.

Never going to happen.I am afraid I still don't understand any of this. What is the actual point of this guideline? It looks to me like nothing more than a blueprint or template for future arbitration or litigation down the road.

What are the penalties now for not abiding by this guideline, or any other guideline that might be out there.

Pretend that your (as in this) guideline was already implemented. How on earth would you expect it to have stifled the release by both the individual in (or a part of) SnoSoft and ISS.

What exactly would have been done differently? Are you expecting either party to have been even more aware of some guideline or is this again, the benchmark by which the vendor will have recourse in the future? [read: litigation].

Based on an informal study I've done of about 350 researcher reports
from early 2002, approximately 50% of the vulnerabilities were
released without notifying the vendor, and about 20% of those reports
included full exploit code

Your informal study of 50% of 350 researcher reports. What exactly does that mean?

How many of those released were one-offs?  1 person never to be seen from again.
How many of them were "repeat offenders" 10 of the same people releasing the bulk of them?

In either case, how again, will the guideline apply or change that behaviour?

Your number 6 below:

"The Vendor MUST provide a facility for individuals or
   organizations who are not Customers to report vulnerabilities"

This to me sounds like it is acceptable that there are going to be vulnerabilities. Continue cranking out shodware because we have a set of guidelines that people who stumble across them are expected to adhere to.

Why not draft a guideline for release of software onto internet. Security guideline (defaults of configs. etc.) and Quality Guidelines (vendor (a) is a known creator of crudware etc.). if you want to connect to the interne or peddle your internet connect warest, you the vendor must follow these guidlines. Penalise them them if they fail. Fine them real money if the repeat.

Don't try to coral the victim of the vendor with guidelines on what he is expected to do if he is burnt by a vendors product. Expect to find garbage software out there. When you do this is how you must report. You are duty bound to do that. Vebdor continue as you were, keep cranking out your crap.

The print looks bright blue to me.

On Fri, 2 Aug 2002 17:44:34 -0400 (EDT), full-disclosure@...ts.netsys.com wrote:
>choose.a.username@...hmail.com said:
>
>>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?
>
>It's an RFPolicy-ism.  Alternate terms are "reporter" (which covers
>"bug hunters" and "people from the press") and "notifier" (which is
>probably more accurate than "researcher," because the notifier might
>not be the person who discovered the issue).  I'm leaning towards
>"notifier."
>
>>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?
>
>Based on an informal study I've done of about 350 researcher reports
>from early 2002, approximately 50% of the vulnerabilities were
>released without notifying the vendor, and about 20% of those reports
>included full exploit code.  (NOTE: the data is presently incomplete;
>but I hope to publish a full report in the future).
>
>But even in the case where the vendor is notified ahead of time, one
>needs only to look at the recent HP/SnoSoft situation to see that
>there are different opinions on how disclosure should happen.  Going a
>little further back, the ISS/Apache situation also demonstrated a
>variety in how professionals handle vulnerability reporting.  We may
>agree on the general notion of "give vendors some warning," but when
>you get down to the nitty gritty details - like *how much* warning,
>and how much effort the researcher should make, and how the vendors
>should respond - suddenly you realize that there's a lot of variety.
>
>You speak of "harnessing" vulnerability researchers.  A number of
>people have said that the current RVDP draft asks too much of
>researchers, including Georgi Guninski and Rain Forest Puppy (and some
>vendors).  That feedback will be taken into account in the next
>version.
>
>In the meantime, the current RVDP draft already has a number of
>suggestions for vendors:
>
>3.3.1 Vendor Responsibilities
>
>   1) The Vendor MUST make it as easy as possible for Reporters,
>   Coordinators, Customers, and the Security Community to notify the
>   Vendor of vulnerabilities.
>
>as well as:
>
>   3) The Vendor SHOULD ensure that its staff knows how to recognize a
>   reported security issue and direct it to the Security Response
>   Capability.  This recommendation applies to staff who provide support
>   online, over the telephone, in person, or through some other means by
>   which reporters may interact with the Vendor.
>
>as well as:
>
>   6) The Vendor MUST provide a facility for individuals or
>   organizations who are not Customers to report vulnerabilities.  The
>   Vendor SHOULD NOT require (1) an active technical support number, (2)
>   telephone access that is not toll-free, or (3) user registration for
>   a web site or other facility that would be used for reporting.
>
>
>If more vendors follow the recommendations in the current draft, it
>will be easier for people to report vulnerabilities to them, which I
>think is a good thing.
>
>
>>Or do you mean the one-off vulnerabilty report, the one that some
>>individiual stumbles upon and sends it off to the lists.
>
>If the one-off person knows about security-related mailing lists, then
>hopefully they'll know something of disclosure issues.
>
>>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.
>
>If there is enough awareness of disclosure issues in the IT community,
>then hopefully this won't happen as much.  However, as you say, there
>will always be people who won't follow the disclosure guidelines.
>
>You may be surprised to learn that the RVDP draft specifically tells
>vendors that they should be prepared for such a situation:
>
>  3.3.1 Vendor Responsibilities
>
>     7) The Vendor SHOULD recognize that inexperienced or malicious
>     reporters may not use proper notification, and define its own
>     procedures for handling such cases.
>
>
>I've mentioned at least 4 vendor requirements from the current draft,
>which would make the notification process easier for researchers.
>
>>Is there then a third set out there that needs this guidence everyone
>>is hollering about?
>
>I think so, and that's the people who are somewhere in between - maybe
>they're not professionals, but maybe they like to do research for fun,
>to analyze the software they use themselves, to build a resume,
>whatever (and before someone misinterprets what I just said, I
>personally don't think that there's anything wrong with doing research
>for resume-building).  Sometimes, it seems that researchers start out
>by releasing advisories without notifying the vendor, then as they
>gain experience, they work with the vendor more and more.  But I don't
>have any hard numbers to back that up.  Indeed, the whole area of
>disclosure is woefully short of hard numbers.
>
>- Steve
>_______________________________________________
>Full-Disclosure - We believe in it.
>Full-Disclosure@...ts.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

wmYEARECACYFAj1LGmUfHGNob29zZS5hLnVzZXJuYW1lQGh1c2htYWlsLmNvbQAKCRDT
5JkCl0iMkPW/AJ4k/WgRMA8UF6OiMLG8MgACO6O3FACdFIqqRD6zgXL96iEVHMw1yhJD
7oI=
=m0a6
-----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

Powered by blists - more mailing lists