Re: CVE for hosted services

[Pascal Meunier <pmeunier@cerias.purdue.edu>]

I'm afraid that the description of the entries, for issues on services
like facebook.com, would be typically very vague and unverifiable.  I'm
rather annoyed by existing entries that read like "a problem in X, but
different from CVE-1234-5678 and CVE-1234-7890".  What is the issue?
What lessons could be learned from this?  What should we teach not to
do, or teach to do better?  No idea.

Pascal

On Wed, 2017-02-22 at 15:38 -0500, Art Manion wrote:
> Some thoughts based on today's board meeting.
> 
> I consider CVE's primary purpose as identification.  There's a good 
> bit
> of work that goes into just doing identification.  Information
> sharing/publishing/cataloging takes work too.  Identification/naming 
> is
> infrastructural and enables many additional functions.
> 
> "Vulnerability" is often abstract and subjective.
> 
> Software and tech change quickly.  The definition/boundary of what 
> "we"
> "collectively" call vulnerabilities evolves.  The current discussion 
> (1)
> started around the idea of assigning CVE IDs to web/service
> vulnerabilities, which I consider natural evolution.
> 
> Lots of discussion around the definition/boundary of "vulnerability."
> 
> Also a separable discussion (2) about the use of CVE IDs for
> internal-only, non-public issue tracking.  Could an organization use 
> CVE
> to track vulnerabilities with no expectation of publishing or sharing?
> Does an organization want to?
> 
> To try to narrow down the services discussion (1), I'll suggest:
> 
> It should be permitted to assign CVE IDs to common web application
> vulnerabilities in specific sites/services (e.g., facebook.com the 
> site,
> not WordPress the product).  "Common web application vulnerabilities"
> means things in OWASP/CWE like XSS, SQLi, CSRF.  Consider this a use 
> case.
> 
> There is no requirement for any provider, vendor, or CNA to try to be
> comprehensive.
> 
> Regards,
> 
>  - Art
>