[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <33006C99F5A5194A9B7A7715DFA3E383EB84DCEF@ALA-MBA.corp.ad.wrs.com>
Date: Mon, 7 Mar 2016 15:28:03 +0000
From: "Radzykewycz, T (Radzy)" <radzy@...driver.com>
To: Amos Jeffries <squid3@...enet.co.nz>,
"oss-security@...ts.openwall.com"
<oss-security@...ts.openwall.com>
Subject: RE: [security-vendor] Re: Concerns about CVE
coverage shrinking - direct impact to researchers/companies
________________________________________
> From: Amos Jeffries [squid3@...enet.co.nz]
> Sent: Sunday, March 06, 2016 5:47 PM
> To: oss-security@...ts.openwall.com
> Subject: [security-vendor] Re: [oss-security] Concerns about CVE coverage shrinking - direct impact to researchers/companies
>
> On 7/03/2016 9:39 a.m., Gsunde Orangen wrote:
> > I totally agree.
> > The concern addressed by Kurt initially is fully valid (for both
> > researchers and for companies that are not on Mitre's product/sources
> > list), so a new (better: additional) solution is required.
> > However, creating a new standard independently of CVE would be too
> > disruptive and be a disservice to the software industry.
> > I'd propose to work out a new solution together with Mitre, whilst
> > keeping the CVE IDs as today.
> > Since 2014, virtually unlimited number of CVE IDs can be assigned per
> > year [1], so a solution could be that
> > - Mitre continues to assign 4 and 5 digit IDs as today
> > - 6 digit IDs are reserved for the new process (hosted outside Mitre)
> > If more than one million vulnerabilities need to be addressed in one
> > year, we could follow the rule (odd digits -> Mitre, even digits ->
> > "other process")
> > From Mitre's POC, this "other process" would become a "CNA", just with
> > its own policy and process definition, not prescribed by Mitre.
> > It would soon become clear to everyone (and all tools and products that
> > rely on CVE) where to look at for the authoritative vulnerability
> > information.
>
>
> While reading this whole thread I have been thinking along very similar
> but slightly different lines.
>
> Right now as a vendor 'security desk' I/we have the situation where we
> have to allocate an internal reference ID anyway while awaiting Mitre
> assignment. These IDs are not spread so widely as CVE in the early
> stages, so we end up with other vendors and downstream distributions not
> quite in the same discussion loop allocating their own temporary numbers
> for the same issue. And some do anyway just because thats the way they
> operate.
> (Those aware of the history might recall this was the exact same
> situation which caused CVE to be created and centralized through Mitre
> in the first place.)
>
> Having an easily self-assigned OVI number does sound nice. At least for
> use as a temporary ID that can be publicly shared before the proper
> analysis can be completed by Mitre for a CVE, which can then sub-link.
>
> AYJ
Seems like it would be a very simple change, if Mitre were willing
to do it, to have vulnerability reporters include an OVE or OVI
tracking number with every report. That way, there would be
a number to track from the initial report, and still have the
benefits of a significant review for CVE identifiers.
If Mitre were willing to make it mandatory, I think that might
be best. But even if not, that wouldn't prohibit researchers
from doing this, though it would be more ad-hoc.
Enjoy!
-- radzy
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
