RE: CVE for hosted services

["Booth, Harold (Fed)" <harold.booth@nist.gov>]

I promised on the call to describe a use case for services. Here is one 
with some branching:

A popular service/site has a vulnerability for some period of time. 
This vulnerability created an exposure for users/consumers of the 
service/site. The users/consumers would like to go back and determine 
if they have been impacted because of this exposure. In order to do 
this they will need a date range and a description of the problem (i.e. 
what part of the service was vulnerable), potential impacts on them 
(the users), and potential (or actual) exploits. While it would be 
beneficial if the service provider had all of this information, they 
may not, and now there is a need to have a long-lived identifier to 
coordinate the discussion among several different stakeholders (I would 
also argue that just communicating between the service provider and the 
customer is enough reason for the identifier). I agree collecting this 
information may not be easy at the moment, but I don't think that 
doesn't mean it isn't desirable to have it. Minimally, I think this use 
case demonstrates the need for an identifier. Perhaps once it is 
demonstrated that this information is important then it will be more 
routine for it to be tracked and available.

Hopefully, I am not too far afield with this.

-----Original Message-----
From: owner-cve-editorial-board-list@lists.mitre.org 
[mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of 
Art Manion
Sent: Wednesday, February 22, 2017 4:39 PM
To: jericho <jericho@attrition.org>; Pascal Meunier 
<pmeunier@cerias.purdue.edu>
Cc: cve-editorial-board-list <cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: Re: CVE for hosted services

On 2017-02-22 16:19, jericho wrote:
> On Wed, 22 Feb 2017, Pascal Meunier wrote:
> 
> : 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.
> 
> Good point.
> 
> Also consider that such descriptions would almost never carry version 
> information and be based more on *approximate* dates. We often hear 
> Facebook "fixed a vuln" but days or weeks after it really happened. 
> Since versions are a huge tool for determining potential duplicate 
> issues, without that would be painful.

Agreed, there's likely pain for cataloging purposes (de-duplication) 
and low value for engineering purposes.  But the overriding factor for 
me is
*identification* (and yes, for ID to work, it has to be possible to 
distinguish different vulnerabilities).

CVE throws light on vulnerabilities.  Probably weekly, without looking, 
I come across issues that don't have CVE IDs assigned and therefore 
aren't noticed by people who might benefit from knowing.  I make a note 
to send in a minimum viable entry, but haven't yet.

Oh, services have CVEs?  Airplanes?  Dentist office software?  Oh, 
large services freely admit they have vulnerabilities, and fix them?
Users/customers actually like such transparency?

Vulnerabilities are common and everywhere and aren't terribly special 
individually.  Name them and go about your choice of defensive 
activities, probably including vulnerability management.

 - Art