|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] CVE Review Meeting summary - Friday Aug. 13
Below is the summary for the CVE Review Meeting. I welcome any feedback. The most salient points are related to use of the term "CVE compatible" instead of "CVE compliant," the recognition of a greater responsibility for members to vote (even if it's a NOOP) and for the Moderator to ensure adequate voting, keeping most aspects of the Editorial Board informal, publication of references, and the possible benefits of private channels for discussion of some candidates. - Steve Attendees --------- Craig Ozancin (Axent), Bill Fithen (CERT), Mike Prosser (L-3), Andre Frech (ISS), Steve Christey (MITRE), Margie Zuk (MITRE), Dave Baker (MITRE), Bill Hill (MITRE) Lunch with Pete Tasker (Director, MITRE Security & Information Operations Division) and Jeff Sebring (Department Head, MITRE Enterprise Security Solutions Department) Introduction ------------ Margie Zuk and Steve Christey presented thoughts on how the Editorial Board is evolving, and included some proposals for further refinement of the process and structure. These proposals were intended to begin the dialog on these issues and gain feedback. This review summarizes those discussions, but any of the presented issues may be addressed by the Board. Roles and Responsibilities -------------------------- Board attendees were comfortable with leaving roles and resonsibilities fairly undefined at this time, since most participants play multiple roles, and the process seems to be working fine at this time. The one distinction is the Moderator, who will be the focal point through which some Board activities will take place. Members can be voting members, or non-voting members (observers). Observers could be on the Board's mailing list, but generally wouldn't participate directly in Board activities. While responsibilities will not be specifically identified at this time, there should be overall guidelines and guidance. Some of those are already discussed in the slides, and cover "minimum" participation for members (to be interpreted by the Moderator). While Board members should show an appropriate level of participation, the Moderator should interface with members to keep their participation active, or accommodate situations where they may need to be inactive. Attendees had no problem with multiple people from the same organization being on the Board and voting, e.g. if multiple individuals bring their technical expertise to Board activities. A number of active organizations have more than one member; generally, one is a voting member, and another is an observer. Attendees were comfortable with this approach, and did not believe that it posed a significant problem if one vendor had more members on the Board than another. Voting ------ In many cases, the "Silence = Assent" rule is not appropriate and could produce inaccurate results. Therefore, members should be encouraged to vote on specific issues. It was suggested that to effectively decide an issue, at least 75% of active members should vote - though in practice up to this time, the percentage has rarely been that high. A "No Opinion" or "Abstain" vote should be allowable, and voters should be allowed to respond personally to the moderator if they wish. Voting activities should be public where possible, although in some cases they could be held in private, e.g. for acceptance or removal of a member, or for some other (hopefully rare) issues. It became clear during the Review meeting discussions that sufficient validation for a candidate is a requirement for its acceptance. Independent validation by 2 Editorial Board members, or more, should be used to provide a sufficient guarantee that the vulnerability being discussed truly exists. The voting "ballot" provided for individual candidates could be modified to allow Board members to register whether or not they have independently confirmed a vulnerability. Member Acceptance/Removal ------------------------- While largely informal, it was recommended that the Moderator should initiate Board discussions for either acceptance or removal. A private vote is held in either case, to avoid potential embarrassment. In the case of removal, the "public" face of the removal may merely indicate that someone has become a non-voting member, or an observer; the percentage of yes/no votes should not be provided. Attendees did not believe it was important to overly formalize the criteria for the removal of a member; the reasons outlined in the slides were useful (e.g. abuse of membership, insufficient participation, etc.) Size ---- No limits for the size of the Board were discussed - play it by ear at this time, and reevaluate if the Board's size becomes too unwieldy. Periodic Meetings ----------------- A meeting will be held Oct. 3 before SANS, in order to discuss the CVE "big splash" to be held that week. Meetings should be regularly scheduled; at this time, quarterly seems appropriate since the CVE and the Board are still under rapid change. They could be held before or after a conference at which some Board members may be present. A teleconferencing capability may be useful to allow other non-attending Board members to participate. Meetings could also be moved around different Board member facilities. This would allow Board members to talk to other people in the host's organization. Voting and Affiliation ---------------------- Review meeting attendees were comfortable with having both "individual" and "representative of company" roles, though they did not see a need to formalize those roles. The individual should make it clear which "voice" they are using when they speak, and MITRE should make certain to reflect that voice. Strongly related to the Editorial Board may be a "CVE Alliance/Partnership" which consists of *organizations* that are actively participating in the public release of the CVE, and/or release of vendor mappings. The CVE Alliance/Partnership may be useful in introducing the Interoperability Demo at SANS Network Security '99. Speaking for the Board ---------------------- The Moderator speaks for the Board, or appoints someone else to do so. In some cases, it may be appropriate for the Editorial Board itself to make statements as a group on various issues, e.g. "publicly sharing data is good, even if sometimes it helps the hackers." The Board may provide an opportunity to present a unified voice for a broad variety of perspectives and constituencies. There are no restrictions to Board members for talking about their activities on the Board, provided they are speaking for themselves or their company. For the initial CVE release, it's agreed that press releases, statements, or other "promotional" considerations should be coordinated to have the most significant impact in the community. In general, it is recommended that organizations should verify their press releases where possible, e.g. when describing what type of company MITRE is. CVE Searchability ----------------- What terminology should be used when describing how a database/tool "speaks" CVE? CVE "compliance" implies some degree of verification. "CVE searchability" is descriptive of web sites or databases, but not interoperability. "CVE compatible" seems appropriate, and should indicate a good-faith effort to use CVE names where possible, maintain accuracy, and fix inaccuracies when discovered. We may also want a phrase for "milder" conformance or support, e.g. CVE-Friendly (or "CVE-supportive"). So supporters of the CVE, or people who reference CVE but don't have databases, can indicate support. To prevent abuse of this phrase, it was recommended that MITRE should trademark the CVE term (to prevent it from being co-opted by another entity who trademarks it, forcing MITRE to change to the term) and use a service mark for "CVE-compatible" and possibly other phrases. The Board doesn't think this will reflect negatively on MITRE in terms of "preparations" for commercial gain. MITRE will need to assume liability and take steps to protect the trademark (e.g. by preventing its abuse, as well as verifying the claims. There was a question about how specific the criteria for "CVE compatibility" should be. We should be specific enough to distinguish the MITRE evaluation of compatibility from evaluations that others might do. With respect to testing for compatibility, random sampling was suggested. However, a more "focused" sample might be better, i.e. a sample that's designed to reflect significant content decisions or places where inaccuracy can be a problem. All testing *MUST* be specific to a CVE version, since the CVE can change significantly from week to week, especially as we try to back-fill older vulnerabilities. CVE vs. CMEX ------------ There was strong support for making the references available to the public, since they help to verify that you know what vulnerability you're really looking at. But how can we cleanly separate the references (a CMEX item) from the "pure" CVE? With respect to universal attributes and categories, they are extremely useful to people who map to the CVE; but they aren't necessary to the general public. Therefore we can make this portion of CMEX available to those mappers who request it. With respect to the Universal attribute, we could use it to create a "Universal sublist" which could be downloaded from the site, for those individuals who prefer using the Universal vulnerability definition. References to private information sources may be useful, but they should be kept in a separate extension (not CMEX). Distribution of these references was not discussed. Private Channels to Discuss Candidates -------------------------------------- There are a few situations where private communications may help to facilitate the proposal, discussion, and acceptance of some candidates. Private channels may be useful for discussing emerging (but not publicly known) vulnerability information, in order to (a) present a candidate whose acceptance is nearly guaranteed, or even (b) to hold private votes on some candidates, in order to present an accepted CVE name in advisories. Both uses may help to reduce the lifetime of a candidate number for some newly discovered vulnerabilities, which may prevent some confusion between CVE candidates and CVE vulnerabilities. If a full vote for acceptance is conducted in a private channel, those votes must still be made public upon acceptance. Some candidates may be proposed for which public information is not available (e.g. when a vendor discovers a vulnerability in their own software, or a response team is notified of a new problem that has not yet been publicly discussed). Private discussions may be useful for other Board members to understand the candidate, or to validate it independently. This could streamline the candidate's acceptance. Thus when an advisory is released, that advisory may reference a candidate number or, in some cases, a CVE number. A Board member may have private discussions with other "trusted" Board members. In some cases, the proposer of the candidate may be prevented from releasing too much information about the vulnerability.
|
||||
