|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [CVEPRI] Request for vulnerability databases to populate CVE
All: If you have a vulnerability database or product, you are requested to provide your full database to MITRE so that we can generate and propose more legacy candidates. Note that this is already being considered as a requirement for CVE compatibility, since CVE must be made complete with respect to compatible databases. (See Section 3.2 of the first draft of CVE Compatibility requirements, at http://cve.mitre.org/Board_Sponsors/archives/msg00627.html). We are not asking for any non-public vulnerabilities you may have in your database. Participants who contribute their databases will be acknowledged on the CVE web site. As you may recall, in November 1999, 10 Board members sent in "top 100" lists of vulnerabilities from their databases, referred to as *submissions*. (Submissions are raw data items that are being considered for candidates). Unfortunately, there was very little overlap between all those submissions (almost 800 unique issues were identified!). As a result, many of them were for a problem that nobody else submitted. Many haven't been converted to legacy candidates yet due to lack of information. (During candidate creation, having multiple submissions available improves the quality of the candidates, as well as their chances for acceptance by the Board.) Having all the data available at the same time will help us to integrate all submissions related to a new candidate. We will be able to create better candidates for the Board to review. It will help us to tailor your voting, e.g. for candidates you've already got in your database, and/or for candidates that are in many databases. Tailored voting proved to be very effective during last August/September when we were preparing for the first release of CVE. Copyright restrictions will be followed, of course, and you can send it to us encrypted if you wish. If you are not comfortable with directly providing us with your database, we can work with you to sign an NDA. INFORMATION NEEDED ------------------ For each *submission* in your database, the following information is needed: 1) Your internal identifier for the submission. With this identifier, we can provide you with a *backmap* to the candidate numbers that are generated. This will further simplify your mapping efforts, since you will have the link from your ID to the candidate name. Backmap information will not be used for any other purpose without permission of the owners. 2) Description text and/or details. This information will be used to find submissions from other databases and create a candidate (if there isn't already a match). Description text will *not* be used in any resulting CVE candidates; we will write our own CVE-style descriptions. 3) References. References are critical for being able to correlate information from multiple sources. URLs are also requested for these references, if available. References will be added to the candidates. The following information is optional: 1) Associated CVE names. This only applies to those who have made their products CVE-compatible (or CVE-searchable or CVE-Reportable, a.k.a. CVE-Output). This will help us to (a) filter out those elements in your database when we do our submission matching, and (b) give us more data to help determine how to measure the quality and comprehensiveness of mappings. 2) Date of the public announcement of the problem. Some vulnerability databases have this information. It is useful for prioritizing which candidates to propose, and it may help other types of CVE maintenance. MITRE'S USE AND PROTECTION OF THE INFORMATION --------------------------------------------- Any other information in your submissions will be deleted. All individual submissions and backmaps will be clearly marked with a copyright statement. Their distribution will be limited to MITRE's CVE content team, who performs various tasks related to submissions. They will take steps to ensure that submissions are not inadvertently released or made accessible to anyone else. (As an example of this "need-to-know" in action, David Mann never saw a submission while he was at MITRE.) Anonymized submissions may also be provided to selected MITRE personnel with expertise in information retrieval and natural language; they can help to make the integration problem more manageable. FORMAT OF THE INFORMATION ------------------------- We will accept any format as long as it is formatted well enough that we can write a program, or use a commonly available application, to extract the information. ASCII text is preferred. The format can be comma-separated, HTML, XML, raw text, Excel spreadsheet, etc. We want to reduce the amount of work that you need to do as much as possible. In November, we found that our request for a specific format made it more difficult for contributors to provide us with the information. So we'll take care of the processing on our end. TARGET DEADLINE --------------- We would like to receive these databases by June 1. Last November, some Board members submitted their databases late in the process, during the *refinement* phase (i.e., after the submissions were grouped, they are *refined* into candidates). It is difficult to integrate new submissions into the refinement phase, so it is preferred that you provide us with your database by June 1. Thanks to all contributing Board members ahead of time. With enough people participating, we can identify and create the bulk of legacy candidates with this one large, focused effort. - Steve
|
||||