The Internet Engineering Task Force (IETF) received a draft proposal called "Responsible Vulnerability Disclosure Process" (RVDP), written by Steve Christey of MITRE and Chris Wyposal of @Stake, which the writers hope will become a published Request for Comments (RFC) standard. The document outlines a proposal of how users should report security vulnerability discoveries to vendors and how reporters and vendors should disclose these vulnerabilities to the public.
As Security UPDATE reported in November 2001, Microsoft headed up the draft proposal effort by bringing together five companies (@stake, BindView, Foundstone, Guardent, and Internet Security Systems) to help draft the RVDP that was recently submitted to the IETF. Microsoft chose the participating companies based on their "sterling reputations" in the arena of security-vulnerability information release. IETF publishes RFCs and serves a loosely knit group of people who want to contribute to the engineering and evolution of the Internet. Anybody can take part by attending any of the three yearly meetings.
The RVDP proposes that a group of three entities take part in the disclosure process: a reporter, a coordinator, and the affected vendor. According to the RVDP, the reporting entity doesn't need to be the person who actually discovered the vulnerability. The proposal states that the coordinator "is an individual or organization who works with the reporter and the vendor to analyze and address the vulnerability. Coordinators are often well-known third parties." The RVDP states the rationale for coordinators: "A coordinator may have resources, credibility, or working relationships that exceed those of the reporter or vendors. Coordinators may serve as proxies for reporters, help to verify the reporter's claims, resolve conflicts, and work with all parties to resolve the vulnerability in a satisfactory manner." The RVDP also states, "While coordinators can facilitate the responsible disclosure process for a vulnerability, the use of coordinators by other parties is not a requirement."
The guidelines in the proposal suggest that a reporter of vulnerabilities shouldn't disclose any information to the public until the reporter has given the related vendor 30 days to correct the security problem for its customers--except in circumstances where 30 days might not be long enough for a vendor to act. Stated circumstances include conditions where the problem "is related to insecure design; where the vendor has a diverse set of hardware, OSs, and/or product versions to support; or where the vendor is not skilled in security." In such cases, the RVDP suggests that a reporter should grant more time to the vendor so long as the vendor continues to act in good faith to resolve the matter. However, if a vendor is unresponsive or uncooperative, or some form of dispute arises, then the RVDP recommends that a reporter work with a coordinator to identify the best available resolution for the vulnerability.
The two main factors differentiate the RVDP from currently used reporting practices (such as RFPolicy ). First, the RVDP introduces the use of a third-party coordinator for reporting and resolving security risks. Second, the RVDP proposes that the three entities shouldn't inform the public of the existence of a given risk until the vendor has actually created a patch or a workaround for an affected product, or has stated it won't provide such information. The idea of a coordinator provides both the vendor and the reporter an entity to work with as a mediator, which might prove useful at times when reporters and vendors aren't friendly or cooperative with each other. The question remains unanswered as to who will hold themselves out as coordinators.
Because the RVDP simply suggests (and doesn't demand) that a reporter give a vendor 30 days to respond, it's still possible for reporters to use their discretion about informing the public of a given risk. The ability for the reporters to make judgment calls seems important for cases where the reporters think that waiting 30 days would seriously jeopardize using computers and networks securely. The reporters can also use their judgment in cases where they suspect that someone else may discover and disclose related exploit details before a vendor has time to act to protect its customers with a patch or workaround information.
The impending RFC, based on the RVDP proposal, is important because RFCs apply peer pressure to a large number of vendors and users so they'll adhere to any published RFC specifications. As the IETF points out, "The RFC series of documents on networking began in 1969 as part of the original Address Resolution Protocol (ARPA) wide-area networking (ARPANET) project. Each distinct version of an Internet standards-related specification is published as part of the RFC document series. This archival series is the official publication channel for Internet-standards documents and other publications of the Internet Engineering Steering Group (IESG), the Internet Architecture Board (IAB), and Internet community."
If you're interested in helping to shape any RFC, including the impending RVDP RFC, you can. According to "The Tao of IETF," anyone can register for and attend any IETF meeting. Section 1.3 of the document states, "Anyone who plans to attend an IETF meeting should join the IETF announcement mailing list, [email protected]. This is where the team posts all of the meeting information, Internet Draft and RFC announcements, and IESG Protocol Actions and Last Calls. People who would like to 'get technical' may also join the IETF discussion list, [email protected]. This is where discussions of cosmic significance are held. (Working Groups have their own mailing lists for discussions related to their work.)" You can read more about the lists in The Tao of IETF document at the IETF Web site.
