CVE assigning/CNA process overview

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

CVE assigning/CNA process overview

Kurt Seifried
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: [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: CVE assigning/CNA process overview

Millar, Thomas

This mostly makes sense to me. How do we make mentors discoverable?

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kurt Seifried
Sent: 15 November, 2016 23:55
To: cve-editorial-board-list <[hidden email]>
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: 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CVE assigning/CNA process overview

Scott Lawler
In reply to this post by Kurt Seifried

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: [hidden email] <[hidden email]> on behalf of Kurt Seifried <[hidden email]>
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: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CVE assigning/CNA process overview

Kurt Seifried


On Fri, Nov 18, 2016 at 2:22 PM, Scott Lawler <[hidden email]> wrote:

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. 


They will be listed in the DWF-CNA registry, I'm cheating and grabbing a few people that have already CVE assignments. Also one aspect of this is for the messier assignments they in turn can go to other mentors (e.g. me) who do have experience splitting babies and rounding up cats as it were. 
 


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

We can't have everyone be a complete expert, that won't scale, but we can definitely do "good enough" (like we already do). 

 


Scott


From: [hidden email] <[hidden email]> on behalf of Kurt Seifried <[hidden email]>
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: [hidden email]



--

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]