再保险:[技术]勤奋的候选人分配水平

安德烈·弗雷希问:>——建议程序审查现有的候选人>和CVE列表来确定已经存在一个类似的问题?>一个清单可能会有帮助。我计划写一个作为一个入门文档对于那些要求候选人数字。目前,搜索CVE网站应充分尊重看到如果已经有一个现存的候选人/条目。CVE的关键字搜索返回的条目和候选人,和一些大约智能匹配,可以使它比其他搜索引擎更有用,在某些方面。(这是由CMEX同义词典)。例如,所有这些术语是等价的CVE搜索引擎:Wuftp, Wuftpd, Wu-ftp, Wu-ftpd;pfdispaly pfdisplay;缓冲区溢出和缓冲区溢出;SMTP和SMTPd; IE, Internet Explorer, IE4, and IE5; etc. >- Which candidates or entries are prone to encompass larger issues? This will also be documented at a high level. Basically, anything that's not a software bug has level of abstraction issues, and can be difficult to search on for the reasons you described. Some high-level candidates do include "classes" in the descriptions; for example, a search for "ddos" will get you CAN-2000-0138, or "Trojan horse" will get you CAN-1999-0660 and -0661, etc. >Perhaps a short list of the virus, DDoS, backdoor, etc. entries that >may not come up during a search would be appropriate. I agree, and this is planned as part of the introductory document. >- When in doubt, is there an impartial and trusted source available >for verifying decisions or resolving questions? One of the major concerns with opening up this process to arbitrary people was in making MITRE aware of non-public issues on a much larger scale, in some cases even before the vendor is aware of the problem. In cases where the discoverer is already working with the vendor on a solution and coordinated announcement, I see this as less of a problem, so more detailed technical exchange (like the ones we've had in the past) may still be feasible for "trusted" discoverers. However, in general, an email discussion or quick phone conversation could resolve the questions without ever going into specifics. For example, I could see if the problem is affected by the "Same Codebase" content decision by asking "does this bug appear in different software packages by different vendors?" etc. For all the advisories that have been published with CAN numbers so far, on reflection I believe that I could have provided sufficient guidance in all cases without ever knowing the specific product that was vulnerable. The introductory document could ask some of these questions, and provide guidance, without mentioning content decisions. And while it has been complicated to create, I've been working on a "decision tree" that people could easily navigate in order to determine the appropriate level of abstraction to use, whether or not the item belongs in CVE, etc. And no, Spaf, it doesn't look like something out of Krsul's thesis ;-) Until such documentation is fully available and deemed effective, some candidates will be assigned incorrectly through no fault of the requester. So it shouldn't have a negative impact on their diligence level just because we're still trying to figure out exactly what we should do :-) Proposal and discussion of CD's will begin next week. Thus they will be documented, and they will, in turn, help to provide guidance to requesters. I hope this answers more questions than it raises. I would be interested in hearing from vulnerability database maintainers if they have any formalized, documented rules with respect to their own "content decisions." - Steve