Message-ID: <200208022144.RAA29377@linus.mitre.org>
From: coley at linus.mitre.org (Steven M. Christey)
Subject: Re: it\'s all about timing

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

Powered by blists - more mailing lists