Re: CVE-CNA JSON Format Proposal

[Kurt Seifried <kseifried@redhat.com>]

On Mon, Mar 27, 2017 at 5:01 PM, Coffin, Chris <ccoffin@mitre.org> wrote:

First, some thoughts on definitions. I’m not sure if everyone is speaking the same language in this case.

 

ASSIGNER: The organization or individual who assigns a CVE ID to a vulnerability. The organization may or may not have discovered the vulnerability. By default, a CVE CNA would be the ASSIGNER whenever they used a CVE ID from their allocated block. DWF Mentors could be a special exception.

Ah to be clear there are three main options for "where" the CVE comes from:

1) main DWF pool - "retail CVE request", DWF CVE-Mentor can sign off on CVE request, this is then passed to the DWF, the advantage being assignment can happen quickly because the request is signed off on (and thus in theory at least it is correct) 

2) DWF CNA pool - "CNA using CVE Mentor" request, e.g. an Open Source project has a dedicated CVE Mentor(s), and has grown enough to get a CVE block for themselves (e.g. Kubernetes in the near future I hope) (so CVE from that projects pool) 

3) "CVE Mentor as CNA", so a CVE Mentor can also have a CVE block (e.g. Josh Bressers), and assign CVE's for things that don't have an associated CNA. (so CVE from the CVE Mentors personal pool) 

In all 3 cases the ASSIGNER would be the CVE Mentor who actually signed off on the request, and in the case of #2 the CVE pool being used could be different from the CVE Mentors own personal pool (e.g. if Larry, a person CNA signed off on a request for Kubernetes once Kubernetes had their own CVE block). 

 

Essentially whoever signs off on the JSON/request being "correct" is the ASSIGNER, also note this could be an organization role (e.g. secalert@redhat.com for example) as opposed to a unique individual. 

 

SOURCE: The organization or individual who reports the details of a vulnerability and is requesting a CVE ID. The SOURCE would report the details and request the CVE ID though a CNA, or in some cases may be the CNA themselves if found internally. Also, this would match up with the discoverer of the vulnerability.

The SOURCE container has a couple of fields, e.g.:"SOURCE": {

    "DATA_VERSION": XYZ,

    "DISCOVERED_BY": XYZ,

    "DISCOVERED_WITH": XYZ,

    "VERIFICATION": XYZ,

    "CNA_CHAIN": [

      "string initial CNA",

      "string parent CNA",

      "string root CNA"

    ]

  }

so the CNA_CHAIN is, well, exactly that. The DISCOVERED_BY would be data about that entity, etc. 

 

 

For the ASSIGNER, MITRE already has this information today based on who is providing the details. We would have no issue in suggesting that the ASSIGNER be required within the minimal format. The reasoning could include the bulleted list below.

 

-          For the purposes of the current use case, CNAs sharing JSON data with MITRE means that the ASSIGNER would always be the CNA. Right?

From the DWF perspective: no. A CNA is simply defined as: an entity that has agreed to play by the CNA rules, and is a CVE mentor (e.g. a person like Larry Cashdollar or Josh Bressers) or has one or more CVE Mentors (can be dedicated to them, or shared) to sign off on CVE requests, in other words they are or have someone trained in CVE assignments. They would almost always have their own CVE block as well (but this is not necessarily a requirement). 

 

-          MITRE is already keeping track of email addresses for CNAs now, but wouldn’t think it’d be terribly difficult to have CNAs include both CNA name and email in any submissions going forward.

To be clear when you say CNA name you mean the name of the entity, which could b a name like Larry Cashdollar, or the entity, like "Red Hat"?

 

-          As suggested by Kurt, the ASSIGNER information could be automatically created for CNAs in whatever tools they use for submission

 

The SOURCE of a CVE would also be interesting to obtain, but we may not always get this since some SOURCES may choose to remain anonymous. Also, in the current use case of CNA submissions to MITRE, I don’t see this as a requirement at the moment, though i am certainly open to others opinions. I’m not sure that we want to actually list SOURCE emails or names as this could get difficult to maintain in some cases (e.g., disputes over who discovered a vulnerability, etc.).

So the DISCOVERED_BY for example could be anonymous for sure. But the CNA_CHAIN data for example should always be correct and complete (of course I can imagine corner cases where the ultimate CNA wants/needs to remain anonymous, but the CVE ID would sort of be a giveaway, so I guess they'd have to do a request via the DWF to be truly anonymous). 

 

 

One thought is that we could simply just try to understand whether or not the SOURCE is the affected software maintainer vs someone else. The benefit to requesting this information would be in providing a kind of validity check for the vulnerability and its details. For the MITRE CNA, if the vulnerability was provided by a CNA then there is a certain level of trust. Whereas a vulnerability reported by a random researcher to the MITRE web form might not have that same level of trust. Thoughts?

That would be the advantage of the CNA_CHAIN data, you know the CNA that assigned it, and can easily determine if it's their own or someone elses based on their declared data.

 

 

Art: Are you ok with moving forward if we just make sure to include ASSIGNER as part of the minimum JSON format?

 

 

Chris

 

 

From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Kurt Seifried
Sent: Wednesday, March 22, 2017 3:02 PM
To: Art Manion <amanion@cert.org>
Cc: Booth, Harold (Fed) <harold.booth@nist.gov>; cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: CVE-CNA JSON Format Proposal

 

Well in theory I would say yes to both because:

 

the source is created automatically, e.g. each CNA in the chain applies their source.

 

As for assigner, in the DWF world we're using signed git commits and/or signed JSON files (so you can create a JSON file and sit on it for embargoed situations and then submit it for automated processing), so it MUST be signed by someone who is a valid CVE mentor (cause we need proof of where it came from), so again that data is automatically harvested/added to the entry (once we get automation). 

 

On Wed, Mar 22, 2017 at 1:45 PM, Art Manion <amanion@cert.org> wrote:

On 3/22/17 3:31 PM, Kurt Seifried wrote:
> So the DWF will require the ASSIGNER, and ideally also the
>
> "source":{

Same questions then for source.  Should ASSIGNER and source be required
in the minimum CVE entry?

What I'm really interested in is who assigned the entry (and is likely
responsible if there are issues) and the (best reasonably available)
source public reference.

Maybe what I'm thinking of is a separate or special case of
"references", or that a minimum entry must contain at least one public
source "references" for the vulnerability.

 - Art

> On Wed, Mar 22, 2017 at 12:52 PM, Art Manion <amanion@cert.org
> <mailto:amanion@cert.org>> wrote:
>
>     Should ASSIGNER be required as part of the minimal example?  I'd say
>     yes.
>
>     ASSIGNER is currently an email address, should it be a CNA name?  I'd
>     say maybe, someone would otherwise have to map email addresses to CNAs.
>
>      - Art
>
>
>
>
> --
> Kurt Seifried
> kurt@seifried.org <mailto:kurt@seifried.org>

 

--

Kurt Seifried
kurt@seifried.org

--

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