Re: CNA Rules Announcement

[Pascal Meunier <pmeunier@cerias.purdue.edu>]

I apologize for having missed the point (even stated in the text of 
CVE-2014-8730!), that this is not a flaw in the specification of the 
protocol.

I agree with Brian, it makes sense to have one ID for a flaw in the 
specification of a protocol, and multiple IDs for vendor implementations 
with different code bases, even if they happen to have made similar 
mistakes.  I think Kurt's suggestion to cross-reference them "(this is 
related to the following CVEs: Z/X/Y)" would be helpful although not 
necessary.

I am sorry for having added confusion.

Pascal

On 10/09/2016 10:13 PM, jericho wrote:
> 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