|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [CVEPRI] Editorial Board Teleconference Summary - June 21, 2001
Editorial Board Teleconference Summary - June 21, 2001 ------------------------------------------------------ Participants ------------ Participants in the teleconference included: Bill Fithen (CERT/CC) Tim Collins (NFR) Renaud Deraison (Nessus) Dana Foat (NSA) Andre Frech (ISS) Peter Mell (NIST) Ron Nguyen (Ernst & Young) Shawn Hernan (CERT/CC) Scott Lawler (DOD-CERT) Larry Oliver (IBM) Pascal Meunier (Purdue CERIAS) Marcus Ranum (NFR) Adam Shostack (Zero Knowledge) Kevin Ziese (Cisco) Alan Paller (SANS) Andy Balinsky (Cisco) Ben Greenbaum (SecurityFocus; proxy for Elias Levy) MITRE participants included: Dave Baker Steve Christey Margie Zuk Bob Martin Andy Bair Barbara Pease Content Update -------------- Currently, there are 1510 entries and 1120 candidates. The content team continues to process the legacy submissions that were obtained from databases provided by Editorial Board members. All submissions have been matched against each other and formed into groups of closely related submissions. There are roughly 4500 submission groups, from approximately 8500 total legacy submissions. Since there were 10 databases provided to MITRE, this shows how little overlap there was between databases, as the average group only included submissions from 2 databases. So far, approximately 500 of these legacy submission groups have been refined. About 150 legacy candidates will be created from these groups. The other 350 groups are duplicates of existing CVE entries or candidates; they will help to extend the references for those items, however. Some content team members are working on refining new submissions into candidates. A description of the submission process is in the "Submission Stage" section at http://cve.mitre.org/board/archives/2000-08/msg00013.html CVE Naming Scheme Changes ------------------------- There are various problems with the current CAN-YYYY-NNNN / CVE-YYYY-NNNN scheme. It can be difficult to find these items from most search engines (the hyphens can be problematic). When a candidate changes to an entry, the CAN prefix of the name is changed to CVE; this increases maintenance costs for CVE-compatible products, since they need to change the name from a CAN to CVE. One database was observed to have some "CAN" numbers for issues that had been converted to CVE entries about 7 months ago, and it is suspected that this problem is typical. Also, if a person searches a product using the CAN-YYYY-NNNN number, but the product has the problem indexed under CVE-YYYY-NNNN, then the person may not find that issue. The current naming scheme only allows for a maximum of 10,000 issues per year, which might not be sufficient in some cases (this is the "CAN-10K" problem). Some CVE-compatible products drop the CAN/CVE prefix altogether and just use a "YYYY-NNNN" scheme. Other problems were discussed and are documented in the next section. Given these problems, it may be appropriate to change the current naming scheme. For example, a single identifier could be used for candidates as well as entries, and the entry/candidate status could be provided as a separate field. Any change, however, could have a major impact on all CVE-compatible product developers, as well as CVE users. Participants in the teleconference said that the impact of such a change would have minimal effect on their own products. Board members agreed that it is important to minimize the number of changes to the naming scheme, otherwise CVE would lose the major advantage of providing a common and stable identifier. If a change should occur, it should only happen once; so, all known problems with the scheme should be addressed at the same time. To assist in the transition to a new scheme, MITRE would need to maintain the old naming scheme alongside the new scheme for a sufficient period of time, perhaps 6 months or a year. MITRE will provide a mapping from the old scheme to the new scheme, which will always be available on the CVE web site. There could be some problems with old advisories that reference CVE names. Those advisories would need to be updated where possible, but there may be older copies that cannot be changed, such as mailing list archives. The advisory provider already has some a small maintenance cost for changing a CAN number to a CVE number anyway, so it makes sense to provide a single identifier. MITRE plans to notify advisory authors when their CAN's become CVE's on a regular basis, but this would not be necessary with a unified scheme. Addressing Misuse and Information Leaks of CAN Numbers ------------------------------------------------------ CAN numbers effectively encode time, which releases potentially sensitive information such as how soon a vendor knew of the issue. Users may like this capability in gauging a vendor's response time, and it may also show how long a researcher has worked with the vendor on an issue. For example, Rain Forest Puppy reserved CAN-2001-0001 for an issue, but the vendor was slow in fixing the problem. RFP was eventually forced to publicize the issue, when most candidates being published were in the "200" range (CAN-2001-02xx). Some Board members agreed that it could be important to hide this information, possibly due to previous agreements with vendors. They agreed that while it might be useful to some people, it was not essential to have the candidate name effectively reflect the date of assignment. It is also suspected that information in the CAN/CVE name is already misused by the public. For example, many probably assume that the year portion of the number is when the issue was first publicized, not when the candidate number was assigned to the issue. There may also be cases in which an entity reserves a block of candidates which are not assigned to an issue for weeks or months; sometimes an "old" candidate number may be publicized for a brand new issue, which could cause confusion on the part of users, or make it appear that the issue has been known for a long time. CERT/CC has a numbering scheme that allows them to provide effectively random numbers that don't give away any temporal information. The Board will discuss this approach when considering a new scheme. While the current scheme is still being used, MITRE will provide more prominent disclaimers that CAN/CVE numbers do not imply when an issue was first known, when it was publicized, etc. MITRE will add these disclaimers to individual candidates (especially those that are reserved) as well as the full downloads for the CVE and candidate lists. Discussion of Candidate Numbering Authorities (CNAs) ---------------------------------------------------- A detailed proposal for Candidate Numbering Authorities (CNAs) was sent to the Editorial Board mailing list on June 14, 2001, with the subject "[TECH] Candidate Numbering Authorities". So far, various organizations have reserved a total of 170 candidate numbers for use in first-time public announcements of vulnerabilities. Approximately 150 of these have been published. Some Board members have wanted more rapid response in terms of assigning candidates to new issues, sometimes within hours after the issue is first published. MITRE's content team is currently unable to meet these needs, as some members are also processing the legacy submissions, and all are still learning how to apply CVE content decisions appropriately (though much progress has been made in the last 6 months). Candidate Numbering Authorities (CNAs) could obtain blocks of candidate numbers from MITRE and assign them to new issues, without directly involving MITRE. CERT/CC and SecurityFocus could be other CNAs, as they are already involved in the disclosure process as third parties (intermediaries between researchers and vendors). Major IT vendors with a large product line could also be CNAs for their own products. For example, Microsoft is already a de facto CNA, as MITRE provides them with candidate blocks that they assign to issues without consulting MITRE. A CNA must be an Editorial Board member, since the CNA must be familiar with CVE content decisions and the assignment process; indeed, the CNA may be involved in modifying these. As a side effect, the screening process for Editorial Board membership could be used to filter out unqualified CNAs. It was suggested that distributing candidates across all parties could be difficult to coordinate, especially when multiple vendors are involved. However, Board members did not think that it would be a significant problem, as the process for coordinating such information is already largely in place. It had been proposed that each CNA could have its own "policy" that reflects how quickly it responds to a researcher's request for a candidate number, how closely it works with vendors, what guidelines the researcher must follow in terms of disclosing the problem, etc. The intention was to allow multiple CNAs who used different disclosure policies, different response times, etc. For example, MITRE's own "disclosure policy" for researchers might be more restrictive than that of SecurityFocus. Some Board members suggested that CNAs should all follow a common minimal policy for "responsible disclosure," such as working with the vendor to fix the problems, or giving unresponsive vendors sufficient time before releasing. If researchers do not follow that policy, then the CNA would not provide them with candidate numbers. Participants agreed that this was a good approach. There was some discussion regarding the impact of current disclosure practices on CNAs. For example, some researchers may want anonymity to shield them from threatened lawsuits. If the researcher wanted to remain anonymous, but abused the CVE process, then the proposed approach would require the CNA to notify MITRE of this abuse; this might not be feasible. At the least, the CNA should avoid providing candidates to such researchers in the future. Some Board members said that a CNA should publicize the conditions under which they would protect the anonymity of disclosers. Some Board members were concerned with how the CNA should protect the vulnerability information before public disclosure. It was proposed that MITRE could set the technical policy that is specific to CVE, and the CNA could define its own operational policies and procedures. MITRE will still be available as a CNA to give out candidates to requesters. Anybody who asks for one, gets one, provided they make it public. To date, all requesters worked with vendors. MITRE's response time can be as fast as 2 to 3 hours, but MITRE can't formally commit to less than 2 business days. Others may advertise a better/faster response time. MITRE would ask the researcher who they contacted at the vendor. There was a brief discussion of the concept of "vendor liaisons" for CVE. The idea is to allow any vendor to participate in CVE by acting as a liaison - consulting with MITRE or other Board members on existing CVE candidates or entries, or by using candidates in its own security advisories. Such vendor liaisons would not need to have the skills and resources to be full-fledged CNAs or Board members. It might be useful to publicize such liaisons on the CVE web site so that researchers and other CNAs would know that they could work with the liaisons on obtaining candidates. MITRE will continue to clarify this role. Board Membership Issues ----------------------- Formalized roles, tasks, and expectations were proposed to the Editorial Board mailing list on June 7. See: http://cve.mitre.org/board/archives/2001-06/msg00002.html http://cve.mitre.org/board/archives/2001-06/msg00003.html The overall participation by Board members was higher than originally thought; defining the roles, tasks, and expectations has helped to clarify how Board members participate in the CVE Initiative. However, it is also clear that voting and other activities need more participation than the current levels. While the Board currently consists of 40 member, it might not be enough to accomplish all the work that is needed. Since then, Steve Christey consulted with approximately 10 Editorial Board members regarding their role in the CVE Initiative. These one-on-one discussions proved useful in clarifying the roles and tasks for these members. While there are too many Board members to maintain this contact on a regular basis, Steve and other MITRE personnel will work to maintain contact. More frequent teleconferences might also help in communicating with Board members. It is expected that some members will move to Emeritus status, if they have made significant contributions to the Board. MITRE is still clarifying this role. For example, if a member occasionally makes contributions to the CVE Initiative and then leaves, they might not necessarily achieve the Emeritus status as currently defined by MITRE. However, such members should be recognized in some fashion. Some members may be asked to leave the Board. Steve Christey has consulted with those members. Each member has expressed a desire to stay on the Board. Each member agreed to a 2 month evaluation period during which it is expected that they will raise their level of participation. Adding New Members ------------------ The Board discussed a basic approach for adding new members. In the March 2001 meeting, some Board members suggested that MITRE could ask Board members for feedback on prospective members. When MITRE recommends a potential member, the Board could be given a time limit (at least 2 weeks) to object or provide other feedback. A different approach would involve having Board members cast a formal vote. Participants anticipated several problems with a formal vote, such as handling conflicting "accept" and "reject" votes. Some members discussed the possibility of having a trial membership period for new members, possibly 2 or 3 months. This approach would allow the new member, and MITRE, to be certain that the new member can accomplish his or her tasks. In the March 2001 meeting, some members had expressed concerns with trial membership. There was mixed reaction during the teleconference. In general, it was agreed that trial membership would not be necessary; MITRE could closely monitor new members and remove them from the Board if they could not participate effectively. Given the feedback by the Editorial Board, the basic process for adding new members will probably involve the following steps: 1) MITRE will conduct the initial screening of the prospective member (similar to MITRE's current screening process). 2) MITRE suggests the prospective member to the Editorial Board on a private mailing list. 3) Board members may provide feedback as they see fit. 4) After at least a 2 week period, MITRE decides whether to add the member, based on feedback from the Board and its own evaluation. Currently, MITRE is delaying the review of approximately 10 prospective members until the new process is established. Miscellaneous ------------- The following topics were also discussed during the teleconference. MITRE's lawyers sent a response to the vendor who threatened to sue MITRE for publishing a candidate for their product. The response is available to Board members upon request. Other Board members had been threatened by the same vendor, but they did not respond legally, because the vendor didn't use formal legal channels. The next face-to-face meeting may take place in mid-September, possibly the week of September 17. A hosting organization has not been found yet. A side meeting could be held at the RAID Conference, and an informal meeting could take place at Black Hat. The next teleconference will take place in late July or early August.
|
||||
