[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[TECH] Assigning Candidates to Not-Yet-Published Security Problems
All, As you may know, several security advisories have included candidate numbers. ISS, rain.forest.puppy, and BindView have all released such advisories. Another entity (not a Board member) has also requested candidate numbers. I believe that requests from non-Board members will increase over time. The interest in candidates by non-Board members has raised some issues with respect to the "proper" way to assign candidate numbers to security problems before they are publicly announced. This email and the next one describe a new process that opens candidate assignment to non-Board members, while reducing the amount of potentially sensitive information that is required. (Until today, a draft advisory had to be reviewed before a candidate was assigned). We will be refining this process over the next few months. The process, outlined below, allows candidates to be assigned more quickly for non-public issues. It makes it easier for interested parties to obtain a candidate number even if they aren't a Board member. It limits the amount of interaction between MITRE and the requester, which reduces the amount of overlap with the activities of other entities like *Bugtraq and CERT. In addition, a rough concept of "trust" is included which may support a small degree of "self-policing" within the vulnerability analysis community. Note that we are not actively publicizing this new approach so that we have some time to test it with analysts who show the initiative to request a candidate number. Thanks to Bill Fithen, Russ Cooper, and Elias Levy for making incredible contributions to this new approach. I hope that this document captures their ideas effectively. - Steve Assigning Candidates to Not-Yet-Published Security Problems ----------------------------------------------------------- Last updated: May 22, 2000 Recently, there have been requests by security experts to obtain candidate numbers for new security problems that they are about to publicly announce. Some of these people are not Editorial Board members. Their requests have highlighted a need to develop an effective process of assigning numbers that can support non-Board members and minimize the overlap between CVE and existing notification capabilities provided by Bugtraq, NTBugtraq, CERT, etc. This document outlines an approach that MITRE is currently taking with respect to assigning candidates for security problems that are slated for publication, i.e. nearly ready to be posted to the *Bugtraq mailing lists or through other means. We are not proactively advertising this approach yet, but we will follow it when someone requests a candidate number. This will allow us to incrementally improve the process as more and more candidate "requesters" participate. Underlying Rationales For This Approach --------------------------------------- 1) Before now, MITRE has worked closely with the requester to determine the proper level of abstraction for a new issue, whether it falls under the CVE vulnerability/exposure definition, and whether it is truly new or not. This approach required a review of an early version of the advisory. While it minimized the potential amount of "noise," it made MITRE aware of non-public information. Extending candidate assignment to non-Board members is a reasonable approach, but it would significantly increase the amount of non-public vulnerability information that is provided to MITRE. This is an overlap with *Bugtraq, CERT, and other organizations that already have the infrastructure to handle non-public information. This new approach reduces the amount of review that is necessary before assigning a candidate. The benefit is a faster response, minimized interference with current processes, and the ability to allow a broader audience to obtain a candidate number which may then be included in advisories or other early announcements. 2) If a security problem is not reviewed before a candidate is assigned to it, there will be an increase in "noise" - duplicate candidates, rejected candidates, wrong level of abstraction, etc. This increases the workload for MITRE to maintain CVE, and for Board members to vote on it. So the risk must be minimized as much as possible. 3) If we only make candidates available to certain "trusted" people, then we face a slippery slope of deciding who can be trusted, and who can't. Some organizations or individuals may be reliable sources of new vulnerability information, but might not be "trusted" per se. An organization/individual should be able to acquire candidate numbers, provided they perform due diligence in avoiding duplication and ensuring that the candidate is appropriate for CVE. (See below). 4) The approach must minimize interference with the current way that new vulnerabilities are announced. For example, it shouldn't delay announcements any further than the current review processes that are in place at CERT, *Bugtraq, vulnerability analysis teams, etc. 5) Requesters should perform due diligence to ensure that the candidate has a strong probability of becoming an official entry without major modifications. Such requesters should be "rewarded" for due diligence. Due Diligence for Candidate Number Requests ------------------------------------------- Before requesting a candidate, the requester should perform due diligence in determining that the request is appropriate for CVE, i.e.: - the problem is genuine and reproducible by the requester - the problem does not already have an associated CVE number (candidate or entry) - the problem satisfies the vulnerability/exposure definition - the problem is represented at the CVE level of abstraction, as dictated by *approved* or *documented* content decisions. (CD's that are still under discussion by the Board are exempt, except where documented on the web site.) It is the requester's responsibility to perform due diligence in determining whether a new candidate number needs to be assigned, and the appropriate level of abstraction to use. If the requester does not perform due diligence, future requests for a candidate number may be denied. Because CD's are evolving and may change before final approval by the Editorial Board, and they are not currently well-documented on the web site, exemptions may be made with respect to CD-related discrepancies in candidates. The requester should only request a candidate when their announcement is almost ready for publication. The requester may consult with MITRE if they need additional information to ensure that they are assigning a candidate properly. A *Diligence Level* is recorded for the requester. The diligence level identifies how well an individual or organization performs due diligence for candidates. Diligence levels are described in a separate document. Candidate Request Process ------------------------- Before making a request, the requester should perform due diligence in ensuring that a new candidate number is required (see above). 1) The requester emails MITRE with a request for a candidate number. They do not need to provide any details about the associated security problem. 2) The requester's identity is verified to ensure that the request is legitimate, e.g. based on their email address. For new requesters, a verification email could be sent to the requester to verify the email address. 3) Each requester gets a *QUOTA* which defines the maximum number of "outstanding" (non-public) CAN's that the requester can have. New or unknown requesters get a quota of 1, and others get larger quotas based on accuracy and reliability. A separate document on diligence levels provides initial guidelines for determining quotas. 4) If the requester's quota is exceeded, their request for a new CAN is denied. Otherwise... 5) A new CAN is quickly assigned, and the requester is recorded in CMEX. The number of "outstanding candidates" for the requester is incremented. The CAN is published on the CVE web site with a default description saying that it is "reserved." No other information is provided. (This provides some basic information if someone looks up the CAN before the CVE web site has been updated with the full information). 6) The requester is emailed the new CAN, along with a boilerplate description of candidates that they should include in their announcement. The current boilerplate is: The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-YYYY-NNNN to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. Candidates may change significantly before they become official CVE entries. 7) The requester must notify MITRE upon publication of the candidate, and include at least one refererence to an established public source (*Bugtraq, news site article, etc.) Until this notification takes place, the CAN is considered "outstanding." 8) If the candidate is ultimately REJECTed or RECAST, then the discrepancy is noted. If the requester repeatedly requests candidates for issues that are RECAST or REJECTed, then the requester's quota may be lowered, possibly to 0. Exceptions are made in cases where a RECAST/REJECT is related to a CD that was unresolved or undocumented at the time the candidate number was assigned. 9) If the vendor acknowledges and/or fixes the problem, the requester should notify MITRE, since vendor acknowledgement improves the chances of a candidate's acceptance into the official CVE list. (Vendor acknowledgement counts as an ACCEPT vote in some situations). Diligence Levels and Assignment Quotas -------------------------------------- A separate document will provide informal guidelines for establishing the *diligence level* for a requester, i.e. how consistent they are with respect to publicizing candidates that ultimately become official CVE entries. Initially the document will be used by MITRE in determining quotas for new requesters, but the Editorial Board may review and modify them if appropriate. MITRE and/or Editorial Board members may evaluate the due diligence of requesters on an ad hoc basis, e.g. by reviewing the number of requested candidates that are REJECTed or RECAST. The guidelines provided above may provide a basis. This process will be refined as the need arises, and formal rules may be adopted if necessary. Open Questions -------------- The Editorial Board should consider whether or not the name of the requester should be published, and if so, how. Publishing the requester's email address may provide additional impetus for them to perform due diligence. The degree of authentication of the requester needs to be decided. At a minimum, an email address may be sufficient. In the longer term, support for PGP signatures would provide stronger authentication for the requesters who want it. Actions to be Taken ------------------- The following actions need to be taken to ensure that this process works properly. MITRE needs to establish a way for someone to request a new candidate, e.g. via email, and ensure that sufficient resources are set up so that a member of the CVE content team can make a candidate available within an acceptable time frame, e.g. 4 business hours after initial receipt of the email. The Editorial Board needs to review the "Diligence Levels" document and consider ways of determining diligence levels. MITRE needs to document content decisions and make them publicly available, so that candidate requesters can determine the appropriate level of abstraction and requirements for inclusion in CVE. In the early days of this new assignment capability, we should be "forgiving" about inconsistencies that are related to content decisions. The Editorial Board needs to review, modify, and approve (or reject) CVE content decisions when they are proposed. Until CD's are approved by the Board, candidates have an increased risk of a RECAST or REJECT.