[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[CVEPRI] CVE Editorial Board Meeting Detailed Agenda

[This is a resend of the previous message, with the CVEPRI tag added
to the subject, in case people filter on that.]


CVE Editorial Board Meeting Detailed Agenda
-------------------------------------------

Following is a detailed agenda for the Editorial Board meeting.  There
will not be any PowerPoint slide presentations.  Most of the content
is in this agenda.

Supporting material will be sent in other posts.

Thursday, March 15 - 9 AM to 5 PM Central Time
Friday, March 16 - 9 AM to 4 PM Central Time

Thursday
--------

There is a morning break, lunch break, and afternoon break.

Morning - 9 to 12 PM
  - Content update
  - Voting
  - Editorial Board

Lunch Break - 12 PM to 1 PM

Afternoon - 1 to 5 PM
  - Editorial Board continued
  - Future CVE activities
  - Advisory council update
  - Cisco CSEC DB demo
  - Content decisions


Friday
------

There is a morning break, lunch break, and afternoon break.

Morning - 9 to 12 PM
  - CVE compatibility
  - Candidate reservation and CNA's
  - CVE maintenance issues
  - Content decisions continued, if necessary

Lunch Break - 12 PM to 1 PM

Afternoon - 1 to 4 PM
  - Remaining business
  - CIEL



================================================================
Content update
================================================================

- Legacy candidates/submissions
  - cleaned up submissions; relabled some as "new"
  - total legacy submissions: 7794
    - not including some "lost" Cisco items
  - total matched: 7696
    - original goal was to finish matches by June 15th!
    - "optimized" the matching method
    - HOWEVER, increased risk of duplicate candidates
  - all matching to be complete by April 2
  - ~4200 total submission groups need to be refined into
    candidates
  - ~3500 groups have no matching CVE/CAN, so we'll get about 3500
    new candidates
  - Should these get CAN-1999-XXXX numbers, or just stick with
    CAN-2001-XXXX?
    - there will always be a need for a few old CAN's
- New security issues
  - Exceeded 100 reserved candidates!  (Primarily major org's)
  - More vendor involvement (e.g. Microsoft; speaking to others)
  - Chris Walzer, Ramsay Key involved in submission matching
    - will move to refinement in next month or two
- Content team tasks
  - Barbara Pease - refinement of legacy issues
  - Jeff Taylor - refinement of legacy issues
  - Jean-Paul Otin - NT configuration problems
  - Chris Walzer - new submission matching
  - Ramsay Key - new submission matching
  - Dave Goldberg - ad hoc consultation
  - *might* have additional personnel
- MITRE content goals
  - New CVE version within a month
    - Deprecation, modification, candidate rejection
  - Candidates for new issues every 2 weeks
  - Candidates for legacy issues every 1-2 months
    - Make it easier for users to distinguish new from old
  - Finish refining 1999 submissions by July 1
  - Finish all legacy candidates by December 2001
- Threatened lawsuit by vendor regarding CVE candidate


================================================================
Voting
================================================================

- Despite January teleconference discussions, there is little increase
  in number of votes
- Will expand Board until enough votes are received
  - Unless existing Board members can contribute more often
- Voting guidance/confidence requirements
  - publicize on CVE web site so that "buyer can beware"
  - voter should only ACCEPT or MODIFY if:
    - the vendor has acknowledged the problem
      - is it enough if the researcher says there's a patch?
    - the voter - or their organization - has verified the problem
      themselves
    - someone that the voter trusts has verified the problem.  This
      could include the original researcher, if the researcher is
      trusted by the Board member
    - has independent confirmation, i.e. 2 different sources claim
      to have reproduced the problem.  Example: initial Bugtraq post
      and followup
  - reason for confidence is provided to Board members, but not
    publicized
    - knowing that a Board member has accepted something, someone else
      could then ACCEPT
  - consider "UNCERTAIN" vote: CVE description and references
    accurately summarize reports, but reports may not be accurate, and
    voter is not certain if problem is real
  - "grandfather" existing entries, and/or re-verify?
- Voter summaries every time a new CVE version is announced
  - included with version difference reports

================================================================
Editorial Board
================================================================
- Tasks being examined
   - Roles: technical, liaison, endorser
- Will post "final" task list to Board mailing list
  - Maybe publish on public web site


Formalizing Board Tasks and Roles
---------------------------------
- Next week, each member will be sent an individual statement
  summarizing their expected role, past tasks, current tasks, and
  expected tasks
  - A summary of the Board as a whole will also take place
- Board members review their own tasks and expectations
- Consult with Chair
- Each member's role and task list will be finalized in 2 months, then
  posted to whole list
  - Possibly recorded on CVE web site?
- New members
  - Specific roles and tasks will be announced when member joins
- Legacy members
  - Formalize expectations of specific roles and tasks
  - How much leeway should be allowed for "charter" members?
- If people want to keep the Editorial Board small, then we need more
  input from existing members, especially voting
- "Resume padding/marketing" shouldn't be allowed unless the member is
  contributing actively
- There are more and more people asking to join


Board Member Roles
------------------

Each Board member might play multiple roles.  Most only play one.

MITRE roles
  Editor - responsible for content
  Chair - responsible for Editorial Board
  Technical Contributor - content team, task leader, etc.

Technical Member - Participates in the design, review, and maintenance
of CVE and/or its applications.
  - Basic requirement: technical skill
  - Benefit to CVE: higher quality of list
  - Expectation: consistent participation in CVE technical tasks,
    e.g. voting or maintenance

Liaison - Represents a significant constituency, related to or
affected by CVE, in an area which does not have technical
representation on the Board.
  - Basic requirement: be visible to their own community
  - Benefit to CVE: awareness of broader context or needs
  - Expectation: consistent participation in CVE when liaison's
    community is affected; technical level

"Endorser" - Actively supports CVE in a highly visible fashion.
  - Basic requirement: be a respected leader in the community
  - Benefit to CVE: credibility, wider reach
  - Expectation: provide external visibility to CVE, participate in
    strategic planning
  - Does any other name make sense?
  - Question: who says that someone's a leader?
  - Answer?: Editorial Board votes (secret ballot)

Legacy Member - An individual who was formerly active in CVE and
maintains an "honorary" position.
  - Question: who decides a legacy member?
  - Answer?: Editorial Board votes (secret ballot)


Editorial Board Member Tasks
----------------------------
- Voting (regular or ad hoc)
- Active in meetings/telecons, and/or hosts meetings
- Ad hoc/offline consultation
- CVE process (content decisions, review process, procedures, Board
  structure, etc.)
- Content provider (provides databases for CVE content)
  - already done by non-members
- IDS/CIEL
- Involved in CAN reservation
  - uses CAN's in advisories, or is prospective CNA
  - already done by non-members
- CVE compatibility
  - already done by non-members
- Non-CVE activities
- Liaison
- CVE promotion (visible/active promotion of CVE)


Level of Participation
----------------------
- How often should participation be?
  - Some tasks only happen every few months
  - Also depends on the role
- For how much time or expense?
  - 3 hours/week is recommended minimum
  - Only about 5 members appear to do this
- How much time should formerly active participants be given,
  especially for "charter members" who were critical supporters?


Maximum number of members
-------------------------
- Could argue for 2 per organization, from different parts of that
  organization; or different tasks
  - But sometimes, one person is active, and another isn't
- Minimum requirements for 2 members
  - Constant activity in one task, or consistent activity in 2 roles

Trial Membership
----------------
- Should all members be added on a trial basis?
- How long should the period be?
- Don't necessarily have to advertise that the trial member
  is involved
- If person is unable to participate in that time frame, then Board
  is clearly not for them
- Could "guarantee" at least a minimum level of participation, but
  what happens after then?
- What if mem's use voting just to stay active?
  - Their name, and their company's name, is still in the record


================================================================
Future CVE Activities
================================================================
- Content goals
  - More voters per candidate
  - 1600 entries by June 1
  - 2000 entries by December 1

- Qualitative goals

- Future outreach
  - MITRE presentations
  - Case Studies
  - Interoperability demo
  - Panel/BoF


================================================================
Advisory Council Update
================================================================
- Members
- Charter
- Meetings
- Web pages
- Funding status
- Presentations by Board members


================================================================
Content Decisions
================================================================

See Editorial Board mailing list post on March 13 for background
material on CD:SF-LOC and CD:SF-EXEC.

- Plan to publicize CD's somehow
  - Maybe as a separate extension, e.g. reference maps
  - Rough indicator of noise


================================================================
CVE Compatibility
================================================================


Miscellaneous
-------------
- Basic requirements: Searchable, output, mapping accuracy
- For publicly available products, services, and web sites
  - No beta or alpha items need apply
  - Version with CVE names does not need to be available yet
- Security services an emerging category
  - What does "searchable" mean here?
  - Often use multiple tools
- Upcoming requirements changes
  - Product documentation must cover the use of CVE names
  - Separate high-level requirements from "implementations"
    (e.g. service, IDS, scanner, database)


Two stages for CVE compatibility branding
-----------------------------------------
- Stage 1
  - declaration of intent for compatibility
  - endorsement quote
  - review by knowledgeable CVE team member
  - listed on CVE site
- Stage 2
  - written statement of compatibility
  - supporting user documentation
  - can require MITRE to sign non-disclosure for assessment
  - sample of data base to verify mappings to CVE names
  - evaluation of statement
  - evaluation of mappings
  - concurrence with statement
  - access to logo and CVE promotion/explanation materials
  - statement is posted on CVE site


Process for 2nd stage of compatibility
--------------------------------------

- Step 1: appropriate CVE statement of compatibility filled out by
  applicant (web site, tools, service, data base, etc.)
	
- Step 2: applicant sends filled in statement to MITRE along with
  normal user documents and CVE relevant elements from vulnerabilities
  data base (MITRE will select ~50 items or 10% of the data base to
  examine).

- Step 3: MITRE evaluates statement and mappings using user documents
  to validate that all appropriate uses of CVE are covered in
  statement.

- Step 4: MITRE concurs with applicant's statement and sends applicant
  user-id and password for CVE compatibility web site.

- Step 5: applicant gains access to CVE-compatible logos and
  supporting information on CVE for hosting onto their web site and
  inclusion into their documentation.

- Step 6: statement is published on CVE web site.


Other information for CVE-compatible item's Organization
--------------------------------------------------------

- CVE Link Button

- CVE news announcements for MITRE's concurrence w/compatibility

- Special emphasis/section for concurrence on CVE web site

- Coordinated press releases?

- FAQ question/answer, e.g.:
   Q:  "Is productnamehere CVE-compatible?"
   A: "Yes, organizationnamehere's or servicenamehere is
       CVE-compatible. CVE is...  A CVE-compatible product is..."

- Glossary terms:
  - "CVE" & definition
  - "CVE-compatible" & definition

- PDF file for CompanywithCompatibleProduct&CVE
  - we already have some of these we could convert and send

- HTML description of CVE (brief)
  - such as on Harris's CVE page



================================================================
Candidate Reservation and CNA's
================================================================

- Basic candidate reservation approach
  - there is a REQUESTER - researcher, vendor, or response team
  - requester makes initial inquiry about process
  - MITRE send writeup on process and rationales
  - MITRE asks for details of vulnerability
  - requester provides details
    - if willing
    - if not, MITRE provides CAN anyway, but this is called Blind
      Candidate Reservation
  - MITRE reserves CAN's
  - MITRE sends CANs to requester
  - MITRE updates CVE web site w/generic CAN's
  - requester publicizes vulnerability, including CAN
  - requester notifies MITRE
    - in practice, this doesn't always happen!
  - MITRE updates CVE web site w/new information
  - MITRE proposes CAN to Board
  - MITRE notifies requester when Final Decision happens
  - requester updates advisory (where possible)
- Blind Candidate Reservation
  - Reservation of candidates without MITRE knowing any details, or
    only knowing very limited details
  - Pro's
    - MITRE non-involvement (reduced risk of accidental disclosure)
    - Immediate access to CAN (if a CNA is involved)
  - Con's
    - CVE web site has generic information for up to 2 days
    - Misapplied content decisions
    - Increased risk of duplication
- Candidate Numbering Authorities (CNA's)
  - An organization could reserve a *pool* of candidates, not related
    to specific issues at the time, for use in initial public
    disclosure
  - Vendor CNA's
    - Should have/need an advisory capability (i.e. scale)
    - Microsoft is effectively a CNA already
    - Others to follow?
  - Third Party (reissuing) CNA's
    - E.g. CERT or Security Focus
    - Should be known/trusted, initial "publication" source
  - Pro's
    - "on-demand" candidates - not entirely dependent on MITRE
      availability
    - Reduce interference with current disclosure practices
    - Immediate candidate access on publication of a new problem,
      instead of current 1-8 week delay
    - Overall increase in use and visibility
    - Can keep MITRE out of picture
  - Con's
    - Coordination is critical!
      - between researcher, vendor, CNA, and possibly MITRE
    - Increased risk of misapplied CD's
    - Increased risk of duplication if researcher uses multiple CNA's
      - but could handle this with diligence levels
    - Bias concerns if CNA is a commercial entity
- Vendor involvement
  - Starting to work w/vendors
    - More efforts in coming months (ad hoc)
  - Basic approach:
    - vendor given a pool of CAN's
    - vendor uses basic content decisions
    - vendor provides CAN's to researcher
    - if researcher provides CAN, vendor must use that
    - if CAN assigned - even if researcher doesn't use proper
      disclosure - then vendor should try to use that CAN
    - if duplicates arise, more official CAN (i.e. vendor) should be
      used.
  - Approach could apply to vendors who are not CNA's
  - Pro's
    - Multiple discoveries of same problem don't produce duplicates
      (e.g. NAI/ISS/Netork Monitor overflows)
    - "Official" acknowledgement of vulnerability
  - Con's
    - Researcher wants CAN, vendor disagrees
      - MITRE/Third party provides CAN to researcher
        - label it now, sort it out later
    - How to inform researcher that vendor uses CAN's?
      - publicize on CVE web page
      - include in "help" information
- Simplification of content decisions necessary
- Simplification of diligence levels
- Publicize new capability once CNA's are set up, and/or MITRE can
  provide 12-by-5-by-1 response (12-hours days, 5 business days/week,
  within 1 business day)


================================================================
CVE Maintenance Issues
================================================================


Entry deprecation and modification
----------------------------------
- Deprecation
  - Require 2 week review period?
  - Require votes
- Modification
  - Require 2 week review period
  - "silence implies assent"


Handling duplicate candidates
-----------------------------
- General approach
  - favor more "official" candidate
  - otherwise, favor first public CAN
  - annotate in references
    - CVE-XXXX-YYYY has ref DUPE:CAN-ZZZZ-NNNN
    - CAN-ZZZZ-NNNN has ref DUPE:CVE-XXXX-YYYY
  - rejected CAN includes CVE in description


Permanent candidates
--------------------
- Some candidates might be real, but never get enough votes
- Should these be "marked" somehow?
  - UNCERTAIN votes, plus age, may be sufficient warning
  - Or, candidate could be marked as "expired"


Rethinking the CVE naming scheme
--------------------------------
- CAN-XXXX-YYYY and CVE-XXXX-YYYY is expensive for maintenance
  - Can also produce search inaccuracies
  - Could use just "CVEx" and have a field that separates a CAN from
    a CVE
- Some CAN's may be permanent (never get rejected, but never get many
  votes)
- Can't easily search for CVE's on search engines
  - CVE-1999-0003 broken into "CVE 1999 0003"
- GENERIC-MAP-NOMATCH doesn't fit the CVE naming scheme; other mapping
  specifiers will eventually be needed, e.g. GENERIC-NOT-A-CVE
- Dot notation may be problematic as well


================================================================
CIEL
================================================================
- Rationales
  - Rule #1: No Sacred Cows
  - Corollary: This is not your mother's CVE!
  - Start from scratch
    - Use lessons learned from CVE, but don't be ruled by them
    - Let CIEL happen "naturally" based on induction
    - Guide it by our own internal practical needs
      - Focus on network-based attacks
      - MITRE's real-world and research uses
  - Assumptions
    - IDS has more abstraction problems
    - IDS has more terminology problems
    - Wider variety of IDS events than vulnerabilities
  - Discoveries
    - Extremely difficult to know *how* an IDS knows something
      - Also could be competitive information
    - Insufficient information (references, details) make it
      difficult/impossible to map to CIEL entries
      - will force greater reliance on accuracy of vendor mappings
    - CIEL as "data normalizer" gets in the way of mapping and
      interoperability
      - Too many varying levels of abstraction
      - Too many "what if's" spoil the broth (what if method X is
        currently used for detection, but IDS'es develop method Y?)
    - Creating CIEL entries, and/or doing CIEL mappings, can require
      a lot of expertise (e.g. protocol commands and arguments)
  - Content Decisions
    - Decided to rely on what's reported
    - "Universally" simple format/syntax
    - Support multiple levels of abstraction when it made sense
    - Rely exclusively on what's seen by today's IDS'es
    - Favor mapping/interoperability over metric usage
      - Costs: varying levels of abstraction, reduced use in metrics
      - Benefits: not as many headaches
    - If the event is unique to an attack/application/protocol, then
      it needs to be distinguished
    - should local vs. remote "detects" of the same attack/vuln be
      separated?
- CIEL entry data
  - Name (CIELnn) --> support searchability
  - Description
  - Context fields (context1, context2, context3)
    - "expand" on the primary CIEL entry
    - provide a critical distinction
    - values depend on the specific CIEL entry
    - most values need to be normalized
  - References?  For IDS?
- Real examples from the draft CIEL
  - TCP events; Trojan horse; ICMP events; CVE mapping; and a
    low-level CIEL to show varying levels of abstraction
- What we're doing now: mappings
  - Snort signatures
  - Firewall logs
    - Resulted in 15% log reduction in 1 day's real data, using 3
      CIEL entries
    - Mapping had to be done on real data; can't really do a mapping
      ahead of time.
- CIEL futures
  - CIEL working group under CVE Editorial Board
  - Add new CIEL-specific Board members
  - Separate mailing list?
  - Call for vendor event lists
Page Last Updated or Reviewed: May 22, 2007