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

Re: CVE assigning/CNA process overview



I like the mentor idea to help keep assignments and content consistent. 


My concern is how do we train and identify these mentors?   This is not an exact science and takes experience to get to the appropriate level of judgment. 


I do think they could have big value and help CVE scale better though. 


Scott


From: owner-cve-editorial-board-list@lists.mitre.org <owner-cve-editorial-board-list@lists.mitre.org> on behalf of Kurt Seifried <kseifried@redhat.com>
Sent: Tuesday, November 15, 2016 11:54:47 PM
To: cve-editorial-board-list
Subject: CVE assigning/CNA process overview
 
I’ve been thinking about how we assign CVEs/create CNAs.

I want to divorce the technical process from the assignment process (I’ve already done this to a large degree with people I deal with, basically it boils down to “please explain the impact of the vulnerability so I can determine if it’s a security vulnerability, and then any details needed to apply counting”, mostly so I can outsource the work and scale myself. To put it bluntly you don’t need to be super technical to understand this most of the time. 

As such I see the role needed as a “mentor”, the mentor has two main jobs: to decide if something is a security vulnerability (simple yes/no) and to apply the CVE counting rules (with guidance from other mentors if really messy). Essentially they ask question to determine if this is a security vulnerability or not, and how to apply counting rules, they then sign off on the CVE assignment (which can then be handled automatically). They are given credit for the assignment (since they did the assignment related work). Mentors have access to other mentors (ultimately the DWF and MITRE itself) to ask for help if they encounter a particularly messy situation (like a protocol level vulnerability). 

Mentors can also provide other services (e.g. coordination) if they wish, but this is NOT required. 

From the CVE request side it would look like:

CVE Request/assignment maturity model:

1. Request CVE through public channels (e.g. guided web form), relies on DWF for mentor
2. Request CVE through structured channels (JSON format), relies on DWF for mentor
3. Request CVE through structured channels (JSON format), has their own mentor
4. Partial CNA - has block but relies upon external mentor(s)
5. Full CNA - has block, has internal mentors

Currently we basically only have options #1 and #5, nothing, or all the way a CNA.

The reason for #2 is that it gets people using our tool chain (so JSON format/etc.) and then makes it easier to step into more mature CNA/security process.

The reason for #3 is that we can have specialized mentors (such as an IoT/Linux person) that is well known and people go to for assistance in getting CVEs. 

The reason for #4 is to provide an intermediary step for projects that are in the process of maturing (when building a security team).They can become a partial CNA, use an external mentor, and then once trained up they can have an internal mentor(s) to do the work.

Please provide feedback/comments/concerns, does this work for you? What parts will be a problem, etc. Also I'll be bringing it up for discussion on the board call tomorrow. 

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com

Page Last Updated or Reviewed: November 21, 2016