Require reporting of which reserved CVE IDs have and have not been assigned to a vulnerability

[EvansJonathan]

GOAL: Increase transparency? CHANGE: Helps differentiate between what are actually assigned vs. those that are reserved and (maybe) unused. The Primary CNA should be publishing these summaries. The Root CNAs must provide the Primary CNA these data. "Allocated" vs. "Reserved"?

Primary CNA will send periodic reports to the Root/Sub CNAs indicating what CVE IDs we have observed/had reported to us that have not been published. One other option is a query on demand vs an email notification

[EvansJonathan]

[Manion 2017-07-11] I question how much effort to put into tracking reserved vs. assigned. We have plenty of IDs now, if bunches go unassigned, so be it. What is critical is that IDs that go public (are assigned) are populated, ideally by the assigning/responsible CNA. So I understand the need for reports about public IDs that aren't populated. But for reports about what is reserved/unused, I don't see a strong need. If the reporting is easy/low cost, I see no harm.

[kurtseifried]

DWF simply assigns a block that is used in multiple years (unless clawed back), e.g.

https://github.com/distributedweaknessfiling/DWF-CNA-Registry/blob/master/DWF-CNA-2017.csv

perhaps we need language around informing parent CNA and ultimately the root CNA (MITRE) about active reservations/etc.

[dadinolfi]

I'm not sure of all the use cases for knowing the number of assigned-but-unpublished CVE IDs per CNA or in the program as a whole.

One use case for knowing which CVE IDs have been assigned comes when someone misuses a CVE ID. For example, if a blog posts that the vulnerability they discovered was CVE-2019-123x, and that ID was not assigned to that vulnerability, we need to resolve the misuse. If the CVE ID wasn't assigned or reserved for anyone, we can just reject the CVE ID (or, if the issue is legitimate, allow it to be assigned to that issue and chide the publisher). If the CVE ID was already assigned, just rejecting the CVE ID would put a burden on the owner of that CVE ID since they would have to communicate the new CVE ID to anyone involved in the pre-disclosure process. If it was reserved but not assigned, the owner can easily exchange it for another unused CVE ID, and we can reject the misused one.

Right now, when we have this kind of problem, we reach out to the CNA and ask if the misused CVE ID has been assigned or not. If it has not been, we will typically reject it. If it has been assigned, and changing the CVE ID for the issue is burdensome, we will work out a solution that serves the CNA and the community for the best on a case-by-case basis.

The question is, as Art Manion asked, what is the effort involved in keeping the assigned list up-to-date versus the effort in reaching out to CNAs on a case-by-case basis in this scenario.

Another scenario serves risk managers. If they know that Microsoft, say, has 100 new vulnerabilities being announced soon (since we start publishing that they have assigned 100 out of 1000 reserved CVE IDs), they can be prepared for a more significant response to the next patch release compared to if they only had 10 out of 1000 assigned. It gives risk managers some insight into the pipeline.

But do all CNAs want that insight available to the general public?

What other use cases might there be where one would utilize the assigned-but-unpublished number?

[david-waltermire]

Could this be handled through use of a shared directory that tracks block assignments to CNAs, and actual assignments of CVE IDs by CNAs? Web APIs can be used to allow for easy integration into any CNAs workflow. Information in the directory can be made public supporting some of the use cases above.

[ghost]

@david-waltermire-nist between what e.g. the DWF does (listing which CNAs have which blocks) and actually registering CVEs when RESERVED we would have all that data. If someone wants to stick an API up for CNAs/blocks I'd be happy to feed data to it. Perhaps MITRE @dadinolfi should consider hosting this data (cnalist?) if we start requiring it.

[dadinolfi]

Full CNA list is here http://cve.mitre.org/cve/request_id.html

It doesn't include Sub-CNAs under the DWF or JPCERT/CC, but we could include that.

[ghost]

@dadinolfi feel free to pull from the DWF repo and generate it.

[dadinolfi]

Suggestion: One use case we are certain about is the need for CNAs to provide their unused CVE IDs for the previous year each year. To make this a requirement, we add 2.3.4:

4. Upon request by the Primary CNA or by the CNA’s Root CNA, provide a list of unused CVE IDs that have been reserved by the CNA. (This will typically be done on a yearly basis for the previous year's CVE ID reservations.)

[ghost]

@dadinolfi wouldn't this be generally fixed by reporting the CNAs/blocks assigned to them (ala https://github.com/distributedweaknessfiling/DWF-CNA-Registry/blob/master/DWF-CNA-2017.csv the CNA blocks and the CNA record: https://github.com/distributedweaknessfiling/DWF-CNA-Registry/blob/master/CNA-Registry/000000/cna-4.json) then the reporting can be automated (simply compare the blocks to what is in the CVE database

[ghost]

I guess we would need some reporting on CVE's assigned and not yet public, or public and not uploaded to the CVE database (partly we can solve the public case by trolling google perhaps?)

[dadinolfi]

Not every CNA will want to indicate which of their reserved CVE IDs have been assigned to a CVE ID in real time, especially if that runs counter to their own embargo processes. The DWF doing this is great, but I'm not sure we should make that much transparency a requirement. What do other's think?

Regarding the assigned-but-not-public and public-but-not-populated issue, this is an on-going problem CVE faces, and how best to gather that information is a bigger topic. It is one worth discussing, though I'm not sure we should do so here.

[ghost]

On Thu, Oct 5, 2017 at 12:14 PM, Daniel Adinolfi notifications@github.com wrote:

Not every CNA will want to indicate which of their reserved CVE IDs have been assigned to a CVE ID in real time, especially if that runs counter to their own embargo processes. The DWF doing this is great, but I'm not sure we should make that much transparency a requirement. What do other's think?

I'm not saying it has to be real time, simply that people publish their CVE blocks if they are a CNA. They would ideally set the CVE as RESERVED (which I do, mostly so I don't accidentally re-use a CVE twice, like I have in past... ) and push that to MITRE, but that's not required of course (and yes for smaller CNAs with a single product for example that could cause a kerfuffle which they may want to avoid).

Regarding the assigned-but-not-public and public-but-not-populated issue, this is an on-going problem CVE faces, and how best to gather that information is a bigger topic. It is one worth discussing, though I'm not sure we should do so here.

Well I think the simplest thing is, is this a real problem? Assuming CNAs behave and observe the "push CVEs to MITRE once public" reliably we would in theory have only a minimal set of embargoed (assigned but not yet public) CVEs for most CNAs (even DWF which will end up doing a lot of embargoed CVEs should only have a dozen or two outstanding at the most at any time really). Perhaps a good idea is to wait until end of Jan 2018 and see what the state is for CNA blocks vs. what is in the MITRE database.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/CVEProject/docs/issues/37#issuecomment-334548265, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDVH24Ul7b_xSbPIjWAJcs2s46VRu6Hks5spRyWgaJpZM4OkOW3 .

--

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