Simplified Draft Counting Paper for CVE Editorial Board Review

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

Simplified Draft Counting Paper for CVE Editorial Board Review

Common Vulnerabilities & Exposures

Dear CVE Editorial Board Members –

 

Please find attached to this note a copy of the draft CVE Simplified Counting Paper. The paper was originally prepared as an internal piece to help the CVE analysts orient their thinking, and we thought that it would be useful to share it with the Board as background before the Board meeting Wednesday afternoon.

 

Please forward any questions or comments to this list.

 

Regards,

The CVE Team

 


CVE Counting - Draft for comment - 2016-03-22.docx (344K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Simplified Draft Counting Paper for CVE Editorial Board Review

Art Manion
On 2016-03-28 12:24, Common Vulnerabilities & Exposures wrote:

> Please find attached to this note a copy of the draft CVE Simplified
> Counting Paper. The paper was originally prepared as an internal piece
> to help the CVE analysts orient their thinking, and we thought that it
> would be useful to share it with the Board as background before the
> Board meeting Wednesday afternoon.

Comments added.

At a high level, even more tolerance for assignment criteria, increased
assignment (by MITRE and/or CNAs) is necessary to keep up with reality.
 A direct affect is an increased need for split/merge/reject cleanup.

Perhaps, vaguely reminiscent of CAN/CVE days, CVE entries get a flag
that can be set by MITRE or a CNA to distinguish "claimed
vulnerabilities, report looks plausible, public reference" from "vendor
acknowledged, or otherwise substantiated claim, public reference."

 - Art

CVE_counting_cert.docx (376K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Simplified Draft Counting Paper for CVE Editorial Board Review

Kurt Seifried

On Wed, Mar 30, 2016 at 3:07 PM, Art Manion <[hidden email]> wrote:
On 2016-03-28 12:24, Common Vulnerabilities & Exposures wrote:

> Please find attached to this note a copy of the draft CVE Simplified
> Counting Paper. The paper was originally prepared as an internal piece
> to help the CVE analysts orient their thinking, and we thought that it
> would be useful to share it with the Board as background before the
> Board meeting Wednesday afternoon.

Comments added.

At a high level, even more tolerance for assignment criteria, increased
assignment (by MITRE and/or CNAs) is necessary to keep up with reality.
 A direct affect is an increased need for split/merge/reject cleanup.

Perhaps, vaguely reminiscent of CAN/CVE days, CVE entries get a flag
that can be set by MITRE or a CNA to distinguish "claimed
vulnerabilities, report looks plausible, public reference" from "vendor
acknowledged, or otherwise substantiated claim, public reference."

 - Art

One thing to keep in mind I think is that at a high level CVE stands for "Common Vulnerabilities and Exposures", so obviously it's used to track vulns, but on the other side CVE is also heavily used to track remediation, be it software updates, workarounds, compensating controls, whatever. A good example of this is the search results:


I'm not sure we need to cover it much beyond the "incomplete fix == another CVE", thoughts/comments?

--
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: Simplified Draft Counting Paper for CVE Editorial Board Review

jericho
In reply to this post by Common Vulnerabilities & Exposures

On Mon, 28 Mar 2016, Common Vulnerabilities & Exposures wrote:

: Please find attached to this note a copy of the draft CVE Simplified
: Counting Paper. The paper was originally prepared as an internal piece
: to help the CVE analysts orient their thinking, and we thought that it
: would be useful to share it with the Board as background before the
: Board meeting Wednesday afternoon.
:
: Please forward any questions or comments to this list.

Attached a copy with Track Changes on, and left comments throughout the
document. There are quite a few things that are not clear and only add
confusion or debate, rather than clarifying a point. Further, this
document would be better off if you could have a technical editor give it
a once-over.

Brian

CVE Counting - Draft for comment - 2016-03-22-BM.docx (358K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Simplified Draft Counting Paper for CVE Editorial Board Review

jericho
In reply to this post by Art Manion
On Wed, 30 Mar 2016, Art Manion wrote:

: At a high level, even more tolerance for assignment criteria, increased
: assignment (by MITRE and/or CNAs) is necessary to keep up with reality.
:  A direct affect is an increased need for split/merge/reject cleanup.

This is a critical comment, and understated.

All of the proposals do absolutely nothing to address the fundamentl
problem CVE faces. All of the proposed changes are the proverbial
deck-chair arranging on a sinking effort.

It is truly difficult to comprehend how so much time can be spent on
pedantic policy like this while ignoring the bigger problem. I mean, I am
all for VDB pedantry, and Steve Christey and I had some epic threads and
conversations along those lines. But this isn't a case where changing
the minutiae of the current policy will fix anything, at all.
Reply | Threaded
Open this post in threaded view
|

RE: Simplified Draft Counting Paper for CVE Editorial Board Review

Common Vulnerabilities & Exposures
In reply to this post by jericho
Brian, Art -

Thank you very much for your review and thoughts on the draft counting paper. You bring up some good points; this paper will be on the agenda for the next Editorial Board meeting in 2 weeks. In the meantime, we encourage other members of the Board to comment and critique. It will facilitate the discussion at the next meeting.

Regards,

The CVE Team

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of jericho
Sent: Friday, April 01, 2016 4:58 PM
To: cve-editorial-board-list <[hidden email]>
Subject: Re: Simplified Draft Counting Paper for CVE Editorial Board Review
Importance: High


On Mon, 28 Mar 2016, Common Vulnerabilities & Exposures wrote:

: Please find attached to this note a copy of the draft CVE Simplified
: Counting Paper. The paper was originally prepared as an internal piece
: to help the CVE analysts orient their thinking, and we thought that it
: would be useful to share it with the Board as background before the
: Board meeting Wednesday afternoon.
:
: Please forward any questions or comments to this list.

Attached a copy with Track Changes on, and left comments throughout the document. There are quite a few things that are not clear and only add confusion or debate, rather than clarifying a point. Further, this document would be better off if you could have a technical editor give it a once-over.

Brian
Reply | Threaded
Open this post in threaded view
|

Re: Simplified Draft Counting Paper for CVE Editorial Board Review

Pascal Meunier
In reply to this post by Kurt Seifried
The "incomplete fix == another CVE" mode of operation makes sense to me
as the code base has changed, and presumably also the mistakes and
assumptions made also changed, which is interesting academically and
from a teaching perspective.  The repeated attempts to fix something are
interesting to me, and using different CVEs makes that easier to follow
and examine.  I believe this is fine and helpful.  Additional coverage
and linkage would be more the province of databases based on the CVE, or
the CWE.

Pascal

On 03/30/2016 08:09 PM, Kurt Seifried wrote:

> One thing to keep in mind I think is that at a high level CVE stands for
> "Common Vulnerabilities and Exposures", so obviously it's used to track
> vulns, but on the other side CVE is also heavily used to track remediation,
> be it software updates, workarounds, compensating controls, whatever. A
> good example of this is the search results:
>
> http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=incomplete+fix+for
>
> I'm not sure we need to cover it much beyond the "incomplete fix == another
> CVE", thoughts/comments?
>
> --
> 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]
>