[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[TECH] "Responsible Disclosure Process" released
Most of you know that I have been working with Chris Wysopal to produce a document that describes a process for responsible disclosure. This is directly related to CVE in the following ways: - The Board has agreed that CNAs should not reserve candidates for people who do not practice responsible disclosure (candidates would be assigned *after* publication). I hope that this document, or a later version, will become part of the "definition" of responsible disclosure. - 50% of reported vulnerabilities are not clearly acknowledged by the vendor, which directly affects voting on candidates. - As I am starting to discuss more publicly, here and elsewhere, disclosure has other impacts on CVE content. The announcement is below. - Steve An Internet-Draft titled "Responsible Disclosure Process" has been released for commentary by me and Chris Wysopal of @stake. This Internet-Draft may be reviewed by members of the IETF and the general public. This is the first step towards establishing an RFC (Request for Comments) and Best Current Practices document. This document is *not* an RFC, and it does *not* represent a commitment by the IETF to produce an RFC. It is the first step within the IETF review process. It should be noted that we plan to create a "sister document" that will contain recommendations for the contents of security advisories. The curent Internet-Draft is focused on how the different parties interact, not the type of information that gets published. Abstract New vulnerabilities in software and hardware products are discovered and publicized on a daily basis. The disclosure of vulnerability information has been a divisive topic for years. During the process of disclosure, many vendors, security researchers, and other parties follow a variety of unwritten or informal guidelines for how they interact and share information. Some parties may be unaware of these guidelines, or they may intentionally ignore them. This state of affairs can make it difficult to achieve a satisfactory outcome for everyone who uses or is affected by vulnerability information. The purpose of this Internet-Draft is to describe best practices for a responsible disclosure process that involves vulnerability reporters, product vendors or maintainers, third parties, the security community, and ultimately customers and users. Acknowledgements We gratefully acknowledge the constructive comments received from several contributors. Any errors or inconsistencies in this Internet-Draft are solely the responsibility of the authors, and not of the reviewers. This document does not necessarily reflect the opinion of the reviewers or their parent organizations. We would like to thank Andy Balinsky, Mary Ann Davidson, Elias Levy, Russ Cooper, Scott Blake, Seth Arnold, Rain Forest Puppy, Marcus Ranum, Lori Woeler, Adam Shostack, Mark Loveless, Scott Culp, and Shawn Hernan for their valuable input. Obtaining the Internet-Draft The Internet-Draft is accessible from the following URL: http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-00.txt (this URL may have been wrapped by your email client). Note that the version number of this draft will change as it is modifed due to public commentary. Commenting on the Internet-Draft Discussion of this Internet-Draft is currently taking place on the IETF Security Area Advisory Group (SAAG) mailing list, although it is possible that the IETF may move the discussion to another location at a later date. SAAG mailing list archives and subscription information can be found at http://jis.mit.edu/mailman/listinfo/saag The IETF and RFC process A high-level description of the IETF and the RFC process is at http://www.ietf.org/rfc/rfc3160.txt Additional details on the Internet standards process are at ftp://ftp.isi.edu/in-notes/bcp/bcp9.txt ________________________________________________________________________ Steve Christey Lead INFOSEC Engineer The MITRE Corporation Chris Wysopal Director of Research and Development @stake, Inc.