Convergence vs. multiple data entries

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

Convergence vs. multiple data entries

Kurt Seifried
So we will have situations where a CVE is issued with some data (at a
minimum the description, affected, reference URLs, etc.) created by
the CNA that issued it, and a third party (another CNA, a non CNA
entity like a researcher, a vendor, etc.) may want to change that data
(e.g. the description mentions affected versions and a researcher
wants to add more). We have two main choices:

1) get the entities to cooperate and come up with a change (or not) to the data
2) allow the third party data to be added, with source information (so
e.g. you have vendor affected data from the vendor, and vendor
affected data from a third party researcher, sorting it out is left as
an exercise to the reader).

I would suggest we want to encourage #1, and possibly enforce it for
some of the data (e.g. the global description), but that there is also
value in allowing competing statements (e.g. vendor affects).

Some concerns with #1: with an original CVE this is "Easy", talk to
the CNA. But what do we do in a case like CVE-2009-3555 where
potentially a dozen vendors want to muck in? Does anyone who
previously had input on the change need to be consulted for future
changes, or does the original CNA "own" that CVE and we send everyone
to them simply?

Some concerns with #2: some data won't be that painful to have
multiple different sets of (e.g. impact) but some data will become
very confusing if there are multiple entries, especially if they
conflict (e.g. flaw type, it's supposed to be a single thing, if
someone puts buffer overflow, and someone else puts buffer
underread... er....) and of course the global description, I think
like the Highlander there can only be one, it's an assumption all the
tools have made (I know I did).

So in the short term we need to decide:

Do we allow convergence of the data? (I think the obvious answer is yes)

Do we allow multiple sets of data? (I think the answer is... maybe,
depends on what it is/who's doing it, so if we decide yes then doing
this becomes contingent  ont he business rules stuff from the
automation working group). Also we need to then rejigger the JSON
format a bit (and I would suggest major version # bump to 5 since it
won't be backwards compatible).

So we also need to define the data that we really care about (e.g. we
won't allow multiple CVE #'s in... right? what about requester?
description?) and which we care less about (I would suggest anything
data and not directly not at the root level is fair game..., so e.g.
affected:* and adding reference URLs for example).


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: Convergence vs. multiple data entries

Art Manion
On 12/13/17 4:19 PM, Kurt Seifried wrote:

> Do we allow convergence of the data? (I think the obvious answer is yes)


> Do we allow multiple sets of data? (I think the answer is... maybe,

My idea is to allow essentially comments or changelog entries on a CVE record.  Outside of what git records in PRs, something that is part of the CVE entry.

For example:

CERT/CC publishes a vulnerability and writes the corresponding CVE entry, submits via github, entry goes into CVE corpus and on to NVD.

Red Hat disagrees with any part of the entry and wants to make a change.  There's a facility to add a comment to the entry saying: "On $date, Red Hat says:  The CVSS score is wrong, here are two new references, and the version info in the description should be updated."  Depending on the nature of the comment, DISPUTED status is set.

Assuming such a comment can be added with little or no friction (and here is part of the business rules discussion, who can add comments, with or without review?), CVE consumers now have new information.  The record hasn't been changed yet.  CERT/CC responds, Red Hat responds, someone else throws in, and the public comment log has provided a path to allow convergence.  In this example, CERT/CC is a responsive CNA, considers and agrees with the comments, and updates the CVE entry.

When reading the original CVE entry and decide I never listen to what Red Hat says, I can ignore the comment.  If I think Red Hat is right, I can act on the comment even before the entry is converged/updated.

And if there's no convergence, maybe some other rules or review come into play, and a CNA upstream from CERT/CC decides to make changes.  Or the comment log sits there, documenting the dispute.

I need to think/talk more about the multiple data containers idea, but the lazy part of my brain only hears "hey, added complexity for unclear reasons."

  - Art