RE: [security-vendor] Re: [oss-security] Concerns about CVE coverage shrinking - direct impact to researchers/companies

["Radzykewycz, T (Radzy)" <radzy () windriver com>]

________________________________________
> From: Amos Jeffries [squid3 () treenet co nz]
> Sent: Sunday, March 06, 2016 5:47 PM
> To: oss-security () lists 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