再保险:CVE托管服务

只是为了“论证”,和更多的锻炼,看看这是导致。https://bugs.chromium.org/p/project-zero/issues/detail?id=1139哈罗德,你会怎么写CVE-ish描述,在移动环境中CVE特定站点问题?服务和信息披露是比较容易的部分。然后呢?你也提到的一些服务使用Cloudflare吗?一些企业可能知道,个人不(例如1密码是托管在它)。你什么日期范围放下吗?你知道修复日期,开始日期。这可以追溯到问题的条目有用公司试图确定风险。在很多方面,这个条目将最简单的写的细节,然而,缺乏信息的关键一点。。b在星期四,2017年2月23日,展台,哈罗德(美联储)写道:我承诺在服务调用来描述一个用例。这里有一些分支:::一个受欢迎的服务/网站有漏洞一段时间。 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 t he 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马尼恩]代表艺术:发送:周三,2017 4:39点:2月22日:耶利哥< jericho@attrition.org >;帕默< pmeunier@cerias.purdue.edu >: Cc: cve-editorial-board-list < cve-editorial-board-list@LISTS.MITRE。ORG >:主题:Re: CVE托管服务::2017-02-22 16:19,耶利哥写道::>结婚,2017年2月22日,帕斯卡贝写道::>:>:恐怕条目的描述,问题:>服务:>:像facebook.com,将通常非常模糊,无法核实的。:>我:>:现有条目,而恼火,读起来像“问题X,: >但:>:不同于cve - 1234 - 5678和cve - 1234 - 7890”。这个问题是什么?:>:这可以从中学习到什么?我们应该教不是:>:>:做什么,或者教做得更好吗?不知道。:> >好点。:> >也认为,这样的描述几乎从不携带版:>信息和基于*近似*日期。 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 :