Re: Juniper to be added to the official list of CNAs

[Kurt Seifried <kseifried@redhat.com>]

On Tue, Apr 26, 2016 at 11:28 PM, jericho <jericho@attrition.org> wrote:

On Wed, 27 Apr 2016, Art Manion wrote:


: Speaking of consequences, what if Juniper doesn't follow the rules?
: Withdraw their CNA status?  Then who is going to issue CVE IDs for
: Juniper vulnerabilities?  If a CNA assigns incorrectly, reject their
: assignments.  If the CNA actually wants their CVE IDs to count, they'll
: shape up.  If they don't, de-list them.  And yes, this does sound like
: laissez-faire.  The current model doesn't scale.

And I have spoken to this point as well. We don't just need rules, we need
a clear path on how MITRE will deal with them if they aren't following
rules. Unless MITRE decided to keep me out of the loop after I reported
CNAs not following rules many times, then I don't believe MITRE has been
following up with them much at all. Or perhaps for a fraction of my
complaints.

I can't imagine MITRE will actually revoke a CNA, because it goes against
their selfish interests (CVE is part of a multi-million dollar contract
they enjoy every year). That is a grim reality we need to remember as we
discuss this problem. I only bring it up because many of us had proposed
that MITRE bring on more CNAs several years ago, and that was met with
silence or opposition (usually in private). Now that they are being called
to task, it seems greenlighting new CNAs could be their answer, even if
the vendor has a history of bad assignments and board members object.

I would rather see education/etc rather than revocation (classic rehabilitate vs punish). Revoking a CNA also can result in "damage", assuming the former CNA still does CVE they would take longer (I assume), or they stop doing CVE entirely. 

My plan with DWF is to think about it and ideally avoid the problem, but if it occurs to start with education and if that doesn't work then we ramp up from there.

 

In fact, every CNA, current or proposed, should be audited once a year, to
ensure they are following assignment guidelines. What seems minor and
pedestrian on the surface to many (e.g. assigning a 2016 ID to a 2015
issue), can also snowball in huge ways, as seen in the 2016 Verizon DBIR
report (pg13, 'Vulnerabilities' section) where the methodology is not
defined, and they may be using the year of the ID to attribute disclosure
attributes. Even if they don't, *many* others have historically done just
that when generating yearly vuln totals based on CVE data. These stats are
about the only you see in any media, industry or mainstream. Because CVE
didn't think that 'disclosure date' was important to track in 1999, means
almost every vulnerability stat today is absurd and wrong.

The audit would be problematic for vendors with a lot of CVEs (Red Hat) or for vendors with limited information disclosure (no names but we all know at least one...). I'm more interested in ensuring that CVE process and CNAs/Mitre provide feedback loops so we can identify and fix these problems. Maybe such examples should be posted to the list (assuming we don't flood it)? 

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com