Jason etc.,
(disclaimer: I'm responding before reading every single thing that
everyone else has said (dangerous, I know!) and have tried to include
everyone who was CC'ed on different portions of the thread)
>[lots of commentary on the expired IETF disclosure draft, and the
>resulting gap, omitted]
Chris Wysopal and I withdrew the draft from the IETF because many
people in the Security Area Advisory Group (SAAG) questioned whether
or not the IETF should work to adopt "human practices" instead of
technical protocols (as Valdis indicated). We explored other options,
including possibly putting it under the FIRST umbrella, but the IETF
is a unique organization: there's international scope, high
visibility, a process for reviewing and approving documents, and a
fully open process for anyone to provide commentary. There is not an
equivalent organization for "best human practices." Instead, we have
decided to seek influential advocacy - but we need an updated document
before progressing.
At this stage, the Organization for Internet Safety (OIS), while
formed of commercial research companies and software vendors, is
moving forward on adopting and advocating some standards. While
Chris' parent organization is a part of OIS, he agrees that open
discussion is important. OIS does not provide this function.
All that said, I have intended to author and publish an update to the
draft that is independent of OIS. This may confuse matters a little
because many people mistakenly think that I (and MITRE) are part of
OIS, but the "vision" involves a number of issues that OIS has not yet
publicly commented on. We have found a hosting web site and some
prospective hosts for mailing lists.
A major component of the updated document(s) will be the vendor's side
of things - what their response capability should look like, etc.
There will also be a list of questions for customers to ask their
vendors - adapted from a disclosure talk I did at the Open Source
Security Summit in October - which may help customers to "pass the
message" on to vendors who have not established a response capability
yet.
We omitted most of the coordinator role for a practical purpose: we
weren't that familiar with the role (though CERT/CC did make
suggestions and say that it was important to cover). However, the
coordinator role has gotten more attention in this past year with
disclosure "events" such as Apache and BIND, as Florian Weimer
indicated, and the prominence of commerical third parties (such as
iDEFENSE) in this "pay-to-play" early disclosure, to put it crudely.
By the way, I left the early-notification angle out of the original
document to "keep it simple" - it was one of *600* comments by the 10
early reviewers - and people wonder why it was 29 pages! As Chris
indicated, there are a lot of complexities, but I'd like the updated
document to suggest/require publication of disclosure policies, which
will help the discussion focus on concrete details.
An "Executive Summary" of the draft's status is included below.
Notice how it specifically mentions DMCA. I apologize that I have not
been able to follow up on this activity as I had intended, but the
need for an update is clear, and so I will state a renewed commitment
to get something out there.
Valdis - many individual items of the IETF draft were controversial,
or needed important modification. The number of comments on the draft
has made it difficult to modify. Even the most basic point - that
vendors should get 30 days' notice before publication, unless
otherwise agreed to - was controversial (some researchers/admins
wanted less; some vendors wanted more).
Alan, Hal, and Clint - as you probably know, Dick Clarke is interested
in responsible disclosure. But I do have some concerns with the
direction that he and his staff seem to be taking in this department,
because it does not seem to fully account for the fact that many
non-professional and/or non-American researchers find vulnerabilities.
Jason, thanks for bringing up this issue again, I really need to do
something about it. Whether others in the industry think this or not,
I view "responsible disclosure" as one of my responsibilities and
invite people to hold me to this commitment.
- Steve
=============================================================
Responsible Vulnerability Disclosure (RVD): Executive Summary
=============================================================
Authors: Steve Christey (coley@mitre.org)
Chris Wysopal (cwysopal@atstake.com)
Date: August 14, 2002
------------
Introduction
------------
New security vulnerabilities in IT products are discovered and
publicized on a daily basis. Many information security professionals
believe that product vulnerabilities should be publicly disclosed, in
most or all cases. Unfortunately, many vulnerabilities are disclosed
before a fix is available from the vendor. Currently, disclosure
occurs in a haphazard way, due to factors such as breakdowns in
communication and conflicting interests of the involved parties.
Many vendors, security researchers, and other parties follow a variety
of unwritten or informal guidelines for how they interact when a new
vulnerability is discovered. Some parties may be unaware of these
guidelines, or they may intentionally ignore them. In addition, the
proper disclosure of vulnerability information has been a divisive
topic for years.
The "Responsible Vulnerability Disclosure" (RVD) draft proposal has
been created in the hopes of capturing the best current practices for
vulnerability disclosure. The draft proposes a responsible way that
minimizing the overall risk to network-connected systems due to
disclosure. It tries to balance the myriad needs or desires of
vulnerability reporters, product vendors or maintainers, third party
coordinators, the security research community, and customers and
users.
The current draft was originally proposed to the Internet Engineering
Task Force (IETF) in February 2002 and subsqeuently withdrawn, because
the IETF focuses on technical protocols as opposed to human policies
and procedures.
Based on extensive feedback from the security and IT communities from
February to August 2002, the original draft is being revised. The new
version will be made publicly available, but it will not be vetted
through any single organization or review process. Instead, it is
hoped that influential advocates will adopt the document and encourage
vendors, researchers, and other parties to follow its principles.
-------------
Draft Summary
-------------
At a high level, the draft makes the following recommendations:
1) Vendors set up an effective capability for responding to, and
resolving, incoming reports of vulnerabilities in their products.
2) Vendors make it easy for others to report vulnerabilities,
including non-customers.
3) The party who notifies the vendor ("notifier") provides vendors
with a reasonable chance to fix the vulnerability before it is
published.
4) When the notifier contacts the vendor, the vendor provides an
initial response within 7 calendar days, preferably more quickly.
5) The notifier and vendor work together to identify the cause of the
vulnerability and develop a fix
6) The involvement of a third-party coordinator is suggested, in order
to resolve disputes, act as an independent observer, and/or provide
additional technical skills.
7) All parties maintain contact at least every 7 days, unless another
frequency is agreed to.
8) The vendor resolves the issue as quickly as possible, preferably
within 30 days of initial notification, or with time extensions if
they are necessary and reasonable.
9) As a result of following this process, the initial public release
of the vulnerability (a) would contain sufficient information for
fixing or mitigating the vulnerability, and (b) is more likely to
be accurate than if the parties work separately.
-----------
Future Work
-----------
Our current goals are to:
(a) seek influential advocacy for the evolving documents
(b) raise awareness beyond the information security community,
especially to vendors and consumers
(c) maintain public dialog and review of all active documents
(d) release supplementary documents that address other aspects of
disclosure, e.g. what information should be included in security
alerts
(e) reduce or eliminate the chilling effects of legal threats against
vulnerability research, such as the inappropriate application of
the Digital Millenium Copyright Act (DMCA) to security
vulnerabilities