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

[Carsten Eiram <che@riskbasedsecurity.com>]

On Mon, Apr 25, 2016 at 6:15 AM, Kurt Seifried <kseifrie@redhat.com> wrote:

I would suggest it's less about the voting per se and more about the
concerns raised,

I find it's about both. However, the main concern regarding the voting was not as much about the Juniper vote itself, as it was about the precedence it could set for votes in the future generally being on Board calls vs. the private list that has historically been used quite successfully.

e.g. With juniper some legitimate issues were raised

Indeed some very legitimate issues.

but by and large everyone on the call (at least my impression) was
like "it's not 100% perfect. It it's not a show stopper, and chances
are the problems can be rectified without to much hassle." As
evidenced if a good chunk of the board (or a unanimous majority
attending) then does vote in the affirmative I think it's safe to say
it's ok to proceed with no material concerns.

The flaw in that logic is that it is assumed all of us roughly have the same knowledge about a given issue, and that the majority is the smartest. The experts rarely comprise the majority. Each of us have different backgrounds and are not equally clever in all areas.

Had Brian not voiced his concerns, I bet no-one else on the Board would even know Juniper today are struggling when assigning CVE identifiers. Although Brian did have a chance to voice his concerns and provide some details, I doubt anyone still really understand the extent except him (and possibly MITRE depending on how many details he provided them off-list). Naturally, it's the responsibility of the Board member voicing a concern to provide sufficient details to allow the rest of us to make an informed decision, but in this case it seems no real attempts were made to further explore how bad it was before voting.

As someone who didn't attend the call and just have the list discussions to form an opinion on, it comes across as if Brian's concerns were more or less dismissed, and that MITRE and Board members were more eager to get another CNA onboard vs. taking the time to fully explore the concerns raised. Why the rush? Because it's important for MITRE to show that they're making progress on the CNA front, which is clear from their initial email announcement.

If a Board member with significant insight into the CVE assignment practises of a given vendor voices concern, it seems prudent to fully investigate said concerns and at minimum raise those with the vendor and get a commitment from said vendor to address those _before_ allowing them to become a CNA. Instead I experience what I can best describe as a laissez-faire attitude: We'll just make them a CNA since no-one (except Brian Martin, who wasn't on the call) "objected strongly", and any issues are likely a "manageable problem" that hopefully documentation/training can fix at some point in the future.

What are the plans now to follow up with Juniper to get said issues rectified?

We do need more CNAs, but if they don't understand the basics of CVE assignments, it may be more hassle than value. We already see plenty of CNAs not following CVE abstraction guidelines without MITRE doing anything about it. Alternatively, we need to define the level of CVE compliance we actually care about. Is it more important to have a lot of CNAs assigning CVEs to issues vs. following the CVE abstraction guidelines, which then should just be treated as rough pointers? That may be a matter for the Board to discuss. Personally, I find that the abstraction guidelines are there for a reason, and it is fair to at minimum expect a CNA to be fully familiar and comply with them.

I would assume had like
half the board voted against mitre might take a second look at things
before proceeding

I'm not so sure. The decision to make Juniper a CNA seemed pretty much done from the initial announcement, which just stated that Juniper had met all requirements and that a public announcement would go out the same afternoon. The follow-up mail from MITRE stated that the heads-up on the private list was provided "as a courtesy". While it did include that the reason for said courtesy was to allow Board members to raise "significant issues" with naming Juniper a CNA, the Board was only given a few hours, so MITRE clearly didn't expect much push-back if any. Furthermore, nowhere did the first email notification suggest that MITRE was actually looking for Board feedback.

I have no issue with MITRE deciding who becomes CNAs without the Board voting. Either approach works for me, and I'm certainly not advocating that we need to vote on everything.

I do, however, think the Board needs to know what the CNA requirements are. It's problematic when MITRE just states that a given vendor "has met all of the requirements" when it's unclear to us what these are. More so when it's disputed by a Board member. I worked with MITRE when Secunia became a CNA many years ago (they lost that status again after I left), so I know what requirements were asked of me/us back then. Mr. (ex-)CVE aka Steve Christey put me through the wringer. Based on Brian's feedback, Juniper certainly haven't met all those requirements if unchanged.

Lastly, I understand that Brian informed MITRE about some assignment problems with Juniper prior to the call. That makes it even more important for us to understand what the current CNA guidelines are, how MITRE is ensuring that they're being followed, and that such assignment concerns are addressed before a new CNA is created. Otherwise, it could lead to a long list of problems in the future. Did MITRE discuss Juniper's potential CNA status when the concerns were voiced by Brian? I know Kurt mentioned Brian's concerns on the call, but did MITRE also specifically bring up the concerns in a detailed manner to ensure Board members not as familiar with Juniper's CVE assignments could factor that in?

(much like with the DWF proposal, if I can't
convince most people  it's a good idea, then there's a good chance it
isn't a good idea).

While I follow what you're saying, I, again, don't subscribe to "majority knows best". I'd rather listen to a few people, who know what they're talking about vs. getting uninformed thoughts from the majority. Especially as a community-driven project, the majority of people have various agendas and may express love for the idea without having any intentions of contributing or insights in order for it to become successful.