CVE-CNA JSON Format Proposal

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

CVE-CNA JSON Format Proposal

Booth, Harold (Fed)

Background

The CVE Automation Working Group met yesterday and one of the outcomes from that meeting was the final approval of the changes for the JSON Format that MITRE can use for exchanging CVE information with CNAs and other interested parties.

Proposed Recommendation

The working group is proposing that the format available at https://github.com/CVEProject/automation-working-group/blob/master/cve_json_schema/DRAFT-JSON-file-format-v4.md be used as the structured format for CNAs to submit CVE information effective as soon as the this recommendation has been accepted by the board.

Response Period: One Week: Ends March 28, 2017

 

Additional Considerations

While the above recommendation is currently only intended to augment the existing mechanisms for submission, the board along with MITRE will need to consider how to transition/encourage CNAs to using this mechanism in order to obtain the benefits of using a structured format.

 

Reply | Threaded
Open this post in threaded view
|

Re: CVE-CNA JSON Format Proposal

Landfield, Kent B

I am good with this. 

 

---

Kent Landfield

+1.817.637.8026

 

From: <[hidden email]> on behalf of "Booth, Harold (Fed)" <[hidden email]>
Date: Tuesday, March 21, 2017 at 8:36 AM
To: "[hidden email]" <[hidden email]>
Subject: CVE-CNA JSON Format Proposal

 

Background

The CVE Automation Working Group met yesterday and one of the outcomes from that meeting was the final approval of the changes for the JSON Format that MITRE can use for exchanging CVE information with CNAs and other interested parties.

Proposed Recommendation

The working group is proposing that the format available at https://github.com/CVEProject/automation-working-group/blob/master/cve_json_schema/DRAFT-JSON-file-format-v4.md be used as the structured format for CNAs to submit CVE information effective as soon as the this recommendation has been accepted by the board.

Response Period: One Week: Ends March 28, 2017

 

Additional Considerations

While the above recommendation is currently only intended to augment the existing mechanisms for submission, the board along with MITRE will need to consider how to transition/encourage CNAs to using this mechanism in order to obtain the benefits of using a structured format.

 

Reply | Threaded
Open this post in threaded view
|

Re: CVE-CNA JSON Format Proposal

Art Manion
In reply to this post by Booth, Harold (Fed)
On 3/21/17 9:36 AM, Booth, Harold (Fed) wrote:

> The working group is proposing that the format available at
> https://github.com/CVEProject/automation-working-group/blob/master/cve_json_schema/DRAFT-JSON-file-format-v4.md
> be used as the structured format for CNAs to submit CVE information
> effective as soon as the this recommendation has been accepted by the board.

This partially came up on today's board call:

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

Re: CVE-CNA JSON Format Proposal

Kurt Seifried-2
So the DWF will require the ASSIGNER, and ideally also the 

"source":{
"discovered_by":"name of discover",
"discovered_with":"name of parties involved",
"verification":"string",
"cna_chain":[
"string initial CNA",
"string Parent CNA",
"string root CNA"
]
},
would be automatically created as the CVE flows through the CNA chain to the DWF and then MITRE hopefully. 

On Wed, Mar 22, 2017 at 12:52 PM, Art Manion <[hidden email]> wrote:
On 3/21/17 9:36 AM, Booth, Harold (Fed) wrote:

> The working group is proposing that the format available at
> https://github.com/CVEProject/automation-working-group/blob/master/cve_json_schema/DRAFT-JSON-file-format-v4.md
> be used as the structured format for CNAs to submit CVE information
> effective as soon as the this recommendation has been accepted by the board.

This partially came up on today's board call:

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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CVE-CNA JSON Format Proposal

Art Manion
In reply to this post by Booth, Harold (Fed)
On 3/21/17 9:36 AM, Booth, Harold (Fed) wrote:

> The working group is proposing that the format available at
> https://github.com/CVEProject/automation-working-group/blob/master/cve_json_schema/DRAFT-JSON-file-format-v4.md
> be used as the structured format for CNAs to submit CVE information
> effective as soon as the this recommendation has been accepted by the board.

I consider my ASSIGNER question to be a non-accepting issue (pending
further discussion).

A couple other issues that can wait for further revisions:

1. Use of vxref for references in CVE:


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

2. Assuming CVSS-SIG produces a CVSSv3 JSON spec, include that as an
extended/optional part of the CVE spec.

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: CVE-CNA JSON Format Proposal

Art Manion
In reply to this post by Kurt Seifried-2
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 <[hidden email]
> <mailto:[hidden email]>> 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
> [hidden email] <mailto:[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CVE-CNA JSON Format Proposal

Kurt Seifried-2
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 <[hidden email]> 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 <[hidden email]
> <mailto:[hidden email]>> 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
> [hidden email] <mailto:[hidden email]>



--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: CVE-CNA JSON Format Proposal

Coffin, Chris

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.

 

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.

 

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?

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

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

 

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?

 

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

 

 

Chris

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kurt Seifried
Sent: Wednesday, March 22, 2017 3:02 PM
To: Art Manion <[hidden email]>
Cc: Booth, Harold (Fed) <[hidden email]>; cve-editorial-board-list <[hidden email]>
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 <[hidden email]> 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 <[hidden email]
> <mailto:[hidden email]>> 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
> [hidden email] <mailto:[hidden email]>



 

--

Kurt Seifried
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CVE-CNA JSON Format Proposal

Kurt Seifried


On Mon, Mar 27, 2017 at 5:01 PM, Coffin, Chris <[hidden email]> 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. [hidden email] 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: [hidden email] [mailto:[hidden email]] On Behalf Of Kurt Seifried
Sent: Wednesday, March 22, 2017 3:02 PM
To: Art Manion <[hidden email]>
Cc: Booth, Harold (Fed) <[hidden email]>; cve-editorial-board-list <[hidden email]>
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 <[hidden email]> 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 <[hidden email]
> <mailto:[hidden email]>> 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
> [hidden email] <mailto:[hidden email]>



 

--

Kurt Seifried
[hidden email]




--

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: CVE-CNA JSON Format Proposal

Kurt Seifried-2
In reply to this post by Coffin, Chris
The source container from V.3 of the JSON:

"SOURCE": {
"DATA_VERSION": "3.0",
"DISCOVERED_BY": "string",
"DISCOVERED_WITH": "string",
"VERIFICATION": "string",
"CNA_CHAIN": [
"string initial CNA",
"string parent CNA",
"string root CNA"
]
}
So I think the problem for me at least is that "source" is an array with a variety of source information things, not just a single thing per se.

On Mon, Mar 27, 2017 at 5:01 PM, Coffin, Chris <[hidden email]> 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.

 

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.

 

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?

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

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

 

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?

 

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

 

 

Chris

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kurt Seifried
Sent: Wednesday, March 22, 2017 3:02 PM
To: Art Manion <[hidden email]>
Cc: Booth, Harold (Fed) <[hidden email]>; cve-editorial-board-list <[hidden email]>
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 <[hidden email]> 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 <[hidden email]
> <mailto:[hidden email]>> 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
> [hidden email] <mailto:[hidden email]>



 

--

Kurt Seifried
[hidden email]




--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CVE-CNA JSON Format Proposal

Art Manion
In reply to this post by Coffin, Chris
On 2017-03-27 19:01, Coffin, Chris wrote:

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

Absolutely.

In a more distributed CVE world, I envision CNAs publishing CVE JSON
(...over a standard transport like RSS/Atom...) and users choosing which
feeds to consume.  MITRE and any other aggregators could consume all the
CNA feeds, hopefully automating that part of the process.

In a world of JSON blobs everywhere, knowing ASSIGNER seems to be more
important.

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: CVE-CNA JSON Format Proposal

Art Manion
In reply to this post by Kurt Seifried-2
On 2017-03-27 23:37, Kurt Seifried wrote:

> The source container from V.3 of the JSON:
>
> "SOURCE": {
> "DATA_VERSION": "3.0",
> "DISCOVERED_BY": "string",
> "DISCOVERED_WITH": "string",
> "VERIFICATION": "string",
> "CNA_CHAIN": [
> "string initial CNA",
> "string parent CNA",
> "string root CNA"
> ]
> }
>
> So I think the problem for me at least is that "source" is an array with
> a variety of source information things, not just a single thing per se.

Here, source covers discoverer/finder and CNAs involved in the assignment.


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

Here, "source" ~= "requester."

The source I'm advocating is a required reference to at least one,
original/canonical public URL.  This assumes public CVE entries are for
publicly disclosed vulnerabilities and we're OK requiring a public
reference URL.


 - Art
Reply | Threaded
Open this post in threaded view
|

RE: CVE-CNA JSON Format Proposal

Waltermire, David A.
In reply to this post by Art Manion
I am copying my co-author on ROLIE, Stephen Banghart.

> In a more distributed CVE world, I envision CNAs publishing CVE JSON (...over
> a standard transport like RSS/Atom...) and users choosing which feeds to
> consume.  MITRE and any other aggregators could consume all the CNA
> feeds, hopefully automating that part of the process.

We have been working in the IETF on a profile of ATOMPub called ROLIE to support this type of use case. The specification draft is nearing publication, so now is a good time to get more review.

The draft can be found here: https://datatracker.ietf.org/doc/html/draft-ietf-mile-rolie. Comments should be sent to the IETF MILE mailing list (mailto:[hidden email]).

Stephen and I have plans to define a ROLIE extension to address the vulnerability information type. We would welcome collaborators from the CVE board to help us on creating this draft. Please let me know if you're interested.

Regards,
Dave
Reply | Threaded
Open this post in threaded view
|

Re: CVE-CNA JSON Format Proposal

Mark J Cox
In reply to this post by Kurt Seifried-2
>> On 3/21/17 9:36 AM, Booth, Harold (Fed) wrote:
>>> The working group is proposing that the format available at
>>> https://github.com/CVEProject/automation-working-group/blob/
>> master/cve_json_schema/DRAFT-JSON-file-format-v4.md
>>> be used as the structured format for CNAs to submit CVE information
>>> effective as soon as the this recommendation has been accepted by the
>> board.

I did a quick parse of the OpenSSL xml data to see how close we are to be
able to automatically create the right format.  Output for CVE-2017-3731
attached.  But is this right or close enough?  It's not clear yet if

* ID or CVE_ID (docs have both)
* if version_data is okay when listing all affected versions
* if the unicode encoding of the original utf-8 credit worked out okay
* may need to parse the description to remove the \n's
* how to define the namespace of the impact word (i.e. this is "moderate"
by (url defining what moderate means to this vendor)

Cheers, Mark

openssl-CVE-2017-3731.json (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: CVE-CNA JSON Format Proposal

Booth, Harold (Fed)
In reply to this post by Art Manion
Art,

  To follow-up on this have your concerns in the ensuing conversation been addressed enough? Or what specifically would you like to see in order to accept the proposal?

Regards,

-Harold

-----Original Message-----
From: Art Manion [mailto:[hidden email]]
Sent: Wednesday, March 22, 2017 3:35 PM
To: Booth, Harold (Fed) <[hidden email]>; [hidden email]
Subject: Re: CVE-CNA JSON Format Proposal

On 3/21/17 9:36 AM, Booth, Harold (Fed) wrote:

> The working group is proposing that the format available at
> https://github.com/CVEProject/automation-working-group/blob/master/cve
> _json_schema/DRAFT-JSON-file-format-v4.md
> be used as the structured format for CNAs to submit CVE information
> effective as soon as the this recommendation has been accepted by the board.

I consider my ASSIGNER question to be a non-accepting issue (pending further discussion).

A couple other issues that can wait for further revisions:

1. Use of vxref for references in CVE:


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

2. Assuming CVSS-SIG produces a CVSSv3 JSON spec, include that as an extended/optional part of the CVE spec.

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: CVE-CNA JSON Format Proposal

Art Manion
On 4/3/17 2:15 PM, Booth, Harold (Fed) wrote:

> To follow-up on this have your concerns in the ensuing conversation
> been addressed enough? Or what specifically would you like to see in
> order to accept the proposal?

Making ASSIGNER mandatory addresses my concern and I'd accept the proposal.

These other two issues can wait for future discussion and revision:

> 1. Use of vxref for references in CVE:
>
> https://github.com/FIRSTdotorg/vrdx-sig-vxref-wip/blob/master/vxref/schema/vxref_schema_03.json
>
> 2. Assuming CVSS-SIG produces a CVSSv3 JSON spec, include that as an extended/optional part of the CVE spec.

In talking to George about the JSON schemas and Node CVE request form
he's working on, another issue came up.  This may be irrelevant or
something specific to JSON (and not the CVE schema).  Is there any
concern or need to specify that CVE JSON is one blob/record per file?
This might get into the transport question and ATOMPub/ROLIE.

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: CVE-CNA JSON Format Proposal

Art Manion
In reply to this post by Waltermire, David A.
On 3/28/17 11:17 AM, Waltermire, David A. (Fed) wrote:

>> In a more distributed CVE world, I envision CNAs publishing CVE JSON (...over
>> a standard transport like RSS/Atom...) and users choosing which feeds to
>> consume.  MITRE and any other aggregators could consume all the CNA
>> feeds, hopefully automating that part of the process.
>
> We have been working in the IETF on a profile of ATOMPub called ROLIE
> to support this type of use case. The specification draft is nearing
> publication, so now is a good time to get more review.
>
> The draft can be found here:
> https://datatracker.ietf.org/doc/html/draft-ietf-mile-rolie. Comments
> should be sent to the IETF MILE mailing list (mailto:[hidden email]).
>
> Stephen and I have plans to define a ROLIE extension to address the
> vulnerability information type. We would welcome collaborators from
> the CVE board to help us on creating this draft. Please let me know
> if you're interested.

I'd suggest this as an item for the automation group to take up.

 - Art