再保险:CVE托管服务

或者我们可以保持CVE前缀就公开定义的块分配给在线服务,如SSN和映射的主要使用3位数的地理区域,或CC公司与领导/ BIN 6位数的射程。使用CVE漏洞前缀,在软件和服务,不一定是一个问题。逻辑上是有道理的,因为它能够识别属于一个漏洞。问候,千瓦> - - - - - - - - - - - >从原始信息:owner-cve-editorial-board-list@lists.mitre.org > (mailto: owner-cve -代表耶利哥> > editorial-board-list@lists.mitre.org]发送:2月24日,星期五,2017年下午4:30 >:棺材里,克里斯< ccoffin@mitre.org > > Cc: cve-editorial-board-list > < cve-editorial-board-list@lists.mitre.org > >主题:RE: CVE托管服务>重要性:高> >我将与所有的虚拟强调我说这个。我> >不会说如果横切跟踪在线服务CVE-style能力>今天对或错的事。但我要说的是如果你>这…> >没有,味道中,使用“CVE”作为ID计划的一部分。> >完全没有逻辑的或有益的理由这样做。> >——CVE支持十年两个前缀方案(CVE)。>——许多组织将不希望跟踪在线服务,以及混合> >会非常痛苦的覆盖率(指标|百分比)等。> -一些组织可能更感兴趣的是云/服务跟踪>(如公司存在多云服务本身)>——无数vuln游客(个人和企业)>,>年度统计数据完全基于CVE和不理解CVE >这将永远使所有数据生成完全没有价值。我>的意思是,他们已经一文不值,但这将使它更甚。>,我有没有提到没有逻辑的理由把它们混合在统一CVE > >标识符?=)> >我一直直言不讳地批评斜方和CVE很久了。 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.