Re: CNA requirements

[Kurt Seifried <kseifried@redhat.com>]

I would define a mature security process not by the process itself, but by the results (essentially the SLA's we expect), some specific things that quickly come to mind:

1) Ability to contact the vendor.project/individual (securely) to report flaws, at a minimum an email address, ideally also a PGP encryption key, even better a way to securely file security bugs into the bug tracker (but increasingly not due to widespread GitHub usage)

2) Acknowledgement and follow up of security reports, I would say max a week to have a human reply to a legitimate issue/question. For example I've had the Puppet security team reply within 3 minutes on a Friday afternoon. At Red Hat we have an SLA for human replies (not fix mind you, but a reply at least) for security reports sent to us.

3) Bug tracking - projects have to have a bug tracking system

4) Projects actually deal with and address the security flaws/reports, even if it's a "WONTFIX because X/Y/Z" or "We'll get that in the next release in 6 months", but there needs to be some sort of resolution. Having bugs sit in a bug tracker for years does nobody any favors, but at least if they're labeled correctly the users of the project can assess the risk/do workarounds/etc.

5) Projects have some notification process for security updates, minimally changelogs (ideally with CVEs), even better a security web page, even better an announcement list (email or other)

But the above really all boils down to: what do they do with security vulns/reports? The more they do to get them addressed/fixed, the more likely they are to be ready to be a CNA, and more importantly, the more likely them being a CNA will have some value. It's simply a question of "does this add value", e.g. a project with a less mature response process, but becomes a CNA and faithfully and correctly assigns CVEs to all the security vulnerabilities found, even if they don't fix them, would still add value in the sense that now I can assess that projects security, or perhaps start helping out with code commits to fix those CVEs. Obviously I'd prefer to have CNA's that assign and fix CVEs, but we all have to start somewhere. Labeling our security vulnerabilities properly as such is a good start (then we at least know what needs to be fixed). 

On Tue, May 31, 2016 at 8:01 AM, Adinolfi, Daniel R <dadinolfi@mitre.org> wrote:

Brian,

Since we seem to not all agree on what a mature security process is, we should probably take a moment to define it. How would you (or others on the Board; please chime in) define or describe a "mature" security process? I'm guessing that there could be many definitions of such a thing, and if CVE would like to see their CNAs have a mature process, we will need to have a stick to measure "mature" against.

What does a mature process look like? How much does the process depend on the organization and how they do software/hardware dev and QA, handle PR issues, support their customers, etc? Or should our definition be a standard, regardless of the organizational details? Are we just measuring how they respond to vulnerabilities in their products, or should we measure beyond that part of their operational processes?

One of the working groups coming out of recent Editorial Board meetings is working on creating standards/guidelines for CVE submissions as part of the bigger community of practice discussion. Should we include this discussion in that working group as well?

-Dan

P.S. SGI does exist. Their CNA contact is Michael O'Connor, and they can be reached publicly at security-info@sgi.com.

On 5/28/16, 02:45, "owner-cve-editorial-board-list@lists.mitre.org on behalf of jericho" <owner-cve-editorial-board-list@lists.mitre.org on behalf of jericho@attrition.org> wrote:

>On Tue, 17 May 2016, Kurt Seifried wrote:
>
>: 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.
>
>And this is where we get into a meta-discussion...
>
>: 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
>
>Patently false.
>
>- Apple is a CNA, they do not have a mature security process.
>- IBM is a CNA, they have a convoluted disgusting security process. (Love
>  Lisa and Scott, but it's true! Also, why isn't IBM on the board?)
>- Oracle is a CNA, they do not have a mature security process.
>- SGI is a CNA, they ... uh, don't exist?
>
>That said, your outline on defining CNA requirements is great and helpful.
>=) Just don't equivocate here.

--

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