再保险:CNA规则公告

太阳,2016年10月9日,孩子叫Nandakumaraiah写道:10/9/16 13点,耶利哥写道::>如果你想然后转变一个ID实现缺陷和问题,:>当协议规范是正确的,你不是一致的。::这是缺陷被分配一个ID::如果缺陷是非常具体和独特的实现:特定的协议,它应该得到一个ID,不论:受影响的产品或供应商。你现在将双方的抽象争论和不一致的或明确的自己。“缺陷被分配一个ID”然后立刻说“如果缺陷是非常特殊和独特的实现……它应该得到一个ID”。你不能两者兼得。:重要的是要保持一致的处理:>问题。::一直做错事不让它正确。重读我的电子邮件。我很明确的说,如果我们改变的标准,这是很好,但是我们需要非常公开状态。 I am not arguing to stick to the old way, or move to the new way. I am playing both sides of the debate because both have merit, and I have said that several times. : > Again, I see the benefit of each method and unfortunately, the benefits of : > each way help different types of InfoSec professionals. If we go one way, : > we please academics, (some) VDBs, and (some) auditors. If we go the other : > way, we please system admins, (some) VDBs, and (some) auditors. : : I have only seen confusion and misunderstandings due to such fragmented : IDs. There is always a danger of some valid vulnerability being ignored : as a false positive because the MITRE description said something about : the CVE being applicable only to a certain vendor's product. Can you cite a specific example? And that would not happen if CVE's coverage was better, and addressed those additional products that were impacted. Either adding them to the base entry (e.g. if it is a protocol flaw), or abstracting out for additional vendors if that is the decision. Ultimately, this boils down to a simple "do we abstract or not" argument for CVE, but must consider the coverage argument above. There are merits for abstracting, and there are merits for assigning a single CVE. I know I don't have a pulse on the entire industry, no one does... but working for a vuln scanner company and a commercial VDB, I see at least two big sides to his argument. There WILL be confusion, regardless of what side we pick. That is the fact. Saying there is confusion is a non sequitur, that should be obvious to anyone familiar with this arena, as I outlined both sides previously. Brian