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

Re: CVE for hosted services

Hi,

I've been thinking a lot lately about taxonomies of attacks for a
project which is only tangentially related to CVE, and so if this
email is randomizing, I apologize.

When we created CVE, we spent a lot of time talking about fingerd.
(As I recall, that's why CVD[atabase] became CVE).  Dave Mann has
talked a lot about the example of a museum exhibit, and how its
creators benefited from being able to point at the birds.  I would
encourage you to create a zoo: a collection of issues about which you
can productively debate, and see if, with those issues collected,
you can find commonalities, such as the one Tom suggests below.

Best,

Adam

On Mon, Feb 27, 2017 at 11:52:02PM +0000, Millar, Thomas wrote:
| I think this (using a discrete, specific block for vulns in services) 
is a
| serviceable middle ground, perhaps.
| 
| I do think a clear distinction should be made for CVEs that can't be 
dealt with
| except by the service provider, basically, probably because I've been 
talking
| to too many people for whom CVEs = audit findings.
| 
| 
| 
| Tom Millar, US-CERT
| 
| Sent from +1-202-631-1915
| https://www.us-cert.gov
|  
| 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| From: owner-cve-editorial-board-list@lists.mitre.org on behalf of 
Williams, Ken
| Sent: Saturday, February 25, 2017 1:53:07 AM
| To: jericho; Coffin, Chris
| Cc: cve-editorial-board-list
| Subject: RE: CVE for hosted services
| 
| Or we could keep the CVE prefix and just assign a publicly defined
| block to online services, as SSN used to do with mapping the
| leading 3 digits to geographical area, or as CC companies do with
| the leading 6 digits for the IIN/BIN.
| 
| Using the CVE prefix for all vulnerabilities, both in software and
| in services, doesn't have to be a problem.  It makes sense logically
| because it identifies the number as belonging to a vulnerability.
| 
| Regards,
| kw
| 
| > -----Original Message-----
| > From: owner-cve-editorial-board-list@lists.mitre.org [ 
mailto:owner-cve-
| > editorial-board-list@lists.mitre.org] On Behalf Of jericho
| > Sent: Friday, February 24, 2017 4:30 PM
| > To: Coffin, Chris <ccoffin@mitre.org>
| > Cc: cve-editorial-board-list 
<cve-editorial-board-list@lists.mitre.org>
| > Subject: RE: CVE for hosted services
| > Importance: High
| >
| > I will say this with all of the virtual emphasis I possibly can. I 
won't
| > argue if MITRE tracking online services in a CVE-style capacity is 
the
| > right or wrong thing to do today. But I will say that if you do 
this...
| >
| > Do NOT, uner any cicumstance, use 'CVE' as part of the ID scheme. 
There is
| > absolutely no logical or beneficial reason to do so.
| >
| > - CVE supported two prefix schemes for a decade (CVE and CAN).
| > - 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)
| > - 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.
| > - Did I mention there is no logical reason to mix them under a 
unified CVE
| >   identifier? =)
| >
| > I have been an outspoken critic of MITRE and CVE for a long time. I 
have
| > spent a LOT more of that time trying to help via the board and 
behind the
| > scenes. If MITRE opts to mix and not use diffferent prefix schemes, 
I
| > fully believe that will be the biggest mistake MITRE has ever made 
in the
| > 17+ years of maintaining the CVE project.
| >
| > .b
| >
| > p.s. This is coming from one of the few people who were strenously 
against
| > the CNA/CVE prefix split and put significant pressure on MITRE to 
unify
| > that.
| >
| >
| > On Fri, 24 Feb 2017, Coffin, Chris wrote:
| >
| > : The CVE Team has discussed the inclusion of hosted service
| > : vulnerabilities within the CVE program on multiple occasions in 
the
| > : past. However, a decision was never made on how to proceed. The 
CVE
| > : Board call on Feb 22 included a very informative and useful 
discussion
| > : regarding this topic, and we feel this topic needs to move 
forward.
| > : Based on Harold's valid use case, input from other Board members, 
and
| > : the fact that more and more software is being offered via hosted
| > : services, the CVE Team believes that these vulnerabilities should 
be
| > : assigned CVE IDs and we have no objections in supporting these 
under the
| > : CVE program.
| > :
| > : We believe that there are still decisions to be made on what 
kinds of
| > : use cases should be supported, but these can continue to be 
identified
| > : and discussed on the CVE Board list. Once we have agreement on a 
valid
| > : set of use cases, the CVE Team and Board can decide on any needed 
rules
| > : and guidelines. At that point, we believe that the best option 
would be
| > : to pilot the idea through one or more of our existing CNAs who 
also
| > : maintain hosted services. If anyone has any additional 
suggestions or
| > : comments on a way forward then please offer them up.
| > :
| > : To answer the specific questions regarding the determination of 
risk
| > : based on CVE, we agree with Art that CVE is the first step in the
| > : process and should only be responsible for starting the 
conversation
| > : (i.e., naming the thing). Other organizations can add additional 
value
| > : on top of this, such as risk scores, mitigations, etc.

-- 
Don't miss out on my news, which comes out roughly once a quarter.
http://adam.shostack.org/newthing.html
Page Last Updated or Reviewed: February 28, 2017