再保险:CNA规则公告

太阳,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