[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[CVEPRI] Editorial Board meeting summary - 12/15/1999
All: Here is my summary of yesterday's teleconference. If I left anything out or you'd like to make some comments, feel free. - Steve CVE Editorial Board Review Meeting - 12/15/1999 ----------------------------------------------- Below is a writeup of the Editorial Board review teleconference that took place on December 15, 1999. Participants ------------ The following Board members participated in the teleconference: David Balenson Andy Balinsky Scott Blake Kelly Cooper Russ Cooper Andre Frech Craig Ozancin Mike Prosser Adam Shostack Tom Stracener Other participants included Marv Christensen (IBM ERS), Char Sample (L-3), and Jim Magdych (NAI). MITRE participants included Margie Zuk, Bill Hill, Dave Baker, and Steve Christey. A meeting was held earlier that day between Steve Christey and Eric Cole, who was unable to attend the teleconference. Candidate Status Update ----------------------- An update on candidates was provided. Various Board members confirmed that they will be voting on recently proposed clusters. In addition, some older candidates may be approved with one more vote. It is not certain yet whether the Board will achieve the goal of 500 entries by January 1. MITRE is working on ensuring that candidates are added for all known 1999 problems, a goal that was proposed and approved in the last Board teleconference. A question arises as to how we can be certain that we have covered all publicly known problems. We discussed the short term plans for candidates over the next month. "Semi-live" assignment of candidates will continue until mid-January. On a weekly basis, a candidate cluster will be proposed to the Board which identifies all problems that were announced in the previous week. Board members were encouraged to submit any additional problems that may be missing from these clusters. The CVE web site will be updated in mid-January to handle candidates. Search utilities and downloads will be enhanced for candidates; in addition, web pages describing the candidate concept will be included. Once the web site has been updated, live candidate assignment will begin. A "legacy cutoff date" will be set at that time; all candidates that were publicly known before that date will be considered "legacy" with respect to CVE. Introducing Candidates to the Public ------------------------------------ Different consumers of candidate information were identified. They include Editorial Board members who may use that information for voting and inclusion in their own databases; interested parties such as other database developers and data summarizers; visitors to the CVE web site; and casual observers who may only want high level information regarding how many candidates have been approved, etc. There is a potential complication with introduction of candidates into the public, and how candidates are currently processed by the Board. Typically there has been a delay between number asignment and proposal to the Board, e.g. for candidate clusters. It was suggested that a forced delay between assignment and proposal might actually be useful, as the understanding of the underlying issue may improve in that time. There was some discussion about the best way to introduce the concept of candidates to the public. Two basic approaches were discussed: make a formal announcement first, or just start using them and include short annotations when candidates are being used, e.g. in advisories. Formal announcements may be a challenge to do effectively, given the common misconceptions that the public already has about CVE. It was suggested to use a metaphor to educate the public about the differences between candidates and CVE entries: candidates are raw information which is not guaranteed to be fully vetted, like posts to NTBugtraq; CVE entries are refined and validated, like advisories. With respect to using short annotations in publications such as advisories, it was proposed that the following should be done: 1) Use a short phrase after the candidate number to emphasize that it is not a guarantee of inclusion into CVE. An example would be: CAN-1999-XXXX (pending validation) It was suggested to use the phrase "proposed" instead of "pending validation." There may be a small complication with this particular term since proposal is a specific phase in how candidates are processed, but there were no major concerns that this discrepancy in terminology would cause any significant misunderstanding on the part of the public. 2) Use a short descriptive text that explains what the candidate number is. The following sentence was proposed and discussed: "This is a candidate for inclusion in the Common Vulnerabilities and Exposures list, which standardizes names for security weaknesses. It is pending validation by the CVE Editorial Board." Various modifications were suggested for this text, including: - replace "weaknesses" with "issues" - emphasize that the candidate is a "temporary" identifier, and if the candidate is accepted, it will become a CVE entry - replace "validation" with "review" or "acceptance" The Editorial Board will further discuss this text on the mailing list. What Information to Publish --------------------------- The Board discussed the following information associated with candidates, and whether it should be made publicly accessible: - name and description - references - phase (assigned, proposed, interim decision, etc.) - associated content decisions - moderator comments - votes (who voted, and what the votes were) - voters' comments A sample web page was provided. Nobody expressed a concern that this information should be kept private. This information is already included in voting summaries, such as Interim and Final decisions for candidates. However, some people weren't sure if information such as votes and voter comments would be useful to many people, and if it was necessary to present it when it can already be seen in the mailing list archives. Voting comments might be useful to non-Board members who are interested in the issues surrounding a candidate, e.g. why it hasn't been accepted, or why it was ultimately split or merged with other candidates. A compromise was offered in which additional information could be provided to a user through an additional link or a checkbox. This would allow MITRE to determine whether that information is being used. Some Board members were surprised to know that voter comments were being recorded and publicly viewable. It was suggested that Board members be reminded that their votes and comments will become public, so that they can use appropriate discretion. Voting ballots will be annotated to include this reminder. Use of Candidates in Mailing Lists ---------------------------------- Some time was spent discussing the issues related to integrating candidate numbers into discussion forums such as the Bugtraq and NTBugtraq mailing lists. Due to how moderation of such lists is performed, the moderator is unable to modify the original text of a post in order to insert a candidate number. A followup to the original post that includes the number would associate the candidate with that thread; however, the original post would not be returned if a user searches an archive for a specific candidate number. An alternate method would be to have MITRE (or another CNA) provide a number to the moderator or the poster, who could then ensure that it is integrated into the original post. However, this could increase the amount of time it takes for the moderator to approve the message. A third option would be to have the moderators act as CNA's and take care of assigning numbers themselves, working from a block of candidate numbers that the CNA has allocated to them. However, this could result in increased "noise" for candidate numbers with respect to duplication or level of abstraction. For example, many content decisions in CVE are unresolved and have not been sufficiently documented for use by other CNA's, and there is an increased risk of duplication. While it is uncertain how risky this third option would be, Board members seemed willing to take this risk in the early days. Further offline discussion will take place with interested parties to determine the best approach. Frequency of Candidate Announcements ------------------------------------ There was some discussion about how often candidates should be made available to the Board, to interested parties, to the web site, or to the rest of the public. With respect to legacy candidates, a weekly schedule has appeared to work well. It was also agreed that weekly proposals of newly discovered candidates will be sufficient for most purposes, but more frequent updates could be made available on an ad hoc basis. It was suggested that each newly discovered candidate should be proposed in a separate email. A concern was raised that this would increase the amount of traffic to the list significantly; for example, 60 new candidates had been proposed in the previous two weeks. For newly discovered candidates, it will often be the case that when a number is assigned, it may be made available to the public before the candidate is proposed to the Board. For that reason, updates may need to be provided more frequently to interested parties. This could be done through regular web site updates or distribution to a "rapid response" mailing list. Implications of Public Candidates --------------------------------- Some implications were discussed with respect to making candidates publicly known. If CVE entries are not approved rapidly enough by the Board, then candidates may become the de facto standard. This concern could be limited by more efficient voting, which could be improved if Board members integrate candidate numbers into their database population activities. There are also some potential implications with respect to CVE searchable databases. A user may enter a candidate number into a CVE searchable database; how should a database handle this, e.g. if the candidate is associated with an approved CVE entry? It was re-emphasized that the notion of CVE compatibility will only apply to CVE entries, but it was recommended that CVE searchable databases consider the issues related to use of candidates for search. Private Candidate Assignment ---------------------------- A brief discussion was held with respect to the private assignment of candidate numbers to Board members who want to include the numbers in first-time announcements of new security flaws. A PGP key for the CVE content team will be made available so that those members can encrypt their transmissions if they wish. Members should request candidate numbers as close to their scheduled announcement date as possible. The candidate must be slated for public dissemination. To avoid potential competition with organizations that introduce new security problems to the public, MITRE will not announce or propose any candidates before they have already been publicized. As private candidate assignment may only be desired by a small number of Board members, it will be handled on an ad hoc basis. Roughly, the process may be as follows. The "requestor" submits information to MITRE with sufficient details for MITRE to look for duplicates, apply the appropriate content decisions, and generate a description. The requestor also states how quickly they need a response, which can be no less than 1 business day. MITRE returns a candidate number(s) and description to the requestor, deleting or encrypting the associated data to minimize potential information leaks. The requestor must then notify MITRE when the candidate has been published. To follow up with the requestor for updates on the status of the private candidate, MITRE would need to record who requested that candidate. Board members did not express a problem with MITRE keeping this information, provided it was not made available to any other organization. A potential situation could occur when a requestor asks for a private candidate number for a problem that has already had a private number assigned to another requestor. MITRE would be very limited in what actions it could take, as most solutions could result in some release of competitive information (e.g. by implying that an unnamed competitor is already working on the same issue). Since it is expected that this will rarely happen, it may be best for MITRE to assign a separate private candidate even though it is a duplicate of another private candidate, then merge the candidates before they are combined into a single entry, giving preference to the first requestor. MITRE will work offline with interested Board members on the mechanics of private candidate assignment. Processing Candidates --------------------- Various suggestions were made to Board members regarding how to process candidates. They included: - Voting on a partial cluster is better than no votes at all - Use NOOPs if you can't vote - Keep your database up-to-date with respect to new candidate numbers - Make ad hoc requests for candidates to vote on, e.g: - All CAN's with Microsoft advisories - CAN's needing only one more vote - Unix/NT problems [noisy and incomplete] - New/legacy problems proposed since YYYYMMDD Eventually, an online web site will support Board members in their voting activities. Until then, Board members can make ad hoc requests for such information. Next Face-to-Face Meeting ------------------------- Craig Ozancin said that AXENT is willing to hose the next face-to-face meeting in Salt Lake City, Utah sometime in February. A 2-day meeting will be planned, and a basic agenda will be posted. The Board will determine the specific date on the mailing list.