Ø
DWF CNA's MUST declare what they cover when they register.
My thought when we discussed this was that a granular list of covered products from a vendor/maintainer would be the exception and not the norm. In other words, most vendors
would cover all of their products. I think we talked about Google, Apache, and one other if I recall correctly.
IMO… if the vendor wishes to only cover a subset of their products, the burden should be on them to keep the CVE program updated on what that subset of products is. We may
even want them to provide the “Not covered” list since it would make it easier to quickly identify when another CNA should intervene and provide coverage. This latter list would be useful for steps 1 and 2 listed by Kurt, i.e., if the product was from Vendor
X and is not in either list, check with Vendor X for clarification as it could be a new product or something they missed.
Chris
From: Kurt Seifried [mailto:kseifried@redhat.com]
Sent: Monday, December 19, 2016 3:20 PM
To: Landfield, Kent B <kent.b.landfield@intel.com>
Cc: Coffin, Chris <ccoffin@mitre.org>; jericho <jericho@attrition.org>; cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: what text is being sent to researchers re: OSS assignments?
My take on this is simple:
DWF CNA's MUST declare what they cover when they register.
DWF CNAs MUST provide a contact method in the form of email or a proper bug tracker
DWF CNA's MUST keep their declaration up to date if they STOP CVE coverage for something they previously covered.
DWF CNA's CAN (not MUST) keep the declarations up to date if they START assigning CVEs for something they cover
If I get a CVE request for something that is part of a CNA and it is NOT explicitly covered I will either:
1) Assign a CVE (to bad, the CNA should have updated their information)
2) Ask the CNA if they cover this and await a reply, if they cover it they can then take it (and the info is updated), or we go back to option #1 and the DWF assigns it.
I suspect most places won't drop CVE coverage that often, and there's no point making them update what they cover until it becomes an issue. Essentially making this driven by CVE requests rather than "let's have a perfect database of coverage
that is magically up to date" (it never will be).
On Mon, Dec 19, 2016 at 2:01 PM, Landfield, Kent B <kent.b.landfield@intel.com> wrote:
https://cve.mitre.org/cve/data_sources_product_coverage.html#products
Is this not granular enough at present? Are you looking for more precise info? Because if you are that could be
a nightmare to manage as vendors introduce new products, EOS and EOL old products, etc. And for large companies, I am talking about internal management as well...
Maybe the exceptions would be easier if you are looking for specifics. Vendor X supports all their products except
for products BBBXXXCCC and AAAVVVDDD...
+1.817.637.8026
What will help is having a list of CNAs that declare what they cover, that data can be consumed easily so if someone search/starts typing you can provide a suggestion (e.g. apache).
On Mon, Dec 19, 2016 at 12:54 PM, Coffin, Chris <ccoffin@mitre.org> wrote:
> Yes, this is basically my point. The wording of the blog I quoted suggests that the text MITRE is sending may not jibe with "check these links first". It sounds like he was told
"anything OSS go to DWF". Thus my question for clarification.
A CVE team analyst directs the request to the appropriate CNA as needed. We do have some template text that we send out for requests that should be handled by the DWF CNA, but it's just basic info how to submit a request to them. In addition, we have begun
providing the requester the text of their CVE web form request so that they don't need to retype everything on the DWF side.
Note that the CNA list has grown and the proper routing for a request will only get more complicated. As Kent suggested earlier, we have spoken about moving towards a landing page where we could implement some form of automation that handles this routing in
a timely and consistent manner (e.g., if Product == Microsoft, send request to
secure@microsoft.com, if open_source == True AND Product != 'Apache', send request to DWF, etc.).
If you have any suggestions please pass them along.
Chris
-----Original Message-----
From:
owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of jericho
Sent: Monday, December 19, 2016 12:24 PM
To: Landfield, Kent B <kent.b.landfield@intel.com>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: what text is being sent to researchers re: OSS assignments?
Importance: High
On Mon, 19 Dec 2016, Landfield, Kent B wrote:
: Couple points of reference....
:
:
https://cve.mitre.org/cve/data_sources_product_coverage.html#products
: https://cve.mitre.org/cve/cna.html
Yes, this is basically my point. The wording of the blog I quoted suggests that the text MITRE is sending may not jibe with "check these links first". It sounds like he was told "anything OSS go to DWF". Thus my question for clarification.
: On 12/19/16, 8:13 AM, "owner-cve-editorial-board-list@lists.mitre.org on behalf of Landfield, Kent B" <owner-cve-editorial-board-list@lists.mitre.org
on behalf of kent.b.landfield@intel.com> wrote:
:
: Can we please post this to the appropriate place? If you have an
: issue with this decision that the Board actively discussed, please as
: the question there. There is no reason to cross-post every message to
: both lists. This was a swim lane issue discussed by the Board and also
: discussed at the face-to-face meeting we had in Rockville, MD in
: November.
Not questioning the decision, questioning how this was implemented in the context of CVE consumers requesting an ID. To me this is a Board issue and impacts the CNA, so I posted to both lists.
--
--
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
--
--
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
|