[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVE for hosted services

On 2017-02-24 17:30, jericho wrote:

> Do NOT, uner any cicumstance, use 'CVE' as part of the ID scheme. 
> There is 
> absolutely no logical or beneficial reason to do so.

I had assumed not changing the scheme, but hadn't given it a lot of
thought.  Not sure I see a logical or beneficial reason to create a
separate "service" scheme, but I'm not necessarily against it either.

> - CVE supported two prefix schemes for a decade (CVE and CAN).

There was a reason for two schemes, the world changed, and CVE evolved.
I recall it being cumbersome at best (although it was probably
worthwhile in the early years of CVE).

What does CAN/CVE mean in this discussion?

> - Many orgs will not want to track online services, and mixing them 
> will 
>   make that very painful for 'coverage [metrics|percentage]' etc.
> - Some orgs may be more interested in cloud/service offering tracking 
>   (e.g. companies that exist for cloudy services themselves)

Seems reasonable.  Is there another way to flag "service" vulns?
Keeping in mind the continued blurring of product and service.  Not a
reserved block of IDs.

> - For the countless vuln tourists (both individual and companies) 
> that do 
>   yearly stats entirely based on CVE and not understanding CVE at 
> all, 
>   this will forever make ALL stats they generate entirely worthless. 
> I 
>   mean, they are already worthless, but this will make it more so.

Counting is broken, for many reasons, which you know better than most.
That's as much a function of the nature of vulnerabilities as it is the
effort anybody puts in to counting.

Identification, identification, identification.

> - Did I mention there is no logical reason to mix them under a 
> unified CVE 
>   identifier? =)

You did, but I throw the tautology flag :)

 - Art
Page Last Updated or Reviewed: February 28, 2017