CVE Board Meeting summary - 27 May 2020



I wanted to resurface the Physical Attack Discussion. I think we agreed to update the counting rules to reflect the conversation below. Intel is planning to update our Bug Bounty Scope guidance to clarify the physical attack scope.

I wondered what the next steps are for the CVE program?

Katie

02.19.01

Identify the industries for active and pipeline CNAs so get a complete picture of the CNA profile.

OCWG

In Process

5/27 Update: The group reviewed the active and pipeline CNAs and have begun to assign industries.

5.13.02

Take the lead for developing a proposal about approach for automated vulnerability identification workshop that includes an initial target participant list, and report back to next CVE Board Meeting on May 27, 2020.

Kent L. (McAfee)

Not Started

§The podcast planning is underway; the group agreed to use Skype or MS Teams and a tentative date is scheduled for June 11.

§Jonathan will provide an updated list of vendors based on the CVE IDs requested from MITRE.

§Successful non-US meetings were held with European and Asian participants (Taki attended, and JP-CERT is interested in attending future meetings)

§The virtual summit is scheduled for Monday, October 19, 2020, from 1:00 p.m. to 5:00 p.m. ET.

§Matt B/Joe W. provided an overview of the CVE Entry states for the feedback for the Entry Submission and Upload Service.

§Focused on general design document around container tagging for EOL and service tags

§Starting to talk through how new tags will get added: How will the proposals be processed and approved and assigned to the right working group (e.g., CNA specific tags)?

§Also discussing different types of tagging around reference types

§Dave explained that we need a place to host the list, valid tag names, valid reference types, etc.

§The document was sent to the CNA list for feedback on May 21.

§Next step is to tech edit the document and then send to CVE Board for approval and program acceptance.

      • We have emailed CNAs that are missing disclosures policies and/or advisory locations. We have emailed 19 CNAs and we have received the requested information from 8 CNAs; 11 are outstanding.

§The initial translation is finished and we are now reviewing the slides internally. This is taking a bit long, as the amount of our coordination work has increased more than we expected. Therefore, although things are still moving forward, not everything (including our PR team review) will be finished by the end of May as we planned.

  • The group discussed if CVE IDs should be assigned to vulnerabilities that require physical attacks (e.g., opening the case or "evil maid" attacks)?
    • Some products attempt to protect against these attacks (e.g., hard drive encryption) and we want to support them.
    • If the vulnerability is created by a physical attack that violates a security model, we will assign a CVE ID. If it does not violate that security model, then we would not assign a CVE ID.

DWF Postmortem discussion: Lessons learned and opportunities going forward

  • Many companies use open source products. INTEL has experienced an influx in CVE IDs requests and no one wants to deal with it. DWF provided coverage for open source products, but today we do not have a representative from a CNA perspective.
  • David expressed that we need a little time to think about it and discuss at the next meeting or schedule a meeting specific for this topic.
  • We already have people coming to us, telling us about RBPs. If we make this metric public facing, then community members will be motivated to report them to us. The only number to be reported will be the total number RBPs, not the actual IDs with the details.
  • Chris L. explained the two benefits from publishing the metrics 1) to get more community help and 2) to tell a story about the reduction in RBPs



Previous Email: CVE Board Meeting summary - 27 May 2020

Next Email: UPDATED: CVE Board Agenda for Wednesday, 27 May 2020

May 2020 Email Index