[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[CVEPRI] Summary of the August 14-15 CVE Editorial Board meeting
All, Below is the summary for last week's Editorial Board meeting. Thank you to everyone who participated! For us at MITRE, we find that these face-to-face meetings often clarify the appropriate direction for CVE, at least for the next few months :-) This meeting was no different. As a result of this meeting, we expect to make final decisions on a number of long-drawn-out issues. Expect this mailing list to be pretty busy for the next few weeks as everything is documented... As discussed at the meeting, the primary goal for the Editorial Board will be achieving 1000 entries for CVE by September 29. Enhanced voting support will be provided in the coming weeks to help Board members achieve this goal. I am looking forward to working with the Editorial Board to achieve this milestone. - Steve **************************************************************** Summary of the CVE Editorial Board meeting on August 14-15, 2000 **************************************************************** Attendees --------- The attendees of the face-to-face meeting were: Ken Armstrong (EWA-Canada/CanCERT) Andy Balinsky (Cisco) Casper Dik (Sun) Andre Frech (ISS) Bryan Kingsford (AXENT; proxy for Craig Ozancin) Scott Lawler (DoD-CERT) David LeBlanc (Microsoft) Ron Nguyen (Ernst and Young) MITRE participants included Steve Christey, Dave Baker, and Margie Zuk. The following participated by teleconference during a portion of the meeting: Kevin Ziese (Cisco) Mike Prosser (Symantec) Barbara Pease (MITRE) CVE Content Update ------------------ The Board was updated with the latest statistics for CVE content. The most recent version was 20000712, with 813 additional active candidates as of August 11. In recent months, the number of official CVE entries has been about the same as the number of candidates. This is an indication that the Board can keep up with the current flow of recent vulnerabilities, but may fall behind once new sets of legacy candidates are created and proposed. Of the 10,000 vulnerability submissions that MITRE is processing, approximately 600 have been matched against other submissions, CVE entries, or candidates. The focus has been on problems discovered in 1999. Once all remaining 1999 submissions are matched, they will be refined into legacy candidates. It is estimated that about 380 new candidates would be produced from the 600+ submissions that have already been matched. Latest CVE Content Goals ------------------------ The latest CVE content goals were presented. The primary goal at this time is to have CVE contain 1000 entries by September 29. This will be achieved by a number of means. Various content decisions will be resolved by September 1, which will allow some candidates to be moved to Interim and Final decisions. Also, tailored voting ballots will be sent to Board members. This approach worked successfully in September 1999 when preparing the first public version of CVE. MITRE also plans to finish processing submissions for the 1999 problems by September 15, with the final rounds of 1999 candidates to be proposed by October 31. An additional goal is to maintain more comprehensive sets of references for new candidates and entries, with a special focus on vendor and response team advisories. MITRE has relied heavily on its original data feeds, as well as votes by Board members, to provide references. Board members are encouraged to identify missing references when voting. Use of CVE Versions in Products ------------------------------- Participating Board members were asked whether their CVE-compatible products were up-to-date with the latest CVE version. Participants indicated that their products were not yet up-to-date. Most participants have an ad hoc process for integrating new CVE information into their products. It was emphasized that CVE versions will become more important for vendors and their customers to understand how up-to-date their products are with respect to CVE mappings. Submission Stage ---------------- Participating Board members were briefed on the submission stage in the CVE process. MITRE performs much of this work behind-the-scenes, but since it is a critical part of CVE, it was described in more detail. The CVE review process is divided into 3 stages: the initial submission stage, the candidate stage, and the entry stage. MITRE is solely responsible for the submission stage. The Editorial Board shares the responsibility for the candidate and entry stages. During the submission stage, MITRE collects raw information from various sources, e.g. the various Board members who have provided MITRE with their databases, or publishers of weekly vulnerability summaries. Each separate item is then converted to a "submission," which is represented in a standardized format that facilitates processing by automated programs. Each submission includes the unique identifier that is used by the data source. After this conversion phase, various utilities are used to help find which submissions are closely related (the "submission matching" phase). Presently, the main focus of MITRE's CVE content team is on submission matching. This will allow content team members to gain familiarity with CVE, as well as to understand how vulnerability databases may differ with respect to inclusion and levels of abstraction. Once matching is complete, related submissions are formed into submission groups. Each group is then analyzed and refined into a single candidate template (the "submission refinement" phase). Content decisions are applied to the submission group to determine whether the security problem should be included in CVE, and to determine the level of abstraction. A CVE-style description is written, and references are collected and presented in the canonicalized format used by CVE. Submission refinement is a bottleneck because deep analysis can be required to apply the content decisions and write the descriptions. In the future, members of the CVE content team will be participating in the refinement of legacy submissions into candidates. After submission refinement, each candidate template is converted to the CMEX data format and given a candidate number, which begins the the assignment phase of the candidate stage. After candidate assignment, each data source is provided with a backmap from their submission to the associated candidates. This in turn reduces the amount of effort that the data source needs to perform to maintain a mapping to CVE. After the backmaps for the candidates are generated, the associated submissions are removed from the submission pool. Candidates are then grouped into clusters, proposed to the Board, and moved through the candidate stage as described elsewhere. In addition to backmaps, a new type of map referred to as a "gapmap" is also provided to the information source. The gapmap identifies the newly created candidates that were not found in the data source's original set of submissions, which may make the source aware of additional security problems that they had not seen previously. It was noted that MITRE is providing backmaps and gapmaps as a value added for its data feeds only. This capability may not be provided once all legacy issues have been identified, although data sources for new information will continue to receive them. All CVE data sources will be credited on a web page on the new CVE web site. Managing CVE and Candidate Content Changes ------------------------------------------ Participating Board members discussed the processes for rejecting and recasting CVE candidates and entries. Candidate rejection was the initial topic. A candidate may be rejected for several reasons, including: (a) it is a duplicate of another candidate/entry, (b) the security issue was incorrectly reported, (c) as part of a RECAST, (d) due to insufficient references, or (e) due to insufficient votes. In the case of insufficient votes, however, there is a concern that a security problem may still be real, even if there are not enough Board members who believe so. The rejection process was described as follows. The CVE Editor (presently Steve Christey) will case a REJECT vote and move the candidate to Interim Decision. If the candidate is a duplicate of another candidate, it is left to the Editor's discretion as to which candidate should be REJECTed. The voting record for the candidate will note the reason for rejection. In addition, the description will be modified to include a specific keyword to make it clear that the candidate has been rejected. The candidate will be removed from the the list of candidates that is available for download from the CVE web site, in order to avoid any possible subsequent use of that candidate to identify a security problem. A list of rejected candidates will be made available upon request. Board members briefly discussed the idea of rejecting candidates that are related to very old vulnerabilities, e.g. the Sendmail WIZ problem, that may not be present in any networks. It was noted that even the WIZ bug may still be present. Also, even if such vulnerabilities are not found in the wild any more, they may be used for academic study or other reasons, so should remain in CVE. The process for performing a candidate RECAST was then discussed. A RECAST may occur when the level of abstraction (LOA) for a candidate is too high or too low. Since each RECAST will increase the maintenance costs for products that use candidates, a method needs to be selected that reduces the amount of maintenance, while avoiding changing the semantics of any existing candidates. Two approaches were discussed: (a) changing the LOA of existing candidates, or (b) creating a new set of candidates. All participants agreed that it would be best to create a new set of candidates and reject the old candidates. This would make it more clear when a product is using an old candidate number. The process for performing a RECAST was described as follows: - perform the RECAST during the modification phase - create or reject additional candidates in the same RECAST action - move all affected candidates to Interim and Final Decisions at the same time - if any new candidates are created, Board members must vote to approve them. However, these candidates would not be subjected to the minimum review period of 2 weeks, which is normally used for candidates that are newly proposed. - annotate the rejected candidates with the reason for the RECAST, and a pointer to any new candidates that were created as a result of the RECAST When the LOA is too high for a candidate, the RECAST operation would involve a SPLIT of the candidate into two or more lower-level candidates. The original candidate is REJECTed, and new candidates are created which reflect the lower LOA. If another candidate already exists at the proper lower LOA, then it may be reused. The original candidates are annotated appropriately to reflect the RECAST. In a similar fashion, when the LOA is too low for a candidate, it will be MERGED with other candidates. The original lower-level candidates are REJECTed, and a new candidate is created to reflect the higher LOA. If another candidate already exists at the proper LOA, then it may be reused. The original candidates are annotated appropriately to reflect the RECAST. In some cases, there may be a single candidate that is described at a low LOA, but whose description only requires a minor modification to change the LOA. For example, a security problem might be discovered in one Linux distribution, and the resulting candidate may only indicate that distribution in the description. If other distributions are also found vulnerable, then a "soft RECAST" could be performed by changing the description instead of creating a new candidate. Once a CVE entry has been added to the official list, it may also need to be modified, rejected, or recast sometime in the future. Board members agreed that the process should be consistent with that for candidates. After publication, minor modifications may be made to an entry, e.g. a small change to the description, or additional references. In the past, modifications have occurred without warning. Board members suggested that such modified entries should be made available for review by the Board to provide members with an opportunity to catch any errors. Such a review period could automatically expire after a period of time (e.g. a week), and the entries could be modified with no further comment. In the case of a potential RECAST or REJECT, the entry enters the Reassessment phase. The same procedure for candidates is followed with respect to performing the RECAST/REJECT. If the Board agrees with the decision, some entries may need to be rejected by entering the Deprecation phase. Participants agreed that once a security problem becomes a CVE entry, that it should not be deleted from the CVE lists, even if it is deprecated. Instead, all deprecated entries will be annotated with the reason for deprecation, as well as a special keyword to help CVE users easily find deprecated entries. CVE References -------------- General guidelines were presented for the ordering of references in CVE entries and candidates. The initial public announcement is listed first, followed by incident response team advisories, vendor acknowledgement (e.g. an advisory or patch description), and other public sources. Older candidates or entries may not have this ordering. In some cases, it can be difficult to create references for advisories that can't easily be found on the source's web site, or for advisories which do not have a clear identification number. The sources for CVE references were also discussed. Currently, only well-established sources are included, and each source must have some mechanism for public review, e.g. Bugtraq or NTBugtraq. However, vulnerability databases are beginning to include pointers to less established sources, e.g. the informal vulnerability analysis teams. In such cases, the CVE reference may refer to the original *Bugtraq posting or other reviewed source. However, since other databases are using these sources, they should be included in some fashion in order to allow CVE users to find the proper CVE entry. Minimum requirements for using reference sources were discussed. While not formalized, there was general agreement that a source should be in existence for more than a year (indicating some degree of stability), discover or publicize at least 3 vulnerabilities or exposures that become CVE entries (indicating some degree of reliability), and be used as a reference in some vulnerability databases. URL's for references are recorded with candidates to facilitate voting. However, the URL's are deleted when the candidate becomes an entry. Participating Board members agreed that URL's should remain associated with references for CVE entries, as it increases the usefulness of CVE for those who require more information. However, since this increases the potential for some "competition" with existing vulnerability databases, MITRE needs to ensure that all potentially affected parties agree with the usage of URL's. Reference maps were also described to the Board members. On the new CVE web site, each source will have a mapping which links the references from that source to the associated CVE entries or candidates. This allows someone who knows a particular reference to find the CVE items that are related to it. Reference maps are expected to be useful for anyone who performs mappings to CVE, as well as people who wish to quickly find all the CVE items that are associated with a particular source, e.g. CERT advisory number or the Bugtraq ID. Private and Out-of-Band Candidate Assignment -------------------------------------------- "Private candidate assignment" is the relatively new capability in which MITRE provides a requester with a candidate number so that the requester can include the candidate in the initial public announcement of the associated vulnerability or exposure. In general, the response time for private candidate assignment is 4 business hours or less. When MITRE has finished defining the process and infrastructure for reliably and rapidly providing candidate numbers to requesters, it will open private candidate assignment to all requesters. One way to enhance this capability would be to provide additional non-MITRE Candidate Numbering Authorities (CNA's) with a pool of candidates which they can distribute to requesters. However, various issues of coordination across CNA's must be resolved first. Some challenges that remain for private candidate assignment are: refining the process by which the original requester makes MITRE aware that the candidate has been publicly announced; how to reuse or expire candidate numbers that have not been published; and how to update advisories and other documents once the candidate becomes an entry. Most of these challenges can be resolved by providing additional documentation to requesters and relying on CVE diligence levels to curttail improper use. Out-of-band candidate assignment was also described. The objective of out-of-band assignment is to assign and announce candidate numbers as soon as possible for important vulnerabilities, e.g. those that would allow compromise of a large number of systems. In the past, Board members have agreed that it is not necessary to try and assign candidates the moment that an issue is published, so rapid assignment has been a relatively low priority for MITRE. As a result, candidate numbers are not immediately assigned when a significant issue is discovered and widely publicized. In the future, the CVE content team at MITRE will be more proactive in assigning candidates as soon as possible for important issues. Board members are invited to request candidate numbers for significant, recently published problems. Out-of-band assignment will become less necessary as vendors adopt candidate numbers into their advisories and private assignment becomes more commonly used. Therefore, MITRE will be working more proactively with organizations who release advisories, e.g. software vendors, security vendors and analysis teams, and response teams, to include candidate numbers in their advisories. Deep Analysis for Security Issues --------------------------------- An approach for conducting deep analysis of security problems was presented to Board members. During the submission stage, CVE content team members will spend a maximum of 1 hour of research per submission group, identifying potential duplicates and applying content decisions, and periodically consulting with other members. During the candidate stage, Editorial Board members and the affected software vendors may be consulted for additional analysis. Such candidates will be marked for further investigation. Results of all deep analysis will be made publicly available and linked to the associated candidates or entries. Validity of CVE Candidates -------------------------- Participating Board members discussed the validity of candidates. Some members expressed concerns that some entries may be approved without sufficient validation. The new voting web site, which will capture more detailed information for why Board members ACCEPT a candidate, will help to make this more clean. The general issue of confidence was discussed. Participants agreed that it would be very useful to CVE, and to the community as a whole, if each CVE candidate or entry was associated with a particular confidence level. In cases in which the affected software vendor publishes an acknowledgement of the problem, confidence in the problem's existence can be high. In cases in which vendors do not acknowledge the problem, a Board member may have verified it independently. Many participants agreed that they could indicate if they have verified the problem themselves. However, some participants validate a problem only before including it in a security tool; saying that the problem has been validated could give advance notice to competitors about enhancements to the vendor's tool. Participants agreed that this concern could be resolved if MITRE only publicizes that a Board member has validated the problem, without indicating which member has done so. CVE and IDS Issues (CIEL) ------------------------- MITRE presented the Board with a number of issues related to the inclusion of IDS events in the CVE list. Many events that are detected by IDSes do not have a clear association with vulnerabilities or exposures, e.g. port mapping. In cases where there is overlap (e.g. an IDS detect for an attempt to exploit a specific vulnerability), CVE descriptions focus on the nature of the security problem as opposed to how it may be exploited. A number of Board members and others involved in IDS work have expressed the desire to have CVE encompass all IDS events. Draft Common Intrusion Event List (CIEL) ---------------------------------------- MITRE is developing a draft list for IDS events, referred to as CIEL (Common Intrusion Event List, pronounced "seal"). CIEL development has helped to identify a number of issues that will need to be addressed by the IDS community. Presently, CIEL development is being conducted through an internal IDS project led by Bill Hill, although Steve Christey and Dave Baker are also involved. Since the draft CVE gave the CVE Initiative some legitimacy by providing a concrete list which Board members could work with, MITRE is taking a similar approach by creating a draft CIEL. This will help to identify CIEL content decisions (e.g. issues related to level of abstraction). Presently, the draft CIEL is being populated from several IDS sources, including Snort and arachNIDS, the DARPA CIDF attack list, and signature lists for RealSecure and NetProwler. In many cases, MITRE will be able to reuse some of its internally developed technologies which were developed to support CVE. While the draft CIEL is still being developed, interested members of the Editorial Board could begin discussion on some of the larger issues surrounding CIEL. Organizational Issues for CIEL ------------------------------ One fundamental question for CIEL is whether the CIEL effort should be pursued only by CVE Editorial Board members, or if a separate group should be created. Participants in the Editorial Board meeting agreed that a separate group would be useful, although there would likely be strong overlap between a CIEL "working group" and the CVE Editorial Board, the DARPA CIDF, and the IETF IDWG groups. Some Board members believed that the CIEL could ultimately become a bigger effort than CVE. With the creation of a new CIEL effort, there is an opportunity to pursue a different process model than that for CVE. For example, CIEL could be populated in a more rapid fashion by eliminating or reducing the "democratic" approach used for CVE, along with less review of CIEL candidates before they become entries, less consultation with others on content decisions, and/or no formal voting process. Regardless of the approach that is adopted, MITRE needs to assess how much of the CIEL effort it can directly support, especially given its own needs for CIEL for its internal project work, and the amount of work that remains to be done for CVE. There is also the risk that the Board and other participants in CIEL could be distracted from the current CVE work on vulnerabilities, as there will be many members who participate in both CVE and CIEL. CIEL Technical Issues --------------------- A sample of technical issues for CIEL was presented to the Board. CIEL entries may be much more difficult to find or look up than CVE entries for several reasons. First, the terminology used in the IDS world is less precise and consistent than that for vulnerabilities (e.g. "port map" vs. "port scan," or the many different ways of describing malformed packets). In addition, there are very few public references that could be used for CIEL entries. Accordingly, CIEL descriptions may need to be more detailed than CVE descriptions, and a more precise terminology may need to be defined. This requirement was further demonstrated by examining the CIDF attack list, whose event names are often too sparse to understand the nature of the event that is being described, and which contains items that may be duplicates (perhaps due to differences in terminology). In addition, content decisions for CIEL may be more complex and/or more directly affect the usability of CIEL for some IDS tools and databases. Based on the preliminary examination of the IDS signature lists identified above, there appears to be more variation in the level of abstraction used by various IDSes than the LOA's used by assessment tools and databases. CIEL Numbering Issues --------------------- Several numbering issues must be considered for CIEL, many of which have been identified in CVE. If CVE numbers are to be used to identify CIEL entries, then CIEL and CVE users would need to be able to easily distinguish between events and vulnerabilities or exposures. This would require providing separate downloads, and/or a new field which describes whether the associated CVE number is releated to a vulnerability or an event. There are some limitations to having a separate naming scheme for CIEL candidates than for entries. For example, for CVE, users must be educated about the differences between candidates and entries. Having separate candidate numbers also increases the maintenance costs for compatible products. For example, when a candidate becomes an entry, the product's mapping would need to be changed to reflect this. Finally, CIEL numbers should be easily findable. Since a CVE number has hyphens in it, many search engines split the number into smaller pieces, which makes it more difficult for search engine users to find CVE items using the CVE name. (For example, a search for "CVE-1999-0003" would find documents that contain the separate terms "CVE," "1999," and "0003.") The dual numbering system for candidates and entries poses some challenges for users of products that use both numbers. For example, if a user searches for CAN-1999-0003, the product should be to find the associated CVE-1999-0003 instead. Thus, either user education or more tool development would be required to support searchability in the case of dual numbering schemes. CIEL Abstraction Issues ----------------------- The Board was presented with some example issues related to abstraction. For example, one could have separate entries to identify different decodes for specific networking protocols, e.g. FTP commands such as USER, PASS, and CWD. Such abstraction choices also apply to communications protocols for Trojan Horses and DDoS utilities. The description of malformed packets also poses some challenges. For example, a TCP/IP packet could contain any combination of SYN, ACK, RST, SYN/FIN, and other flags. Each flag could have a separate entry, but there would also need to be a way to characterize all different combinations of the flags. Another area in which there are abstraction questions is that of detects for specific tools, e.g. Whisker vs. CyberCop Scanner vs. nmap. CIEL could have separate entries for each tool (a high cardinality problem), one high-level entry for any tool, or some other entry whose level of abstraction is somewhere in the middle. Issues such as the one described above indicate that CIEL may better serve its users by allowing multiple levels of abstraction to be represented. Dot notation, which has been approved for use in CVE but is not actively in use, may be insufficient to handle multiple levels. Participants in the Board meeting agreed that it would be reasonable for CIEL to be populated from what IDS tools use, which could address some of the abstraction problems described here. MITRE will continue to report on CIEL progress to the Editorial Board and other interested organizations. CVE Compatibility ----------------- MITRE provided the Board with an update on its approaches to CVE compatibility. MITRE is currently designing a special logo which will only be approved for use on CVE-compatible products. At a high level, the process will be as follows. The vendor will make a formal application for use of the logo. MTIRE will review the vendor's product for accuracy of the mappings, relative to a specific CVE version. Once approved, the vendor will be given formal approval to use the logo. MITRE will also be examining the possibility of supporting advertising on the CVE web site for CVE-compatible products. The role of CVE versions in CVE compatibility - especially reference versions - was discussed. Reference versions will be assigned approximately once per quarter. The new CVE web site will provide more details on specific CVE versions. Reference versions will be useful in providing a standard version with which users and/or MITRE could determine how up-to-date a product's mapping is. Guidelines for determining reference versions were presented. A new reference version may be created when there is a content milestone (e.g. exceeding N-hundred entries), it has been approximately 3 months since the last reference version, and it should be relatively up-to-date with respect to recent security problems. One requirement that arose out of these discussions was that for each release of a product, vendors should advertise how up-to-date their mappings are by specifying the most CVE version that was used to make the mapping. It was also agreed that for a product to be considered "up-to-date," it would need to be mapped to a version of CVE that was released within the previous 6 months. A shorter time frame was discussed, but since product development cycles can take several months, it was agreed that 6 months was a reasonable maximum to account for different timing windows. The CVE compatibility requirements document will be updated to reflect the discussions at the Board meeting. The requirements will also be posted to the CVE web site so that consumers may use them to help in their purchase decision making. In addition, MITRE will host a teleconference related to CVE compatibility in early September. Editorial Board Business ------------------------ The next wave of Board recruiting activities was discussed. MITRE will be concentrating on adding software vendors to the Board, and/or establishing liasons with other vendors. As security services have become more prominent, MITRE may recruit representatives from those types of organizations as well. As CVE has gained acceptance in the community, MITRE has begun receiving requests for membership from individuals who are not known to MITRE. In some cases, the individuals have a desire to help the CVE Initiative, but the only apparent way of helping is to build a CVE-compatible product or become a member of the Editorial Board. Participating Board members discussed creating a separate mailing list (a "CVE Working Group") which would provide a forum for non-Board members to discuss CVE issues and contribute to the effort. In turn, such a group could be used for individuals to establish credibility as potential candidates for the Editorial Board in the future. As the size and diversity of the Editorial Board is growing, MITRE will also work on refining the roles and responsibilities for Board members. This in turn will provide better guidance to new, incoming Board members. It would also be useful to determine which Board members are not participating in the Initiative enough, which in turn could make it easier to ask those members to leave and make room for others who would participate more actively. Since Board members contribute in different ways to the Initiative, it may be a challenge to formalize their roles and responsibilities and to determine sufficient levels of activity. The recently announced acquisition of AXENT by Symantec was also briefly discussed, as both organizations have Board members. As agreed to previously, a maximum of 2 Board members can come from the same organization, unless an existing Board member's affiliation changes, in which case the maximum is 3. While these original guidelines were created because individuals would change organizations, it seems reasonable that the same guidelines could apply to mergers and acquisitions. Finally, the date and location of the next face-to-face Editorial Board meeting was discussed. It was agreed that having a Board meeting every six months is appropriate, so the next Board meeting will be held around February 2001. Possible locations included Cisco in Austin, Texas, or Microsoft in Seattle, Washington. Another location would be EWA-Canada in Ottawa, although there was strong agreement that a February meeting in Ottawa would be sub-optimal. Software Vendor Liaisons ------------------------ An approach for establishing software vendor liaisons was discussed. In recent months, it has become apparent that the CVE Initiative would be greatly helped by more involvement from software vendors. However, due to the raw number of software vendors, not all vendors could be part of the Editorial Board. It is an open question as to how to determine which software vendors would still qualify for Board membership; but since OS vendors typically deal with a large number of vulnerabilities in a variety of software, it is likely that OS vendors would be able to contribute at the level of other Editorial Board members. The current thinking is to include "official" POC's for vendors who will serve as liaisons. They would not be a formal part of the Editorial Board, but the individuals and/or their organizations would be recognized in some other fashion. Liaisons would be able to "vote" and comment on security issues related to their own products, with their comments being included in the voting record or any associated deep analysis. The liaison could be consulted before any CVE candidate related to their product is ACCEPTed into the official CVE list. They could make themselves available for consultation with other Board members. Board members were asked about the degree to which they communicate with software vendors on security issues. There was wide variety in the answers, although most Board members have built up relationships with individuals working for a small number of vendors. The experience of CERT/CC's interaction with vendors was briefly discussed. MITRE will follow up with CERT/CC for guidance on how vendor liaisons could be established within the CVE Initiative. The funding status for CVE was also discussed. Steve Christey and Margie Zuk described some of the funding approaches that MITRE will be pursuing for the next fiscal year, e.g. by creating an advisory board or using advertising on the CVE web site. They also discussed the complexities of pursuing a funding model for an open effort like the CVE Initiative. Voting ------ Board members at the face-to-face were given a basic demo of the new voting web site. A version of the voting web site will be made available to the Board within the next few weeks. Participating Board members agreed that it will be sufficient to use SSL with server-side certificates to restrict access to the voting web site. The initial online version of the voting web site may only use HTTP Basic authentication, but it would allow Board members to test it in an operational environment. All votes that are recorded on the voting web site will be extracted and processed internally by MITRE before they are publicized. However, each Board member's vote and comments will be immediately visible to other Board members, which is not feasible with the current email-only voting process. Proposed enhancements to the voting web site included: the ability to have a voter indicate if they have been unable to reproduce a problem, the ability to highlight where there are voting conflicts (e.g. candidates with both ACCEPT and REJECT votes), and the ability to mark a candidate so that it is given "special attention" by other voters, e.g. if a Board member has discovered a possible error or inconsistency. Other voting support could be provided to each Board member in the form of automated email reminders, or separate sections on the voting web site. For example, the member would be able to see: - candidates that the member is still REVIEWING - candidates that the member hasn't voted on yet (with the possibility of prioritizing such candidates if they appear in a backmap for a product owned by that Board member) - candidates that have subsequent comments by other Board members - candidates marked for further investigation or deep analysis - conflicting votes (e.g. candidates with both ACCEPT and REJECT) - breakdown by OS family - ad hoc keyword queries Board members also discussed the CD:VOTE content decision, which specifies rules and guidance for voting. Vendor acknowledgement of security problems was discussed. Vendor acknowledgement is not counted as a vote unless there is some public notice in which the vendor acknowledges the problem, usually in the form of an advisory, post to a mailing list, or description in the software's change log. The software vendor representatives who participated in the Board meeting suggested that while they may post followups in some mailing lists in which they directly or indirectly acknowledge the existence of a problem, their posts should not be regarded as sufficient vendor acknowledegement. However, they agreed that their ACCEPT vote for an issue should be counted as vendor acknowledegement. In addition, the vendor's vote and a separate acknowledgement should not count as 2 votes. (In practice, such cases already count as 1 vote). There was some discussion regarding the proper way to handle voting conflicts. Some Board members suggested that if the conflict cannot be resolved, then a large majority should be required to make a final decision. A separate process will be defined to handle such cases. Content Decisions ----------------- Board members discussed a number of high-level issues related to CVE content decisions. Most participants agreed that a "SPLIT-by-default" operation would be appropriate when there is insufficient information for determining the level of abstraction for 2 closely related security problems. Some members advocated adopting a MERGE approach, since it is often a more appropriate level of abstraction for system administrators. It was agreed that, where possible, the vendor of the vulnerable product should be the final authority in such matters. Such an approach, however, assumes that the vendor is willing and able to respond in a timely fashion. In addition, there is a risk that some vendors may always request a MERGE to minimize the number of CVE entries related to their products. Participating Board members were asked how they handled "content decisions" and consistency for their own vulnerability databases. Content decisions for these databases are either dictated by a single content authority, or by an entire group which makes a decision on a specific vulnerability and uses it as a precedent for future decisions. In most cases, however, the content decisions are not well-documented. Most members had separate technical writers or QA teams that helped to ensure consistency where possible. The decision for the level of abstraction varied across databases, being driven by different needs. For example, some databases would choose an LOA that reflected the needs of system administrators, whereas others might choose an LOA based on patches or differences in risk. The CVE content decisions, as written, attempt to take a top-down approach by describing rules or guidelines at a high level, then applying the rules to specific candidates. This made it difficult for some participants to evaluate a content decision without knowing the details for a specific problem that is affected by the CD. Participants advocated taking an ad hoc, precedent-based approach, by analyzing each candidate, making a decision, documenting the decision, and using it as a precedent for future considerations. This is consistent with approaches that some Board members have taken with respect to their own database maintenance. However, since Board members contribute to the effort at different times, there is a risk that inconsistent decisions will be made based on who happens to be voting or discussing a particular issue at one time. MITRE will modify and document its new approach to content decisions to reflect feedback from the Board. CVE Accuracy and Timeliness --------------------------- Participating Board members discussed the different ways in which CVE could be inaccurate. For example, a CVE entry or candidate may be described at an improper level of abstraction, the security issue may not be real, the security issue is described improperly in the CVE description, or it is a duplicate of existing entries or candidates. Accuracy could be improved by consulting with software vendors liaisons. In some cases, the description for a complex security problem may be inaccurate because important details have been removed from the short CVE style descriptions. Participants agreed that the CVE Initiative should maintain the minimum 2 week review period that is currently set for candidates, and there is insufficient reason to put candidates on a "fast track" even for the most serious vulnerabilities. A short discussion was held regarding the factors that may delay the final decision for candidates. In some cases, a candidate may not receive sufficient ACCEPT votes in the first 2 weeks after it has been proposed. Generally, Board members do not vote on candidates that are more than 2 weeks old, so candidates with insufficient votes may fall behind in the process. Unresolved content decisions have also played a significant role in accepting some candidates; the new approach to less formalized content decisions may reduce such delays. Voting conflicts also contribute to delays. When a Board member casts a vote to REJECT or RECAST a candidate, it is normally given a much lower priority than other candidates. This problem may be resolved when voting conflicts become more visible and easily identified. Consultation with the software vendor may also delay candidates in some cases, as the vendor may need additional time to review the issue. The final factor is related to Steve Christey's multiple roles in the CVE Initiative; other tasks not directly related to CVE content may occasionally prevent Steve from focusing on identifying and addressing some delays for specific candidates. This final concern will be mitigated as the rest of the CVE content team gains experience in submission refinement, CD's, and other aspects of the CVE process. Community Feedback on CVE ------------------------- Steve Christey and Margie Zuk discussed feedback that they often receive on CVE. Users often assume that the data in CVE is reliable. In practice, this is not necessarily the case, since only the number of ACCEPT votes determines whether a candidate is accepted or not. The voting record itself could be summarized and associated with CVE entries to provide a better indicator of reliability. Board members thought that knowing which CVE entries have been actively exploited, combined with a field that indicates whether a problem has been acklnowledged by the vendor or reproduced by a Board member, would be important information for CVE consumers. Such information might be made available as an extension to CVE. Most feedback from the CVE web site is related to usability of the references. Users will often ask for additional information regarding specific sources, or ask for URL's which could provide them with more information. The reference key and reference maps on the new CVE web site will help improve the usability of the references while MITRE works with other organizations to determine if it is reasonable to include URL's with the references for CVE entries. Users often ask about whether CVE includes viruses or Trojan horses. While some of this may be due to confusion regarding the difference between vulnerabilities and viruses, others explicitly say that the multiple naming conventions adopted by anti-virus vendors causes problems for them. However, since Trojan horses and viruses are high cardinality items, CVE probably will not include specific entries for them, except at a high level of abstraction (e.g. CAN-1999-0660 or CAN-1999-0661 for certain types of Trojan horses). Some users want more rapid candidate assignment and review. Candidate assignment will become more rapid as private and out-of-band assignment becomes more prevalent. Since participating Board members have agreed that the minimum 2 week period for candidates should stay in place, the CVE list itself will not achieve the timeliness desired by some of its consumers. Other common requests from users are for additional data formats (e.g. XML), a capability to search by OS (which could be handled by existing online vulnerability databases that are CVE-compatible), and the recording of a risk level. While risk level is outside the scope of CVE itself, some CVE users have told MITRE that it is difficult for them to deal with the inconsistent ways in which products describe the risk of a problem; therefore it may benefit the community as a whole if it adopts a consistent way of describing risk.