[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
RE: Rough Drafts of CVE Counting Documents
Kurt,
Thanks a ton for the feedback... I very much appreciate it.
FYI... I hadn't taken into account Pascal's feedback in the comments
below, but I added Pascal's definition of vulnerability as I think it
works very well. Thanks Pascal!
> Could we add "typically requires" instead?
I added some text to the definition. Take a look and let me know if
this works for you.
> Can INC2 (Vendor acknowledgement) be expanded to include actual
> verification through a proof of concept/reproducer for example, or
> via source code examination?
I would be concerned with putting strict verification requirements at
the inclusion stage. For vendor CNAs, I think they will most likely do
some or all of this, and maybe we can insert this language here that
mentions it. However, there may also be other CNAs reading this
decision who are not the vendor or maintainer of the product/code and
assembling this data or getting it from the vendor could take time if
it happens at all. My feeling is that the inclusion steps should
emphasize speed in assigning CVE IDs as opposed to getting things
perfect up front. If a mistake is made, it can be cleaned up after the
fact. Thoughts?
> INC3.1 "demonstrated" does this mean we need a reproducer?
Similar to the above, for a vendor CNA following this it is probably
not much of an issue. For a CNA who is not the vendor or maintainer,
such as yourself, this becomes more important obviously. I think you
have said yourself that you get lots of garbage already. In my mind,
"demonstrated" means can the requester properly describe the
vulnerability and explain what it's impact is. I think if we force the
requester to provide a PoC we may be asking for too much at this stage.
As the bolded text states, this one is about trusting the researcher in
their claim to a certain extent.
> INC4: can we better define public/private? E.g. what if a medical
> device maker plans to use a CVE for an issue that they will then
> inform ever user of directly? Ditto for aerospace/SCADA/etc.
Are you saying that we should soften language now to start including
room for CVEs issues that will only be released to a limited group of
users? I know we have had these discussions in the recent past, but my
understanding was that we would wait to make this kind of change until
CVE actually brought on some of these domains where this issue will
come up.
> INC5: "CVE IDs are assigned to products that are customer-controlled
> or customer-installable." what about on premises solutions that are
> locked down? I know many medical devices, high end manufacturing, etc
> you buy it, but you don't touch it, the company tech services it.
> Ditto for other regulated items like elevators (contractually most
> elevator maintenance involves a "if anyone but us touches it, your
> warranty is totally void").
This is a really great point! This is another area that I haven't
really put much thought into and I don't think anyone else on the board
has brought up in the recent past. Outside of the "sort of" similar
idea of SaaS (and possibly other xaaS), I imagine there could be IT
products (e.g., appliances and such) produced now or in the future that
could fall into this category. Similar to the above comments though,
should we account for this in the current rules, or should we wait
until presented with this problem such as when we bring on the medical
devices domain?
> CNT4: I'd like to better define the embedded code situation, e.g.
> libxml/gzip situations (bits of those are everywhere!).
One thing that I noticed is that the decision language did not direct
the CNA to defer the report to the appropriate CNA in the case of a
shared codebase that doesn't apply to the receiving CNA (i.e., the CNA
following the decisions based on the report). Are you looking for more
process explanation in this case or maybe more examples? If you have
anything specific please feel free to pass along.
Chris
From: Kurt Seifried [mailto:kseifried@redhat.com]
Sent: Wednesday, August 24, 2016 3:55 PM
To: Coffin, Chris <ccoffin@mitre.org>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: Rough Drafts of CVE Counting Documents
Some feedback:
A vulnerability in the context of the CVE program, is code that can be
exploited, resulting in a negative impact to confidentiality,
integrity, and availability, and that requires a code change to
mitigate or address.
Some vulns are internal to the protocol and the only code change that
"fixes" it is to remove the code/functionality altogether. Could we add
"typically requires" instead? I'm worried about the intersection of
software/API vulns that will become increasingly common (more instances
of this, and people will start looking for them).
Can INC2 (Vendor acknowledgement) be expanded to include actual
verification through a proof of concept/reproducer for example, or via
source code examination?
INC3.1 "demonstrated" does this mean we need a reproducer?
INC4: can we better define public/private? E.g. what if a medical
device maker plans to use a CVE for an issue that they will then inform
ever user of directly? Ditto for aerospace/SCADA/etc.
INC5: "CVE IDs are assigned to products that are customer-controlled or
customer-installable." what about on premises solutions that are locked
down? I know many medical devices, high end manufacturing, etc you buy
it, but you don't touch it, the company tech services it. Ditto for
other regulated items like elevators (contractually most elevator
maintenance involves a "if anyone but us touches it, your warranty is
totally void").
CNT4: I'd like to better define the embedded code situation, e.g.
libxml/gzip situations (bits of those are everywhere!).
On Wed, Aug 24, 2016 at 2:19 PM, Coffin, Chris
<mailto:ccoffin@mitre.org> wrote:
All,
Attached is a new version of the CVE Counting for CNAs document. I
have made some changes to the counting decisions as well as provided
some clarifications in certain decisions based on feedback from the CVE
Team.
Chris
From: mailto:owner-cve-editorial-board-list@lists.mitre.org
[mailto:mailto:owner-cve-editorial-board-list@lists.mitre.org] On
Behalf Of Coffin, Chris
Sent: Monday, July 25, 2016 5:03 PM
To: cve-editorial-board-list
<mailto:cve-editorial-board-list@lists.mitre.org>
Subject: Rough Drafts of CVE Counting Documents
All,
Sorry for the delay, these were supposed to go out last week.
Attached is the latest marked up version of the Simplified Counting
Rules, as well as the promised very rough version of a new CVE
Vulnerability Counting for CNAs document. There is still plenty of work
to be done on this new document, but the main focus so far has been to
develop the decision trees. The included decision trees are meant to
replace the older decision trees found at
https://github.com/CVEProject/docs/blob/gh-pages/cna/application-guidance.md.
Current thinking is that the introduction of the “independently
fixable” concept obsoletes many of the older counting decisions, but
we’d be interested to hear others opinions on this. Also, the inclusion
rules actually grew a bit, but these all seem to be fairly
straightforward.
The Report Type decision is something that came up during internal
discussions and is probably new to everyone. An earlier version of the
doc didn’t have good coverage for how to count when independently
fixable resulted in No or Not Sure. The Report Type allows for common
reporting cases to be handled in a somewhat uniform way. The idea is to
handle the most common reports and the recommended counting action for
each. We are definitely interested in hearing others thoughts on this
entire counting decision, as well as the common reports and actions
that are defined.
Like I said before, this is a very early version so I am open to any
and all feedback. Thanks in advance!
Chris Coffin
The CVE Team
--
--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: mailto:secalert@redhat.com
Attachment:
CVE Counting for CNAs_v0.5.docx
Description: CVE Counting for CNAs_v0.5.docx