|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [CVEPRI] Editorial Board Meeting Summary - March 15-16, 2001
Following is the summary for the CVE Editorial Board meeting. I apologize for taking so long to write this up, but as you will see, there were good reasons for the delay. Thanks to everyone who made this one of the liveliest Board meetings yet. It was also one of the most critical. Many important topics were discussed at the meeting. The most important and timely issues will be moved to the mailing list over the next month or so. Those issues are: the numbering scheme for legacy candidates, the verification/voting requirements for CVE entries, and the definition of Board roles, tasks, and expectations. - Steve **************************************************************** CVE Editorial Board Meeting Summary - March 15-16, 2001 **************************************************************** Members of the CVE Editorial Board met at Cisco in Austin, Texas, USA on March 15 and 16, 2001. The attendees of the face-to-face meeting were: Andy Balinsky (Cisco) Troy Bollinger (IBM) Tim Collins (NFR) John Flowers (Hiverworld) Andre Frech (ISS) Scott Lawler (DOD-CERT) Jim Magdych (NAI) Pascal Meunier (Purdue CERIAS) Ron Nguyen (Ernst & Young) Mike Prosser (Symantec) John Rhodes (DOE-CIAC) Kevin Ziese (Cisco) Sean McAllister (DOD-CERT; not a Board member) Ryan Walters (Symantec; not a Board member) Participating by teleconference were: Larry Oliver (IBM) Craig Ozancin (Symantec) MITRE participants were: David Baker Steve Christey Bob Martin Bill Hill (via teleconference) Margie Zuk (via teleconference) CVE Content Update ------------------ The Board was presented with a progress report on assigning candidate numbers to legacy issues. (See http://cve.mitre.org/board/archives/2000-07/msg00024.html for an explanation of terms). Due to some errors, previous statistics had not been accurate. The number of legacy submissions that need to be processed is 7794. As of the meeting, 7696 of those submissions had been matched against each other. In January, only 1500 had been matched. All matching is expected to be completed by April 2, which will be more than 2 months ahead of the target date of June 15. (A set of submissions from Cisco had been improperly imported, and thus were not matched properly; Cisco provided an updated list of submissions, which will be matched by April 2). Some optimizations were made in the matching process in order to significantly reduce the amount of time spent matching. However, the new approach increases the risk of producing duplicate candidates. Where possible, MITRE will try to mitigate the risk of duplication with the resulting legacy candidates. If a duplicate still arises, it could be caught in the Editorial Board review process. Currently, the matched submissions have produced approximately 4200 submission groups (small groups of submissions from multiple sources, all of which describe the same vulnerability, or closely related vulnerabilities.) Approximately 3500 of those groups have no matching CVE entry or candidate. This means that approximately 3500 more legacy candidates could be created from those groups. The actual number is difficult to predict due to idiosyncracies in the matching process and differences in the level of abstraction of submissions in comparison with CVE content decisions. There is also progress in MITRE's processing of new security issues as they are publicly announced. Over 100 candidates have been reserved for use in the initial public announcement of vulnerabilities. Approximately 80 of those reserved candidates have already been publicized. Some affected software vendors, e.g. Microsoft, are becoming more involved in reserving candidates for vulnerabilities in their own products; other vendors will also be contacted and asked to participate. Approximately 1200 "new" submissions - i.e. submissions for vulnerabilities that were discovered after November 1999 - still need to be processed. However, many of those submissions are for the most recently discovered vulnerabilities. The Board was presented with the individual tasks being undertaken by the CVE content team. Barbara Pease and Jeff Taylor are refining the legacy submissions. Christine Walzer is performing submission matching on new, incoming submissions. Ramsay Key is matching and refining new submissions. Jean-Paul Otin is working on creating candidates for Windows NT-based configuration problems. Numbering Scheme For Legacy Candidates -------------------------------------- Since members of the CVE content team are now performing submission refinement, MITRE will begin to produce legacy legacy candidates on a regular basis. There are several numbering schemes for candidates that could be adopted. The Board discussed several options. However, since each proposed solution had strengths and weaknesses, no decision was made. The current approach for numbering candidates is CAN-YYYY-NNNN, where YYYY is the year in which the candidate number is assigned - *not* the year in which the vulnerability is publicized. (The same applies to CVE entry names, in which the CAN- prefix is converted to CVE-, but the rest of the identifier remains the same). If applied to legacy candidates, the current approach would produce many vulnerabilities that have CAN-2001-NNNN names, but were publicized in 1999 and earlier. Many people may have the perception that the "year" slot in the CVE name is actually related to the year in which the vulnerability is publicized. In addition, there may be an "aesthetic" desire to have the candidate name reflect the year of publication, as a high-level means of managing vulnerability information based on how old it is. Regardless of the public's misconception of the meaning of the year in the CVE name, many of the candidates/entries with 1999-NNNN names were actually announced earlier than 1999. For the most part, CVE items with 2000-NNNN names were publicized in 2000, but some 2000-NNNN names are for older issues. Similarly, some problems discovered in November and December 2000 have 2001-NNNN names. So, many of the current CVE/CAN names are already inconsistent with respect to the year of publication for the associated vulnerabilities. However, depending on the number of new vulnerabilities discovered this year, and the number of legacy candidates that MITRE produces, it is possible that more than 10,000 candidate names will need to be assigned this year. The name space only supports up to 9999 different names per yer. (This is being referred to as "the CAN-10K problem"). There are ways of extending the name space if necessary; for example, by moving to a hexadecimal numbering scheme instead of decimal, 65536 different vulnerabilities could be assigned per year without changing the number of characters in the name. However, it is not known whether such a change would adversely impact how some CVE-compatible products may store the CVE names. There are several factors that need to be considered when selecting a naming scheme for legacy candidates: 1) It was suggested that to help users manage CVE based on date of publication, that a separate field could be added which lists such a date. However, this information is currently in other databases, and thus increases the risk of CVE's competition with those databases. In addition, the date of publication would rarely help someone in mapping a specific vulnerability to a CVE name, although it is occasionally useful in discriminating between extremely similar vulnerabilities in the same product. The references and description, on the other hand, are essential for looking up the CVE name for a problem. 2) If a naming scheme is adopted which encodes the year of publication in the name, then all the entries or candidates that currently exist should *NOT* be renamed just to make things consistent, since there is such a large number of CAN/CVE-1999-NNNN items that were not discovered in 1999. The maintenance costs would be high for CVE users and compatible vendors. Thus, even if the Board adopts a "publication-based" encoding, it will not apply to all CVE items. 3) If a publication-based encoding is not used, then users will need to be able to distinguish between new candidates and legacy candidates. This information could be provided in reports that are accessible on the CVE web site. Following are the different approaches that were discussed by the Board. 1) Assignment-based encoding: continue to use the current approach, i.e. assign CAN-2001-NNNN (or CVE-2001-NNNN) to the issue, since 2001 is the year in which the candidate is assigned. Pro: emphasizes that the encoding of the year in the CVE name is not related to the year of announcement. Simplest to implement. Con: increases the possibility of misuse by consumers. For example, consumers might focus on the last 200 CAN-2001-NNNN candidates, mistakenly believing that they are the most recent issues that have been discovered. Con: susceptible to the CAN-10K problem. 2) Publication-based encoding: assign YYYY-NNNN, where YYYY is the year in which the issue was first publicized. Pro: more likely to address common public misconceptions. Pro: least susceptible to the CAN-10K problem. Pro: will be accurate for all issues that are publicized in 2002 and later. Con: 1999-NNNN, and portions of 2000-NNNN and 2001-NNNN, will not be consistent with the approach. Con: some complications if a vulnerability is publicized one year, a candidate is created, and then it becomes clear that the problem was actually publicized in earlier years. 3) Hybrid encoding. If the problem was published in 1999 or earlier, use 1999-NNNN; otherwise, use the year of publication. Pro: emphasizes that the encoding of the year in the CVE name is not related to the year of publication, for any issues that were publicized in 1999 or earlier. Pro: For 2002 and later years - and all but the first 150 candidates of 2001 - the year of publication will be encoded in the CVE name. Con: For 2000 and 2001, some candidate names will not include the year of publication. Con: most susceptible to the CAN-10K problem, because there may be more than 10,000 vulnerabilities from 1999 and earlier that ultimately require names. To help end users better manage or discriminate between new and legacy issues, and highlight the differences for purposes of user education, it was suggested that legacy candidates be assigned names with the highest sequence numbers available. For example, one could start at CAN-2001-9999, CAN-2001-9998, etc. for legacy candidates that are created in 2001. An alternate scheme was proposed in which legacy issues could be assigned CAN-2001-5000 and advanced upward. However, it is possible that these significant gaps could cause confusion. In addition, some people may be using the highest-numbered candidate for other purposes, which could have unexpected consequences. For example, it was noted that some people mirror individual CVE entries and candidates on the CVE web site by requesting information up to 100 "sequence numbers" above the most recent candidate; such mirrors might immediately attempt to download 10,000 candidates for 2001, instead of the current number of about 250. Regardless of which approach is adopted, users will need to be educated about it. It is likely that additional information will be needed on the CVE site; in addition, CVE-compatible vendors will need to address user misconceptions. Also, MITRE will not be able to start proposing legacy candidates until the numbering scheme is finalized. MITRE's CVE Content Goals ------------------------- MITRE's CVE content goals were presented. The last CVE version was released in January, but there are sufficient votes to promote at least 100 more candidates to official CVE entries. A new CVE version will be released within a month. Some CVE entries will be deprecated due to duplication. Other entries will be modified, e.g. to add new references. Some candidates - mostly duplicates - will be rejected. To address the needs of people who would like candidates to come out more rapidly for new issues, MITRE has set a goal to create and propose candidates for new security issues every 2 weeks. Candidates for legacy issues will be created and proposed on a regular basis. Other longer-term goals remain. By July 1, all submissions for issues discovered in 1999 should be refined into candidates. By December 2001, all legacy submissions should be refined into legacy candidates. Threatened Lawsuit Regarding CVE Content ---------------------------------------- A software vendor has threatened to sue MITRE based on some CVE content. A CVE candidate describes a reported vulnerability (denial of service) in the vendor's product. The vendor says that the reported problem is not in the product, but rather in the improper use of the product by system administrators, who do not use OS-provided resource limitations to reduce the effects of a DoS attack. The vendor says that many products who rely on OS-provided resource limitations are also affected. There are technical arguments on both sides regarding whether the reported vulnerability is in the software or in the operating system; this disagreement is reflected in the long discussions on the vendor's mailing list regarding the reported problem. There also was disagreement by participating Board members during the meeting. The software vendor appears to be considering lawsuits against owners of other databases that list the reported problem in the vendor's product. In addition, it appears that several security tools list the reported problem in their products; thus, the software vendor's lawsuit might extend to other organizations. MITRE's lawyers are preparing a response. Specific details (i.e. the vendor and claimed vulnerability) were provided to the Board members who participated in the meeting. Other members may obtain details from Steve Christey. Ultimately, other affected software vendors may attempt similar lawsuits. There was some discussion of the potential chill that such lawsuits might pose for vulnerability research and reporting. Verification Requirements for CVE Candidates -------------------------------------------- In the past 9 months, the Board has had several discussions regarding how much verification of a candidate must be performed before the candidate can be promoted to an official CVE entry. (See http://cve.mitre.org/board/archives/2000-06/msg00054.html as well as the "Editorial Board Voting Status and Issues" section in http://cve.mitre.org/board/archives/2001-01/msg00010.html for some details.) Ultimately, the guidelines for voting can not be completed until the verification criteria for official CVE entries is determined. According to one point of view held by some Board members, the official CVE list should act solely as a "dictionary," i.e. a set of agreed-upon names that are used to describe reported security problems, independent of whether those problems are real or not. External databases or vendors could clarify whether the reported issues are real. In some cases, it would be useful to have a CVE name for an issue, even if it turns out to be false; for example, an issue might be publicized in one forum, but refuted in another. If the issue does not have a CVE name, but it has been deleted from various databases, then some consumers might still think that the problem is real. It was noted that CVE candidates could be used to record all reported vulnerabilities, and the voting record could include a refutation if the initial report is discovered to be wrong. Other Board members believe that official CVE list should be well-reviewed, and there should be some level of verification that ensures that the issues being identified are real. They argued that while many databases or products may have a mixture of "real," "potential," and "incorrect" issues in them, CVE should strive to be more correct. It was also argued that the candidates, by their nature, already imply a level of uncertainty, and there would be little difference between entries and candidates otherwise (with the exception of duplication and level of abstraction problems). Also, there is already a public perception that because of the review process, CVE entries have been sufficiently validated. That is not necessarily the case currently; in addition, the small number of votes increases the risk that an incorrectly reported issue will become an official CVE entry. A more stringent requirement for verification of CVE entries could result in a large number of "permanent candidates" that are never refuted or rejected, but never gain enough ACCEPT votes. There are already some candidates like this. The original idea of candidates was that they would be temporary numbers that formed the "to-do" list for Editorial Board members to review. Permanent candidates, if they arose, would need to be managed differently. It was proposed that if less stringent requirements are adopted, then the Board could publicize the fact that there is still a community-wide need for strong verification of vulnerabilities, but CVE will not be able to fill that need. Current Voting Activities ------------------------- In the January teleconference, MITRE had noted that the number of voters, and the total number of votes taking place, had dropped sharply in recent months. Some of the decline was related to the more stringent guidance in Fall 2000 with respect to the level of verification that is necessary before Board members should vote to accept a candidate. There has not been a noticeable increase in voting since January. The Board has almost 40 members, and it is difficult to get 2 or 3 votes on a timely basis. This delay is noticeable to the public. Only 4 members vote regularly; another 15 members vote on a periodic basis, usually once every 4 to 6 months. This is insufficient for current needs, and will become even worse when legacy candidates are added. Since voting is the most critical task for Board members, the lack of voting needs to be addressed. Unless current Board members can contribute more often, MITRE will need to keep adding Board members - or increase minimum expectations for existing members - to ensure that there is sufficient review of candidates in the future. Board members did not object to the idea of expanding the Board further; in earlier meetings, some members had expressed concerns that the Board could get too big. It was proposed that voting records could be better publicized, so that CVE end users could know which Board members are voting actively. Voting activity can be inferred from current public information, but it is not easily accessible. There were no objections to this proposal. MITRE will consider how (and when) to most effectively publicize this information, once the other significant voting issues are resolved. Since voting is affected by the verification requirements for CVE entries, voting activities will be revisited once that issue has been addressed. Proposed Voting Guidelines -------------------------- The following guidelines for voting was proposed and discussed. A voter could only ACCEPT or MODIFY a candidate if: (1) The vendor has acknowledged the problem. (2) The voter, or the voter's organization, has been able to replicate the problem. (3) Someone that the voter trusts has verified the problem. This could include the original researcher, if the researcher is trusted by the Board member. (4) There is independent confirmation of the issue, i.e. 2 different sources claim to have reproduced the problem (such as an initial Bugtraq post and multiple follow-ups). Participating Board members agreed that the first two requirements were acceptable. It was noted that "vendor acknowledgement" needed to be clear; for example, it might not be sufficient acknowledgement if a researcher says that there's a patch, unless that patch is tested, or the vendor says that the patch fixes the problem being reviewed. Some concerns were raised with respect to the trusted verification issue. For example, if the voting Board members all trusted the same person or organization, then there would be a greater likelihood of an incorrectly reported candidate being promoted to an official entry. Some members said that this would not be a problem, because only researchers who have established a strong reputation would be trusted by many members. An incorrect report could also reduce the overall trust in future reports by the researcher. There may be other cases in which a Board member trusts "too many" people. Also, only the trust of the members who vote will be taken into account; thus the ultimate contents of CVE could vary, depending on who is voting. Previously, it had been proposed that Board members could publicize who they trusted. This could address some of the concerns outlined above; however, members might not be willing or able to provide such information. In general, however, the Board agreed that "third party trust" should be sufficient reason to accept a candidate. This approach utilizes the resources of others in the security community who are not on the Editorial Board. Due to time limitations, the Board did not discuss whether independent confirmation should be included in the guidelines, or how it might be measured. Until the voting question is resolved, MITRE will only accept candidates that satisfy the first 3 voting guidelines as described above, i.e. vendor acknowledgement, verification by a Board member, or verification by a party that the Board member trusts. The voting guidelines, once finalized, will be publicized in order to clear up any misconceptions that CVE users may have. Other Voting Issues ------------------- There was a concern that by voting to accept a candidate, a Board member might be held liable if their vote is interpreted as stating that they believe the problem is real. This issue could be exacerbated by situations like the potential lawsuit related to CVE content, as described in a previous section of this summary. Limitations of the current set of votes (Accept, Modify, No Opinion, Reject, Recast, Reviewing) were also discussed. It was proposed that an additional "UNCERTAIN" vote could be used to state that a voter believes that the candidate description and references accurately reflect all available information, but the voter does not have sufficient knowledge about whether the reported problem is real. Board members disagreed with this proposal, since it implied a level of confidence, and it was already decided that confidence levels should not be included in CVE. A different situation arose in which a candidate described a vulnerability that was refuted by the vendor; however, in the past, the researcher had discovered other vulnerabilities that had been fixed by vendors. The voter did not trust the researcher and believed that since the vendor disagreed with the issue, there should be more confidence before accepting the candidate. However, none of the possible votes adequately described the voter's intent. Formalizing Editorial Board Tasks and Roles ------------------------------------------- For various reasons to be described below, MITRE is formalizing the roles, tasks, and expectations for current and future Board members. The Board discussed several related issues. Over time, the Editorial Board has evolved. The Board started out as an informal organization. An interview and review process was put in place in late 1999. Starting in late 2000, the expectations for new members were more clearly defined and publicized. Most recruitment activities for Board members were performed by MITRE. In rare cases, a prospective member was nominated by an existing Board member, or the prospective member established initial contact. However, the number and type of participants in the Editorial Board has changed over the years. In addition, outsider requests for Board membership has increased significantly. More of the initial inquiries come from marketing personnel instead of technical workers. More prospective members are not known to MITRE, or they are not qualified to participate. Editorial Board membership is sometimes mentioned in marketing materials or personal biographies. While these conditions reflect a growing acceptance and prominence of CVE, they also indicate a need to ensure that membership on the Editorial Board is not used inappropriately. Without a clear description of the tasks that are performed by the Board, and without a more formal review mechanism, it is becoming more difficult for MITRE to manage the incoming requests, to clearly identify expectations of prospective members, and to fairly assess the prospective member. It also makes it difficult to assess the level of participation of current membets. Some current members have not been able to contribute at the level which was agreed to when they first joined the Board. Other members who have been on the Board since fall 1999 did not join through the current process; as such, there was never a formal discussion or recruitment period which would describe the tasks and expectations, which evolved as CVE has changed. In an attempt to clearly identify how current Board members participate in CVE activities, MITRE has developed a spreadsheet which outlines the level of contribution which each Board member has made, in a number of different tasks. The purpose of the spreadsheet is to clarify how each Board member contributes, and how often; to be used as a basis of one-on-one discussion with each member on their own expectations for how they participate in Board activities; and to clarify what minimum expectations could be. In the next few weeks, each Board member will be contacted, and their roles and tasks will be discussed. In turn, this will help all Board members to collectively decide on future expectations for Board members, and to formalize such expectations. Ultimately, each member's tasks, roles, and expectations will be publicized to the rest of the Board, and possibly the public as a whole. Board Member Roles ------------------ The following roles were discussed by the Editorial Board. It is believed that most members would have a single, primary role on the Board. By identifying the role of each member, the associated tasks and expectations could be clarified. Some MITRE-specific roles were identified. The CVE Editor is responsible for CVE content. The Chair is responsible for Editorial Board structure, recruitment, and activities. Both roles are currently performed by Steve Christey. Technical contributors include task leaders (i.e. Margie Zuk, Pete Tasker, Bob Martin, Bill Hill, and Dave Baker), members of the content team (Barbara Pease, Ramsay Key, Chris Walzer, Jean-Paul Otin, Dave Goldberg, and Jeff Taylor), and other supporting personnel. Four roles for Editorial Board members were identified. Technical members participate in the design, review, and maintenance of CVE and/or its usage. Expectations include consistent participation in one or more technical tasks, such as voting, ad hoc consultation, or definition of CVE processes. Liaisons represent a significant constituency, related to or affected by CVE, in an area which does not necessarily have technical representation on the Board. This role may include software vendors. Liaisons would need to be visible and active in their own community. They bring a diverse perspective, a broader awareness, and community-specific needs for CVE to the Editorial Board. The primary expectation for liaisons would be consistent participation in Board activities that directly affect the liaison's community. Advocates actively support or promote CVE in a highly visible fashion. This role would be reserved for respected leaders in the security community. They help bring credibility to the CVE Initiative, and they may give CVE a "wider reach" outside of the community. They might participate in strategic planning for CVE, but they wouldn't necessarily participate at a technical level. A current Board member was proposed as an example Advocate. It was suggested that the term "Ambassador" could also be used to describe this role. Editorial Board members agreed that the Advocate role is important for the CVE Initiative, and it is appropriate to include advocates on the Board. There was some discussion regarding how a member might be assigned an advocate role, as it may be difficult to outline specific requirements. Advocates could be appointed with a vote by a significant percentage of Board members, but this approach was not discussed in detail. The fourth role is Emeritus, which is an individual who was formerly active and influential in the CVE Initiative, and maintains an "honorary" position as a result. The expectations for the member are minimal. One concern was raised that the Board should only include active members, and as such, it might not be appropriate to include an Emeritus. However, in some cases, an Emeritus may continue to participate on an ad hoc basis. While this role was not discussed extensively, Board members agreed that it might be appropriate for MITRE to choose which members can retain Emeritus status. Editorial Board Member Tasks ---------------------------- The following tasks were discussed by the Editorial Board. Members agreed that their CVE-related activities were covered by one or more of these tasks. 1) Voting on candidates. Some members vote regularly; others vote on an ad hoc basis, e.g. when there is an effort to reach a specific content goal. 2) Meetings. Some members participate actively in face-to-face meetings and teleconferences. 3) Ad hoc/offline consultation. Sometimes, members are consulted "behind the scenes." Their contributions, while valuable, may not be visible to the public or even to other Board members. 4) CVE process definition. Activities may include discussions related to content decisions, the review and voting process, Board structure, etc. 5) Content provider. Several Board members have provided their vulnerability databases for conversion into candidates, which ensures that CVE content is complete. Note that this task is also performed by some organizations that are not on the Editorial Board. 6) IDS/CIEL. In some cases, CVE does not identify events that are captured by intrusion detection systems. Some Board members will be participating in the review and development of the Common Intrusion Event List (CIEL), which is currently being drafted by MITRE. 7) Candidate Reservation. Some members use candidates in their security advisories, or they are prospective Candidate Numbering Authorities (CNA's). Note that this task is also performed by some organizations that are not on the Editorial Board. 8) CVE compatibility. Some members participate in the definition of requirements or the evaluation process for CVE compatible products. Note that this task is also performed by some organizations that are not on the Editorial Board. 9) Non-CVE activities. Occasionally, an activity that is not directly related to CVE is undertaken by the Editorial Board. The most prominent example is the CyberCrime Treaty Statement, which was drafted in May and June 2000. 10) Liaison. It is expected that the tasks for a liaison will be ad hoc. 11) CVE promotion. Some members are active, visible promoters of CVE. 12) Education about CVE. Since the amount of participation by each Board member varies, as well as the specific tasks that the member performs, it is difficult to determine what the minimum level of participation should be for each member. There was little discussion on this topic during the meeting. However, it will be revisited in the near future as Board members evaluate their own roles, tasks, and expectations. Organizations with Multiple Members ----------------------------------- Some organizations have 2 members on the Editorial Board. In some cases, one member is active, but the other is not. It was proposed that organizations with multiple members should have a level of activity which exceeds the minimum expectations for one member. However, meeting participants advocated that the requirement should be made more stringent, and each Board member should meet the minimum requirements for participation. This requirement was accepted by all participating members who were in multi-member organizations. It was agreed that there should be allowances for extenuating circumstances; for example, one Board member was recently injured in an accident. New Member Recruitment Process ------------------------------ The Board discussed the process by which prospective members could be recruited, evaluated, and added to the Editorial Board. MITRE's current process was described as follows. A prospect is first identified in one of three ways. Some prospects ask MITRE about membership. Other prospects are actively recruited by MITRE, often to fill a gap in Board representation. Other prospects are nominated by current Editorial Board members. Once identified, the prospect is given a short description of Editorial Board tasks and the expected amount of time that needs to be committed. An interview then takes place between MITRE and the prospect. The interview allows MITRE to determine if the prospect has the appropriate technical knowledge to contribute to CVE, and to identify the specific roles and tasks that the prospect will undertake. The prospect can obtain more information about Board activities and expectations. During any of these phases, MITRE or the prospect may decide that membership is not appropriate. If MITRE decides to add the prospect, the prospect provides a short professional biography. The prospect is then announced to the Editorial Board as a new member. The announcement describes how the new member will be able to contribute to CVE, lists the member's bio, and identifies the specific tasks that the member is expected to perform. The prospect is then sent an introductory documentation package that describes recent news, voting, technical rationales for CVE, etc. While Board members were satisfied with the types of people that MITRE has added to the Board, there was some concern that Editorial Board members are not included in the evaluation process. As more and more people request membership, there is an increased risk that a MITRE-only recruitment process might add a Board member who is inappropriate. Some members advocated an approach in which MITRE "screens" prospective members, then consults the Board for feedback on those prospects who pass the screening. During the screening, MITRE should ensure that prospects have a clear understanding of expectations; while MITRE currently does this, it will be easier to describe when the roles and tasks are well-defined. The Editorial Board could provide feedback via a discussion period and a formal vote. It was proposed that a minimum 50% of members could be required to accept a prospect, but given the size of the Board, and the lack of consistent participation by most members, this number is probably too high. A minimum 5 votes might be more reasonable, and it still represents a little more than 10% of all members. There would need to be a minimum review period to give members enough time to review the prospect, perhaps a month. It was agreed that a private mailing list would be needed for discussion and voting on prospective members, if such an approach is adopted. It was proposed that prospects should be visible or known to the Editorial Board. However, some current Board members were not well-known to other members. In addition, some members act as liaisons for other groups, but may not be well-known if they are not directly involved in the security industry. Some lesser-known Board members have made significant contributions. Many members agreed that the prospect could be required to submit a "resume" that outlines specific qualifications for Board membership, in light of the tasks that the prospect is expected to perform. This would allow all Board members to evaluate the prospect, even if they do not know the person. Guidelines for a minimum amount of experience were discussed. There was general agreement that between 3 and 5 years' minimum experience in information security should be required, unless the individual has made a recognizable contribution to the information security community. Some concern was raised that a more formal voting process could make the Editorial Board a more exclusionary organization. However, MITRE's current recruitment and screening process could reduce this risk. There was also some side discussion regarding the diversity of the individual members of Board, especially with respect to the lack of women; the small percentage of women in information security may be a factor. There is currently one woman on the Board, but she is expected to leave soon. MITRE's management, content, and support teams include women, but they are not on the Board. Some potential members were identified, and they will be evaluated and recruited through the established process. Once the tasks, roles, and expectations have been more clearly defined, the Board will be able decide on the new approach to recruitment and evaluation of new Board members. Trial Membership ---------------- MITRE proposed the possibility of establishing a "trial membership," or review period, for new members. This could be used to ensure that new Board members would be able to participate as actively as expected. In some cases, new members would join the Board, but they would not be able contribute at the level that was expected. Trial membership might be useful to ensure that the new member is active, at least during the review period; however, it does not necessarily guarantee the level of activity after the trial period. Trial membership could also limit the number of prospective members who join the Board solely for marketing or promotional purposes. Board members disagreed with this proposal. Instead, they suggested that the vetting process should be improved to minimize the risk of "under-performing" new members. As the roles, tasks, and expectations are formalized, it will also be easier to request that some Board members resign if they are not able to participate at the expected level. Other Board Business -------------------- At several points during the meeting, it was noted that a non-public mailing list could be useful for Board members to discuss certain issues that would be inappropriate for the normal Editorial Board mailing list, which is publicly archived. While the Board has committed to making its deliberations public, there has always been a consideration that there might be a need to support private discussions. Members will need to be careful that the private list is not used for any discussions which should be publicly archived. The frequency of Board teleconferences was also discussed. Currently, teleconferences are held every 2 to 3 months. Some members suggested creating a single time slot for weekly discussions. If members had a planned time slot, it could allow them to participate more regularly, and receive more timely updates. A staggered schedule was also proposed, since a single time slot could prevent some members from participating at all, if they had other regular meetings that occurred at the same time. However, members believed that a single time would be more easily manageable. The topics for the meeting could be ad hoc, and there would not need to be a formal agenda or report afterward. If the tasks and roles for Board membership begin to require more involvement, more frequent teleconferences could help ensure that everyone is up-to-date. Since the face-to-face meetings are consistently more productive than the teleconferences (probably due to the personal dynamics involved in face-to-face interactions), MITRE is considering increasing the frequency of face-to-face meetings to every 4 months, instead of every 6 months. There was no discussion of the date and location for the next face-to-face meeting. Future CVE Activities --------------------- Because the level of verification required for voting on candidates has not been decided yet, it was difficult to set specific CVE content goals. The two main goals that were scheduled for discussion were to reach 1600 entries by June 1, and to reach 2000 entries by December 1. Many CVE goals in the past have been quantitative, focused on the number of entries and/or candidates. The Board identified some qualitative goals, including: - making significant progress in the CIEL effort - making CVE content more "real time" by creating candidates more quickly and updating CVE versions more often - increasing international reach by translating CVE into other languages and adding more international Board members - establishing working relationships with the various Information Sharing and Analysis Centers (ISAC's) - adding other types of members to the Board, such as end users, auditing organizations, and security services. Other future efforts were discussed. Some upcoming conference presentations were described; most of them will be for a different audience than previous presentations. Also, MITRE plans to collect case studies in which CVE users discuss how they have integrated CVE into their work. Board members were asked to contribute case studies. Senior Advisory Council Update ------------------------------ The Board was updated on the CVE Senior Advisory Council, which is composed of senior executives in U.S. government agencies, many of which provide funding for CVE. MITRE has been developing the Advisory Council for almost a year. A list of current council members was presented to attendees during the Editorial Board meeting. The Council held its first meeting on January 25, 2001, in Washington, DC. Since then, the charter has been finalized and sent to the Editorial Board mailing list. The Council will hold face-to-face meetings on a quarterly basis. Some meetings might include presentations from Editorial Board members. A web page on the Advisory Council will be added to the CVE web site. There were some questions about the lack of commercial involvement in the Council. MITRE had attempted to find commercial supporters in the early stages. However, it was unable to find the appropriate executives who might be interested in participating. Editorial Board members also suggested involving the ISAC's in the Advisory Council. The Council has decided to limit membership to government, but it recognizes that commercial involvement is important. However, there may be cases in which a commercial organization's membership on the Editorial Board is not appropriate to the specific tasks. MITRE may create a separate organization with an industry focus on CVE. The Editorial Board was also briefed on CVE's funding status. With respect to CVE itself, one of the Council's main roles will be in providing strategic guidance for the direction of CVE. For example, the Council has encouraged MITRE to involve the ISAC's more closely in CVE, conduct outreach to large organizations outside of the security industry, define qualitative goals, and concentrate more on CIEL. Board members expressed an interest in receiving regular updates regarding the status of the Advisory Council. Issues With CVE Content Decisions --------------------------------- MITRE presented its rationales for modifying some of the most common and complex content decisions (CD's) in CVE. (Content decisions are criteria that determine which items should be included in the CVE list, and the appropriate level of abstraction to use.) Some CD's are difficult to describe and formalize. In some cases, CD's can not be applied consistently due to the lack of available information, source code, and/or individual expertise. Some members have suggested taking an ad hoc approach to each candidate. However, now that additional members of MITRE's content team are producing candidates, and more people are reserving candidates for use in initial public announcements, there is a growing need to make CD's easy to describe, while defining them in a way that allows them to be applied consistently to each CVE candidate. For example, CD:SF-LOC ("software flaws/different lines of code") suggests how many candidates should be created when there may be multiple failure points (bugs) in a single product version. When applying the SF-LOC content decision, an analyst might encounter cases in which it is difficult to identify how many failure points exist. For example, the vulnerable product might not have source code which could tell the analyst if several different attack vectors ultimately reach the same failure point. As a result, the CD would be inconsistently applied to different vulnerabilities, depending on the amount of information available. In addition, later discoveries could force a change in the level of abstraction, which would require renumbering candidates or entries, increasing maintenance costs. In previous discussions, the Editorial Board had suggested taking a simple "split-by-default" approach in cases of uncertainty: i.e., if there is insufficient information to be sure that 2 issues are the same, then create separate candidates. Since MITRE adopted this approach, it produced a larger number of candidates than before, moved CVE to a lower level of abstraction than that used by most databases and tools, and made the effects of incomplete information even more severe. A more detailed description of these issues was posted to the Editorial Board mailing list on March 13. It is archived at http://cve.mitre.org/board/archives/2001-03/threads.html with the subject: [CD] Reconsidering "split-by-default" in content decisions To address the problems described above, MITRE has since adopted a middle-of-the road approach which is less dependent on the amount of information that is available at the time of analysis. The approach is: (a) separate reported issues by the type of the vulnerability; (b) if there appear to be multiple failure points of the same type - e.g. buffer overflow - then they should be combined into the same candidate; (c) write the CVE description, and use CVE's "dot notation," to indicate the possibility of multiple vulnerabilities of the same type; (d) if one vulnerability appears in a different product version than another, then they should be separated. Participants agreed that this approach, while not perfect, was satisfactory. Some members were concerned that the level of abstraction as specified by CVE content decisions is too high for some uses, e.g. academic study. In turn, this reduces CVE's utility to such users. Some people wanted CVE to be more precise (i.e. use a lower level of abstraction), as there are no other data sources that use that level. It is believed that CVE's "dot notation" could satisfy the needs of those users while maintaining the higher level of abstraction. However, there may be several ways in which a CVE item could be broken down into smaller parts, e.g. by individual failure points, or by the different scripts that are available for exploiting the vulnerability. Dot notation was originally accepted by the Editorial Board under the assumption that only one type of abstraction would be needed below CVE. The concept might be extended to support multiple types of abstraction. However, it will be important to ensure that each abstraction type has only one official notation. There are other cases in which the level of abstraction used by CVE is too low. For example, a single patch could fix multiple vulnerabilities. Many system administrators might prefer that only one CVE entry be used to cover all the possible issues. This problem is not being addressed at this time. For each candidate, MITRE records the content decisions that affect that candidate. This information is accessible to Board members, but it is not easily obtained by the public (although it is included in candidate voting ballots, which are recorded in the mailing list archives). MITRE intends to make this information more easily accessible to those people who wish to understand which candidates were affected by such approaches to content decisions. The data will probably be provided as a separate extension, like reference maps. CVE Compatibility ----------------- MITRE provided the Board with an update on its evolving process for establishing CVE compatibility and providing the appropriate branding, and recent issues that have come to light. Bob Martin of MITRE is the task leader for CVE compatibility. Some vendors have unquired about CVE compatibility for products whose first versions were still in beta or alpha development. To reduce the risk of including CVE compatibility declarations for "vaporware," MITRE has decided to only post declarations for products that have had at least one full public release. (There is no such restriction for products in beta development for which previous versions have already been released.) It was suggested that vendors with other CVE-compatible products could be exempt from this restriction when they are ready to release a new product line. An additional requirement will be added in which the vendor's product documentation must include a description of how the product uses CVE names. CVE-related documentation will be useful for MITRE to perform its evaluation. It will also help end users, because each product will implement CVE compatibility in a different manner. Board members did not object to this additional requirement. A new category of CVE-compatible "product" is also emerging - security services. Such services often use tools from multiple vendors, and they provide reports to their customers. The high-level requirements (searchibility, output, and mapping accuracy) still apply to services. However, the implementation of "searchability" is not necessarily clear for services. The current thinking is that a service is CVE-searchable if either (a) it can provide the customer with a list of CVE names for vulnerabilities that are identified by the service, or (b) if a user provides a list of CVE names to the service vendor, the vendor can list which of those CVE names are identified by the service. As the number of categories has grown - tools, databases, web sites, and now services - the current requirements document is getting larger and less easy to manage. The requirements document will be modified accordingly, possibly by creating separate implementation documents for each type of product. There was a question regarding whether compatibility applied to a specific product and CVE version. MITRE's evaluation of a specific product will occur relative to a particular version, but as long as the vendor follows the appropriate requirements for remaining up-to-date and accurate with the product's mappings to CVE, then the product remains compatible. Thus, compatibility reflects the functional implementation and the process of maintaining accuracy, instead of being associated with a specific version. However, there are still some issues with respect to how CVE versions should be properly handled and advertised within the product itself. In cases of abuse, the requirements allow MITRE to revoke CVE compatibility. It was suggested that MITRE could provide an external "complaint" mechanism for handling user's problems related to a product's CVE compatibility; however, most problems should be handled by the vendor's technical support capability. MITRE is also considering performing a periodic renewal of compatibility for a product, possibly at the vendor's request. Process for CVE compatibility evaluation and branding ----------------------------------------------------- MITRE's current approach for establishing compatibility involves two stages. Stage 1 includes: - the vendor's declaration of intent for compatibility - an endorsement quote from the vendor (if desired) - review of the declaration by a knowledgeable CVE team member - publication of the declaration on the CVE web site Stage 1 is currently implemented for all products. However, it does not result in an official evaluation by MITRE that a product is CVE-compatible. The second stage, which MITRE is now developing, identifies this process. Stage 2 includes: - MITRE provides the vendor with a questionnaire in which the vendor provides details on how the requirements have been implemented in the product. - The vendor provides MITRE with a written statement of compatibility, i.e. the completed questionnaire. - The vendor provides MITRE with the CVE-related user documentation for the product. - The vendor provides MITRE with the mapping from product-specific vulnerability items to CVE names. - MITRE verifies the accuracy of the mapping, possibly by analyzing a random sample. - MITRE evaluates the vendor's statement of compatibility to ensure that it addresses the requirements by examining user documentation or screen shots, and/or running the tool itself - If the mapping is accurate, and the statement of compatibility and other materials satisfy the requirements, then MITRE establishes a concurrence with the statement. - MITRE provides the vendor with access to a CVE-compatible logo and other CVE promotional materials, possibly through a restricted web site. - The vendor's statement, and MITRE's concurrence, is posted on the public CVE web site. If the vendor wishes, MITRE will be able to sign a non-disclosure agreement during the second stage, until the final statement is published. The process is designed to minimize the expense for vendors and MITRE in evaluating compatibility. MITRE wants to avoid an expensive evaluation process that makes it too expensive for freeware or smaller software vendors to obtain compatibility. The questionnaire and statement of compatibility are designed so that the vendor properly understands and implements the requirements. The publication of the vendor's statement on the CVE web site allows end users to compare how different products satisfy the requirements; the market could then decide which specific implementations are best. There were no objections to publicizing the statements of compatibility. The Editorial Board agreed with this high-level approach. MITRE will continue to implement the details of the process. Candidate Reservation and Candidate Numbering Authorities (CNA's) ----------------------------------------------------------------- MITRE discussed the current process for candidate reservation, i.e. the means by which vulnerability researchers, vendors, or third parties can obtain CVE candidate numbers for inclusion in public announcements of vulnerabilities. Candidate reservation begins with a requester, i.e. the researcher, vendor, or third party. The requester, if new, will typically inquire about the process; MITRE provides a description and rationale for the process. MITRE also asks for details of the vulnerability, in order to apply content decisions to determine how many candidate numbers must be assigned. MITRE does not require such details, however; there may be reasons why the requester is unwilling or unable to provide such details, e.g. because of an NDA with the affected vendor. If the requester does not provide any details, MITRE still provides a candidate (this is referred to as blind candidate reservation). Blind reservation has some benefits because the public has immediate access to the candidate number when the issue is first publicized. Also, there is a reduced risk of accidental disclosure, since MITRE does not have the information. However, there is an increased risk that the requester will use an incorrect number of candidates, or use a candidate for a rediscovered issue that already has a CVE name. Once all available details are provided, MITRE checks to see if the problem is new, applies the CVE content decisions, and determines the number of candidates necessary. This may require further consultation with the requester. MITRE then sends the candidates to the requester, along with descriptive text that could be included in the resulting advisory. Related communications, along with details of the vulnerability, are then either encrypted or destroyed in order to reduce the risk of accidental information exposure. MITRE then publishes the candidates on the CVE web site. The description indicates that the candidate was reserved, but it does not contain any details about the problem (since the issue hasn't been published yet). Sometime later, the requester publicizes the vulnerability (e.g. in a security advisory or in a mailing list post). The requester includes the candidate number in the publication and notifies MITRE. MITRE then updates the CVE web site with the specific vulnerability details. Since there is a delay between the publication of the vulnerability and the update of the CVE web site, there is an increased reliance on the requester to notify MITRE of publication; however, this does not always happen in practice. If the candidate was reserved blindly, it may take longer to update it, since the vulnerability analysis must be performed after publication. The candidate is eventually proposed to the Editorial Board for review and commentary, along with other candidates that are created through the submission stage as described earlier in this document. If the candidate becomes an official entry, then MITRE notifies the requester, who updates the advisory with the new CVE number, if possible. (This is not feasible in the case of mailing list archives). Blind Candidate Reservation Discussions --------------------------------------- The Editorial Board provided some feedback on the current process, especially the role of blind candidate reservation. Some members expressed concerns that blind candidate reservation could cause too many problems and weaken the credibility of CVE, especially if the candidates are at the wrong level of abstraction relative to CVE. While statistics are not available, of the 100 candidates that were reserved, approximately 20 to 25 of those reservations were blind. There has already been a case in which blind reservation produced an inappropriate number of candidates relative to CVE's content decisions. There was also a separate case in which a candidate was obtained for an issue that already had another candidate number (though it did not take place through blind reservation). CVE diligence levels could partially address such concerns, since a requester who uses candidates inappropriately could get a lower diligence level, and eventually may not be allowed to reserve candidates again. However, some members said that diligence levels would not help, because the candidates would already be public and CVE's credibility would be affected even if the requester is not allowed to obtain more candidates. In addition, some of these errors have been made by major researchers. There could also be a credibility problem if researchers obtain candidates for vulnerability reports that turn out to be false, but Board members did not discuss this problem in detail. It was suggested that MITRE should not perform blind candidate reservation unless the requester can show that they understand CVE content decisions well enough that they can request the appropriate number of candidates. Board members agreed that this was a good approach, and that the risks of blind candidate reservation outweighed the benefits. It was also suggested that if blind reservation occurs, then the candidate should be clearly identified as such, so that educated CVE users can understand that the level of abstraction may be inappropriate. There was some discussion regarding why some organizations do not use blind candidate reservation, even if they have established that they use candidates reliably. Some requesters believe that providing MITRE with such non-public information is an acceptable risk. The additional review by an outsider increases the chances of detecting a duplicate issue that was already publicized. MITRE also becomes a "test subject" for the advisory that is being drafted, and as such can identify potentially confusing descriptions. Since there are some subtleties with respect to content decisions in which the guidelines are not necessarily clear, there is greater assurance of consistency with MITRE's involvement. Other Candidate Reservation Issues ---------------------------------- There was some discussion of situations in which multiple requesters ask for candidates for the same issue. This problem had been addressed before. Since newly discovered and unpublicized vulnerabilities are competitive information, MITRE cannot make the requesters aware that they have discovered the same problem. MITRE also cannot provide the same candidate to both requesters, because the later requester may be able to tell that the candidate had already been reserved. A specific example was provided, in which ISS and NAI both discovered buffer overflows in Network Monitor, and 2 candidates were provided (CAN-2000-0817, CAN-2000-0885). Including the affected product vendor in the candidate reservation process would minimize this risk of duplication, since the vendor would know about the duplicate, and could provide the same candidate number to both parties. Since the publicized information uses candidate numbers, educated CVE users would understand the risk of duplication; in addition, the candidate voting process would be able to publicly document and address the duplication. Some members expressed concerns that candidates were being assigned to issues too early. There was some discussion regarding the role of Bugtraq ID's and CVE candidates with respect to early vulnerability information, as well as the process by which Bugtraq ID's are assigned, but the members at the meeting did not know enough details to have a substanive discussion. It was also observed that the reservation process document that is sent to the researcher, which advocates using the SecurityFocus VulnHelp service to provide a Bugtraq ID (BID), might cause a problem because SecurityFocus is a commercial organization. The document currently recommends obtaining the BID for several reasons: (a) it is one of the most commonly used references, which ultimately helps end users when mapping to CVE names; (b) it is expected that as the number of people reserving candidates increases, more and more people will not follow the normal process of resonsible disclosure; thus the VulnHelp recommendation may increase the chance for responsible disclosure; and (c) there are no other commercial organizations at this time that provide such a service and offer a commonly used identifier. However, CERT/CC is not recommended as an option in the current documentation. The documentation will be reviewed and modified to address such concerns. The Board also discussed the distinction between Bugtraq ID's and CVE candidates. The difference is difficult to describe easily, and reflects the partial overlap between how the two are used, especially in the early stages of vulnerability information. Much of the discussion was hampered because critical members were not able to participate in the meeting. However, the distinction may become more clearly defined as time goes on. Candidate Numbering Authorities ------------------------------- MITRE discussed some of its plans for creating additional Candidate Numbering Authorities (CNA's). Certain organizations could be given the ability to reserve a collection of candidate numbers (a "pool") which they could assign and use in the initial disclosure of vulnerabilities. CNA's could increase the number of candidates that are used in initial vulnerability announcements, without involving MITRE as an additional party and increasing the risk of accidental disclosure. CNA's could increase the speed with which candidates are assigned to new problems and publicized. This is presently difficult for MITRE because it needs to process the large backlog of legacy submissions before it can concentrate solely on new vulnerabilities. Finally, if CNA's are the same organizations who are currently involved in vulnerability disclosure, then they might be able to integrate candidates into their own processes more easily than if MITRE were directly involved. Software vendors and certain third parties could be CNA's. In recent months, Microsoft has been obtaining pools of candidate numbers for its own security bulletins, and as such is effectively a CNA already. MITRE has begun exploring this option with other potential vendor CNA's, primarily major operating system vendors. Third parties who act as an interface between the researcher and the vendor - e.g. CERT/CC and SecurityFocus - could also be CNA's. While it is expected that third party CNA's should be well-known and trusted, there are special issues with third party CNA's that need to be addressed. There are several issues related to general CNA operations that need to be resolved. Proper coordination across all involved parties is necessary, to ensure that the same candidate number is used by all parties. This could be difficult for cases in which multiple vendors, researchers, or CNA's are involved. There is also an increased risk of duplicate candidates as more organizations become involved. If diligence levels are formally adopted, then all CNA's will need to be able to have access to that information, and possibly help maintain it. (Diligence levels, as currently written, need to be simplified.) It may be difficult to publicize which CNA's, vendors, and researchers use candidates, or to properly educate those who don't. In addition, the exchange of CVE names may not fit well with the current practice in which vulnerability information is shared before publication. CNA's will also need to follow CVE content decisions, which are not well documented or finalized yet. (An approach was developed with Microsoft which ensured consistency with CVE content decisions.) There are also potential risks of abuse by CNA's that are also commercial organizations, whether they are vendor or third party CNA's. There may be complications if a vendor CNA disagrees with a researcher's assessment of a vulnerability; in that case, the researcher could contact MITRE or another CNA if necessary. The discussion of CNA's was cut short due to time restrictions and the lack of appropriate Board members who could best discuss the topic. The idea will be developed in future discussions. CVE Maintenance Issues ---------------------- The process for modifying and deprecating existing CVE entries, and rejecting candidates, was briefly reviewed. More details are in the January teleconference summary at http://cve.mitre.org/board/archives/2001-01/msg00010.html. Since CVE currently has some duplicate entries, those entries will be proposed for deprecation before the next version. Similarly, a number of entries will be modified, and several candidates will be rejected (mostly because they are duplicates). Rethinking the CVE naming scheme -------------------------------- There was also some discussion regarding the current CVE naming scheme. There are two basic problems: (a) CVE names are normally not considered atomic, and as such are not easily found by most search mechanisms; and (b) the differing candidate and CVE numbering schemes cause maintenance and search problems. The current naming scheme for CVE entries is CVE-YYYY-NNNN; for candidates, it is CAN-YYYY-NNNN. However, many search engines separate the name into 3 different terms (CAN, YYYY, NNNN) because the hyphen is considered a word separator. This makes it difficult to easily find CVE information via search engines. In other cases, special quoting may be necessary. For example, a database query for a CVE name might need to quote the hyphen; otherwise, the query might return items that do *not* match the YYYY or NNNN portions of the name. Finally, the encoding of the year in the name may cause some problems with misuse, as indicated in a previous section on determining a numbering scheme for legacy candidates. Dot notation, depending on how it is implemented, could cause additional problems for searchability. Problems also arise because the candidate naming scheme (CAN-YYYY-NNNN) is slightly different than the CVE naming scheme (CVE-YYYY-NNNN). While the name visually tells a user about the status of a CVE item (candidate or entry), it can also cause some problems. For example, when a candidate becomes an official entry, all CVE-compatible vendors would need to update their databases to convert the candidate number to a CVE number. This could be labor intensive. In addition, users might still search for the candidate number instead of the CVE number; most CVE-compatible products will not find the associated CVE entry if the user uses the candidate number in the search. To avoid this problem, each CVE-compatible product would need to implement a specialized function. Some products omit the CAN- and CVE- prefixes outright, but this prevents the user from knowing whether the item is a candidate or an entry. The CVE web site handles these discrepancies flexibly, but it requires some special code. Many CVE-compatible tools are not as flexible, and such a capability is not required because CVE compatibility does not require use of candidates. A solution is to construct the CVE names in a way that minimizes these types of implementation problems. Using just a number would not be appropriate, because numbers are so commonly used in so many databases and search engines. A scheme like the one used by the arachNIDS IDS signature database, e.g. IDS297, might be better. If such a scheme is adopted, then the status of a CVE item - whether candidate or entry - could be noted as a separate field in CVE. There were no objections to this proposal. No decisions were made with respect to changing the CVE numbering scheme. It is uncertain how many products or web pages currently use the existing names, and how the names are actually implemented. There will be high maintenance costs in some cases, along with additional education of the public. However, in the long term, it may be appropriate to use a different numbering scheme. These problems could be reduced if candidates are promoted to CVE entries faster. However, that would require more active participation by the Editorial Board in voting. Also, if stringent verification requirements are adopted for CVE entries, there may be permanent candidates. Common Intrusion Event List (CIEL) ---------------------------------- A dynamic discussion was held regarding the progress of the Common Intrusion Event List (CIEL), which is being developed by Bill Hill and Steve Christey at MITRE, with additional support from other MITRE personnel. CIEL is sometimes informally described as "a CVE for intrusion detection." It is intended to provide a naming scheme for events - whether on a network or on a host - that may be useful in detecting intruder activities, but are not directly associated with CVE items. For example, port mapping, ping mapping, legally structured network requests, or failed binary integrity checks do not easily map to CVE entries. In addition, the process that is being used for assigning CVE names might not be appropriate for IDS events. MITRE has produced a draft CIEL which contains 37 entries, most of them at a high level of abstraction, with additional fields that support lower levels of detail. MITRE has begun mapping various IDS signatures to CIEL names and using those mappings for analysis. In one experiment, MITRE was able to reduce the number of reported events by 15 percent, by converting the logged events to CIEL names and removing duplicates. MITRE has been observing the development of the data models of the IETF Intrusion Detection Working Group (IDWG) to identify possible conflicts with CIEL. The IDWG efforts are more comprehensive in scope. A common attack name is a small but important part of the data models, which specifically mention CVE and the Bugtraq ID as potential naming schemes. CIEL Assumptions and Rationales ------------------------------- MITRE presented the assumptions and rationales for its approach in developing the draft CIEL. Since intrusion detection is event-focused instead of vulnerability-focused, MITRE decided to develop it independently of CVE. Various "CVE lessons learned" were used to guide the creation of the draft CIEL, but the expected use of CIEL drove its development. MITRE's own research and operational efforts in intrusion detection provided additional guidance. The initial focus was on network-based events; however, CIEL is expected to include host-based events as well. Several assumptions were made during development of the draft CIEL: - there is a wider variety of IDS events than vulnerabilities - there is more variety across IDS's in the level of abstraction (or level of detail) than there is in vulnerability scanners and databases. - there is not much well-defined and commonly accepted terminology in IDS CIEL Discoveries ---------------- It was often difficult to understand how an IDS examined and identified an event, as details were rarely provided. This was often critical in deciding how to name the event. It was recognized that the actual method of detection might be competitive information. Since those details may not be publicly available, users should be able to assign a CIEL name without them. Thus it was decided to create CIEL entries for each event as it is reported, independent of how the IDS identifies the event. However, the lack of information could make it difficult for non-vendors to create CIEL mappings, which would limit the end user's ability to make an IDS "CIEL-compatible." This problem is not so serious in vulnerability scanners and databases. MITRE examined the construction of CIEL for satisfying two main purposes: normalizing data in order to facilitate quantitative analysis (e.g. for comparing tools by counting how many CIEL entries they have), and supporting the exchange of information across tools. Often an approach would be useful for one purpose but not the other. With the varying levels of abstraction used by tools, CIEL's use as a data normalizer could be limited. The focus for creating CIEL was therefore on supporting information exchange, and the approach addressed several important issues that were encountered in the draft CIEL's creation. However, this approach may have an impact on CIEL's use in metrics. CIEL "Content Decisions" ------------------------ Part of CVE's success is due to its simplicity. MITRE decided that this should be a requirement for CIEL as well. While the CIEL name has multiple components and is different than a CVE name, it is still basic enough that it can be represented with a simple syntax. Since IDSes operate at more widely varying levels of abstraction, it was decided that CIEL would need to support multiple levels of abstraction. Thus, most CIEL entries are hierarchical in nature. However, there were cases in which a type of event was unique to a type of attack, application, or protocol. It was decided that such unique characteristics, if reported by IDSes, would need to be captured by a CIEL entry, even if the entry was at a lower level of abstraction. For example, the FTP bounce attack is specific to the FTP protocol, and could not be easily described by CIEL entries that were at a higher level of abstraction. Some difficulties in creating the first CIEL entries involved the types of events that are reported by today's IDS technology, in comparison with events that might only be detectable by future IDSes. It was decided that the focus should remain on the types of events that can be detected by current IDS technology. CIEL Entry Data --------------- The following information is included with each entry in the draft CIEL. 1) Name - the CIEL name, of the form CIELn, where n is a unique number. 2) Description - a short description of the entry. 3) Context fields - additional fields that provide additional information that may help distinguish events at a lower level of abstraction. Up to 3 different context fields can be used for each CIEL entry. The types and values of each field are dependent on the specific CIEL entry. Context fields could allow IDSes that operate at different levels of abstraction to share information at a high level, via the same base identifier (the CIEL name). In some cases, context fields were used to handle cases in which it was infeasible to use separate CIEL names for each "instance" of an event type. For example, there is a single draft CIEL entry that is related to Trojan horse activity, with a context field whose value indicates the specific Trojan horse being used. Many context fields in the draft CIEL would require normalized values. CIEL will need to include such "value mappings" to ensure consistency across IDSes. (For example, one IDS might report "Tribe Flood Network," whereas another one reports "TFN"; such information, which may be recorded in a context field, needs to be normalized.) 4) Notes - background information on the rationale behind the CIEL entry, or a description of which context fields would need normalized values. A short symbolic name was also provided for ease of use in mappings, and may be included in later CIEL versions. Most items in the draft CIEL did not have good references that would describe the type of attack in more detail; thus, references were not included. Review of Draft CIEL Entries ---------------------------- MITRE presented several draft CIEL entries for discussion. The examples were posted to the Editorial Board mailing list, and are archived at http://cve.mitre.org/board/archives/2001-03/threads.html with the subject "[CIEL] Extracts from the Draft CIEL" 1) CIEL1, which is used to describe all types of ICMP events (ping, netmask request, etc.). The context fields are used to identify the type and code, as defined in the ICMP RFC. 2) CIEL2, which describes TCP related activities. The context field captures the source and destination number. One problem with respect to this entry is that some IDSes may detect and report services on nonstandard ports. 3) CIEL22, which identifies attacks on specific vulnerabilities in the targeted systems. The context fields include the name source (e.g. CVE), and the actual name (e.g. CVE-1999-0067). The allowance for multiple naming schemes is currently being used in IETF Intrusion Detection Working Group (IDWG) standardization efforts, so it made sense to support it here. 4) CIEL23, which describes Trojan Horse activity. The context fields include the name of the Trojan, the specific action being taken, and any arguments that may be extracted or identified. 5) Some lower-level entries. Board members believed that these entries might be captured by other higher-level CIEL entries in the draft CIEL; or, additional high-level entries could be constructed. Some Board members questioned the use of a single CIEL entry, CIEL22, to describe all possible attacks on specific vulnerabilities. This reflects MITRE's decision to design CIEL for interoperability instead of metrics. Some IDS'es may detect hundreds of vulnerability exploits, but they would only be covered by one high-level CIEL entry. However, interoperability is still possible by using the context fields that identify the name of the vulnerability being exploited. It was posited that all items covered in an IDS could be described by some vulnerability or exposure, and as such would always have some CVE name associated with it. Future efforts in CIEL (and CVE) will show whether or not this is the case. Some Board members said that the draft CIEL as presented makes it difficult to determine the CIEL name for events that fall under the higher-level CIEL entries, i.e. events that can only be described using context fields. Strong networking knowledge or research is often needed. For example, to determine the CIEL name for an ICMP echo request (ping), the CIEL user would need to know that the type is 0 and the code is 8. This significantly reduces the usability of the draft CIEL as currently written. A reference document could be created that matches well-known events (such as ping) with their CIEL names to increase usability. It was also proposed that a naming system similar to the Dewey decimal system could be adopted; the CIEL name, in conjunction with its context fields, may be similar. Many participating Board members, especially the IDS vendors, found that the high-level draft CIEL entries did not seem to describe same categories that they might have used. In some cases, the problem may have been due to MITRE's lack of information on the precise way in which some signatures were detected. As such, the draft CIEL may represent more of an end-user perspective than a vendor's perspective. Board members also discussed some CIEL entries that were at a much lower level of abstraction than others. Members believed that they could create a higher-level entry which would include the lower-level items. Overall, the Board agreed with the hierarchical nature of the draft CIEL. CIEL Future Work ---------------- MITRE will create a CIEL working group and mailing list that is part of the CVE Editorial Board. MITRE plans to add other members to the Board for the purposes of the working group. The group may be expanded to include other individuals or organizations who are not part of the Editorial Board. MITRE will provide the working group with the full draft CIEL as a starting point for further discussions. Board members discussed adapting the draft CIEL to reflect a more natural classification of IDS-reported events. Each member could provide a representative list of approximately 20 signatures from their products, and a proposal for high-level CIEL entries that would cover those signatures. The end result could be a draft CIEL that is better suited to interoperability of IDS products. MITRE will continue to use its draft CIEL to create mappings, perform some analytical tasks, and share lessons learned with the working group.
|
||||
