Re: dispute resolution

[Kurt Seifried <kseifried@redhat.com>]

On Wed, Dec 6, 2017 at 8:38 AM, Art Manion <amanion@cert.org> wrote:

>
> 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.

the state for disputed/details already exist, just use:

"STATE": "DISPUTED"
"STATE_DETAILS": "BLAH BLAH BLAH"

>
> 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?

I think like CVE requests it should be a claims based process, the
better the claim/evidence, the more likely it is to succeed.

> 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

I think the more important question would be where do we initiate the
dispute? I would suggest:

1) if it's a global type issue (e.g. description, affected data not
owned by a CNA), the originating CNA is your starting point
2) if it's an issue with data that "belongs" to an existing CNA you go
to them (e.g. DWF issues an Open Source CVE, Cisco makes a statement
about product vulnerability, if someone finds a problem with that then
it's probably more useful to go to Cisco first since the DWF would
just have to contact them anyways).
3) If resolution is not achieved they move up the food chain as it
were to MITRE ultimately

Case in point: 
https://github.com/distributedweaknessfiling/cvelist/pull/3
which I need to go fix now =)


-- 

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