[<prev] [next>] [day] [month] [year] [list]
Message-ID: <200208060151.VAA23775@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:
>What are the penalties now for not abiding by this guideline, or any
>other guideline that might be out there.
We explicitly stayed away from defining what the penalties are.
That's outside the scope of the recommendations - the "marketplace"
may decide, or perhaps, the legal community may decide. If there are
no guidelines at all, then perhaps "the government" will decide (which
obviously has its own issues, in an international community such as
information security.)
>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.
It at least establishes a point of discussion. Whether you agree with
the particular points of the draft or not, they can be compared to the
facts (or apparent facts) of the situation.
For the ISS/Apache issue, it seems that nobody disputes that ISS gave
Apache less than 7 days to respond to the initial report, before they
published. This is not consistent with the spirit of the disclosure
draft (I just took a look at it, and while it requires the vendor to
respond within 7 days, it doesn't have a complementary suggestion that
the reporter should give 7 days to the vendor! whoops). In the
ISS/Apache case, we have the further complication that multiple
vendors were involved (a difficult issue that is not addressed by the
current draft, except in its recommendations for involving
coordinators). Without community-defined guidelines, there are no
clear boundaries to say whether ISS did things "reasonably" or not.
The SnoSoft/HP issue is more complicated and not cleanly addressed by
the disclosure draft, which does not cover accidental or unauthorized
releases, and is not comprehensive on the role of third party
coordinators. I think it demonstrates some of the complexity in
vulnerability disclosure. Some people have argued that this means
that there shouldn't be *any* guidelines, but I believe that we should
try to be as detailed as possible in the guidelines to reduce
confusion, provide flexibility where it is needed, and do what is
possible to avoid regulations that may come from outside the IT
community.
- Steve
Powered by blists - more mailing lists