[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CNA Rules Announcement

On Sun, 9 Oct 2016, Chandan Nandakumaraiah wrote:

: On 10/9/16 1:08 PM, jericho wrote:
: > While many may immediately say "we don't need 100 IDs for that, 
it's 
: > confusing!" 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
Page Last Updated or Reviewed: October 10, 2016