Re: CNA requirements

[Kurt Seifried <kseifried@redhat.com>]

On Tue, May 17, 2016 at 8:54 AM, Waltermire, David A. (Fed) <david.waltermire@nist.gov> wrote:

IMHO, I believe we need to address this in a way that supports a non-hierarchical, graph of communications between CNAs. This models what happens in the real world. It should be possible for any CNA to find any other CNA, get their contact info, and then reach out to them to coordinate on a CVE assignment. Relying on parent CNAs does not make this work.

Regards,
Dave

 

So I've been thinking about this a bit and looking back at some situations in the last 5000 or so CVE's I've assigned and some things are obvious:

1) Being a CNA requires you to have a mature security process, if you don't have this you wouldn't be able to function as a CNA let alone then do something useful with the CVE. So from the DWF's point of view it's easy, you must be this tall (height requirement to be decided) to get on the ride and become a CNA. 

2) We have four main types of CVE related groups:

a) researchers who find vulns

b) coordinators who help handle vulns

c) vendor who fix the vulns

d) end users who consume CVE data/fixes/etc

for group a) it's simple, if they are mature and well behaved it makes sense for them to become a CNA, then their vulns have CVEs from day one and are a lot easier to track. There is some potential for parallel discovery and thus duplicates, but this is rare enough it won't be a huge problem. 

for group b) it's simple, if they are mature and well behaved it makes sense for them to become a CNA, people come to them with vulns, they get a CVE which helps coordination immensely. There is some potential for parallel discovery and thus duplicates, but this is rare enough it won't be a huge problem. Parallel discovery can also be addressed here if the same CERT is used for the issues.

for group c) it's simple, if they are mature and well behaved it makes sense for them to become a CNA, people come to them with vulns, they get a CVE which helps coordination immensely. Parallel discovery can also be addressed here assuming the CVEs are reported to the vendor (which if they aren't, we have worse problems).

for group d) it's not so simple, but I can see a potential for example of a large consumer of security updates wanting to ensure they all have CVEs. I suspect in this case I would advise people to go to the DWF/Mitre, I can't see us minting a CNA that is just a consumer of security updates without some really interesting circumstances (which might happen, what do I know?). 

As for contact information I'm simply requiring CNA's that the DWF creates to register with us, they must have a working email address and almost always a URL where they publish CVEs (although not required, I can see there being a potential for exceptions). I've also decided not to have a minimum number of people (beyond the obvious answer of "1") since many projects are sometimes one core developer driving the security effort, and based on past experience many do a very very good job. I will certainly not be requiring a Phone number. 

As for "sub CNA's", I haven't given that a ton of thought yet but I suspect the best/easiest will be to largely have the DWF policies "flow through", so we have consistency, good contact data, etc.

--
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