dispute resolution

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

dispute resolution

Art Manion
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
Reply | Threaded
Open this post in threaded view
|

RE: dispute resolution

Coffin, Chris
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: [hidden email] [mailto:[hidden email]] On Behalf Of Art Manion
Sent: Wednesday, December 6, 2017 9:38 AM
To: cve-editorial-board-list <[hidden email]>
Cc: Carsten Eiram <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|

Re: dispute resolution

Kurt Seifried
In reply to this post by Art Manion
On Wed, Dec 6, 2017 at 8:38 AM, Art Manion <[hidden email]> 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: [hidden email]