RE: dispute resolution

["Coffin, Chris" <ccoffin@mitre.org>]

Art,

> Continue with the current assignment rules and CNA expansion (and 
> expanding the git/github pilot).
> ...
> The rest of the CVE downstream ecosystem can keep right on moving.  
> Those who want to treat disputed entries differently are free to do 
> so.

I like this approach since it lessens the amount of analysis needed up 
front in assignment. Once published, the community should be able to 
provide some amount of effort in determining whether the vulnerability 
should stand or whether it might be a split or merge situation. I think 
one key in this is making it simple and straightforward for folks to 
dispute something. Maybe create a simple web format that allows quick 
and easy reporting. A new state could also be created for these cases, 
but my current thinking is that DISPUTE should be sufficient to cover 
all of these cases.

> Who has dispute permissions?  Board members, CNAs, anyone?

Once reported, I'd say it's up to some other entity to change the CVE 
state and add the dispute information. Currently this is the Primary 
CNA, but maybe a role could be defined for this and it could be 
performed by others (e.g., Root CNAs).

Chris

-----Original Message-----
From: owner-cve-editorial-board-list@lists.mitre.org 
[mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of 
Art Manion
Sent: Wednesday, December 6, 2017 9:38 AM
To: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Cc: Carsten Eiram <che@riskbasedsecurity.com>
Subject: dispute resolution

We're repeatedly running into issues with how to handle disputes.  This 
should be expected with the increasing number of CNAs and federation.

A few recent examples:

"An interesting data point" thread

"Problematic assignments for subpar reports via CVE request form" 
thread (Lin Wang)

On 2017-12-06 10:00, Waltermire, David A. (Fed) wrote:
> Under #3 or as a separate item, I'd like to have us explore what the 
> workflow could be for submitting corrections to another 
> organizations. 
> For example, what if the NVD finds a spelling error in a CVE entry 
> description or a fixed broken reference? How could we submit a pull 
> request to kick off a workflow to allow that feedback to be addressed 
> by the appropriate party? What degree of automation could we use to 
> support this?

While we will always need board and CNA discussions to work out 
emerging issues and policy and technology solutions, I suggest we look 
at something more distributed and lower effort.

I see at least two classes of dispute that get 
conceptually/subjectively difficult to resolve:

1. "not a vulnerability"

2. Split/merge

Here is just one idea.

Continue with the current assignment rules and CNA expansion (and 
expanding the git/github pilot).

For any dispute, flag the entry (possibly using the existing DISPUTED 
state/status, although I also want to review CVE states).  Along with 
the flag there needs to be a way to capture the nature of the dispute, 
possibly a short text/log entry, like "crash only."  Also the source of 
the dispute.

On ${date} Carsten disputes CVE-2016-LINWANG with reason "crash only, 
no evidence of security impact."

The rest of the CVE downstream ecosystem can keep right on moving.  
Those who want to treat disputed entries differently are free to do so.

And if/when a dispute is resolved, update the entry.

Who has dispute permissions?  Board members, CNAs, anyone?

For split/merge issues, the dispute logging feature could record the 
proposed relationships:

https://github.com/FIRSTdotorg/vrdx-sig-vxref-wip/blob/master/vxref/schema/vxref_schema_03.json

I'd suggest this as a board meeting agenda item, although I'm doubtful 
for the 12/13 meeting.

Regards,

 - Art