再保险:CVE托管服务

>我不会认为如果横切跟踪在线服务CVE-style >能力是当今对或错的事。>……>——一些组织可能更感兴趣的是云/服务提供跟踪>(如公司为多云服务本身存在的)我认为你同意有一些组织将受益于有一个中央存储库的托管服务安全漏洞,对吧?什么坏实践跟踪(例如,可怜的密码处理)?其他人呢?>没有,味道中,使用“CVE”作为ID计划的一部分。>没有绝对的逻辑或有益的理由这样做。> >——CVE支持十年两个前缀方案(CVE)。>……>注。这是来自为数不多的人强>对CNA / CVE前缀分裂和>斜方统一都将承受巨大的压力。 Just so I am clear, I think you are saying that having a different prefix for CVEs has been tried in the past and wasn't successful. If I am wrong then let me know. I see the older CAN/CVE scheme as quite a bit different since it was more about having a quality control check and not so much about separating different types of vulnerabilities. Am I understanding your bullet correctly, or are you pointing out something different here? If a new C*E effort was to be stood up to handle hosted service issues specifically, I could see using a CAN/thing model since the use cases, issues, and the problem space would in general be less understood and agreed upon. In other words, a CAN style model could be used early on to ensure quality. Seehttp://cve.mitre.org/about/faqs.html cve_list_retire_term_cve更多信息。“为什么CVE退休CVE”一词候选人”?当CVE倡议在1999年首次开始和漏洞被发现并公布经常比现在少,CVE标识符发行“候选人”或“条目”状态,在候选状态表明,重新审查该标识符包含CVE名单和条目状态表明,标识符已被正式录取名单。与候选成员国资格使用CAN-prefix CVE标识符(例如,“- 1999 - 0067”),同时与条目状态使用CVE-prefix CVE标识符(例如,“CVE - 1999 - 0067”)。这意味着个人标识符数字本身需要改变一次候选人已经进入状态更新,把一个很大的负担放在世界各地众多供应商和组织,进而需要更新他们的工具和流程,以适应数字替换标识符。这成为特别繁重的漏洞被发现的数量和添加到CVE列表中每年急剧增加(CVE标识符现在添加到CVE网站每天)。因此,在社区的要求,在2005年所有CVE标识符现在使用CVE-prefix和立即可用的社区。而引用和其他支持信息更新可能随着时间的推移,CVE标识符数字本身不会改变一旦被分配到一个问题。”>- 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) The Board has discussed expanding CVE into other domains such as medical devices, Iot, transportation, etc. I believe we would run into the same problem in those areas as well right? Maybe this gets solved very simple by way of a field that labels the domain of the CVE. One of those domains could be hosted/site-specific software. Additionally, Ken Williams mentioned another approach of using specific blocks to separate these CVEs from the others. > - 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. I understand your point, but it seems this will always be a problem and would never really go away regardless of what direction we take. > - Did I mention there is no logical reason to mix them under a > unified CVE > identifier? =) We are obviously not far along in this discussion and have lots of time to change course if and when needed. One of the things I'd like to see is a more defined set of use cases to support this effort. There are a number of folks on the Board that are interested in pursuing this discussion and I want to make sure we facilitate that discussion. I would like to hear more specifics regarding why we should NOT include them under the CVE umbrella. Does anyone else on the list have concerns similar to the general ones listed here? Separate from the above responses, here are a few related thoughts that come to mind when "separating" these programs (i.e., CVE and some other C*E to track hosted vulns). These situations might make assignments interesting to say the least. It was mentioned in another reply that the difference between products and services will continue to get more blurred going forward. - The affected software is available in both customer-controlled AND vendor-hosted versions. Do you create an ID in both programs and assume it affects both, just the one that was reported, something else? - The affected software is offered as vendor-hosted only, but the vendor has allowed a limited number of customer-controlled instances. Same problems as above. - The affected software is a hybrid with some client code and some hosted code. It isn't clear which is affected in each case. - Many hardware/embedded devices contain software that cannot be changed by the customer (e.g., Iot and appliances). You could argue that this falls into the category of vendor-hosted/controlled since the customer has no way of changing it. Chris Coffin The CVE Team -----Original Message----- From: jericho [mailto: jericho@attrition.org发送:星期五,2017年2月24日下午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.