再保险:CNA规则公告

    我很抱歉错过点(甚至在的文本表示
    cve - 2014 - 8730),这不是一个缺陷的规范
    协议。
    我同意布莱恩,是有意义有一个ID的一个缺陷
    规范的协议,并为供应商实现多个id
    用不同的代码库,即使他们发生了类似的
    错误。我认为库尔特的建议”(这是交叉引用它们
    有关以下cf: Z / X / Y)”虽然不是很有帮助
    必要的。
我很抱歉带来混乱。帕斯卡在10/09/2016 13点,耶利哥写道:
> 太阳,2016年10月9日,孩子叫Nandakumaraiah写道::在10/9/16 1:08点,耶利哥写道::>虽然很多可能立即说“我们不需要100的id,它是:>混乱!”I disagree to at a certain point. When it comes to per-vendor : > fixes where you are applying 20 different patches, upgrades, or : > workarounds in your organization "for the same vulnerability", that is : > confusing. That one ID is no longer talking about the same vulnerability : > in the full scope of it (flaw, impact, and remediation). : : CVE's core value is in the ability to name vulnerabilities - not fixes, : patches, upgrades or workarounds. : : This is similar to how we name hurricanes or medical conditions: we : don't name the same medical condition differently based on medicines : used to treat it, or people it affects. If we have to send 20 rescue : missions to respond to hurricane Matthew, naming the hurricane : differently for each response mission isn't going to help. : : If there is a need to name (i.e assign unique id to) each patch or : upgrade then that should not be mixed up with 'Common Vulnerability : Enumeration'. We will need something named liked a 'Vulnerability : Remediation Enumeration'. You are right, but jump back in the thread. If the vulnerability is in the protocol specs, it deserves one ID. That is *one* base vulnerability that is inherited by any product implementing the protocol based on the specs. If you want to then turnaround and issue one ID for implementation flaws, when the protocol spec is correct, you aren't being consistent. At that point having different IDs speaks to the different patches, but it wasn't abstracted *because* of the different patches. Subtle, but important difference. I honestly don't much care which way it goes. One ID, abstract by vendor, whatever. The important part is to stay consistent in the handling of such issues. MITRE has largely been consistent on this, with a few outliers (all understandable as best I recall). If MITRE and the Board decide to change that, it should be a unified decision that is clearly stated moving forward. 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. Brian
>