[
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
