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

Re: CNA Rules Announcement



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



Page Last Updated or Reviewed: October 10, 2016