Saving CVE with open source, part 2: How CVE IDs get created

Part 2 of a 3 part series based on Saving CVE with Open Source, a talk that I am giving with Kent Landfield of Intel at RSA 2017. Read Part 1 here.

In the past, getting a CVE ID was simple but prone to possible delays. Either you were a CVE Numbering Authority (CNA) (such as Red Hat) and you could assign CVE IDs as needed or if you weren’t a CNA, you had to find a CNA (such as Red Hat or MITRE) and ask for their help with the process. Alternatively, if it was for a public open source issue, you could simply email the oss-security mailing list and wait for a reply.

Besides these hoops to jump through,the actual method for creating a CVE ID or for crafting an informative CVE ID request, was not well known outside of the CNA community.

Simply put, receiving a CVE requires three steps:

1. Determine if this a security vulnerability

2. Determine how to count the vulnerabilities (if it’s more than one issue)

3. Request a CNA to actually assign the CVE ID(s) as needed

The first step seems self evident but can often be tricky. For example, some things may be security-related but end up being classified as a security hardening issue, not be an actual vulnerability. Other types of security problems exist on a continuum, ranging from clear vulnerabilities, such as process/package that claims to provide encryption but fails to do so, to borderline issues, like using AES 256 in CBC mode (sometimes that’s ok, and sometimes that’s a vulnerability).

The classic question used is “does this issue cross a trust boundary” which needs some clarification. This can quickly devolve into a series of academic discussions which are useful for dealing with corner cases but it all boils down to:

Can an attacker use this security vulnerability to do something bad?

This entails activities like gaining access to something, elevating privileges, and crashing a system or program. It can also mean that affected systems have a stated security property that doesn’t work (e.g. if you advertise a system as having a firewall and it doesn’t, that’s a CVE).

If you can’t easily or clearly articulate what bad thing someone can use this issue for, chances are it’s not a vulnerability, or that the issue isn’t sufficiently understood.

In order to make getting CVE IDs easier and quicker, we need to do two things:

1. Make the process simpler where possible

2. Scale this process out (have a lot more CNAs)

Fortunately for us there is a way to do both things at once: CVE Mentors.

CVE Mentors serve two main purposes: they handle the actual process of CVE ID assignment, meaning that we don’t have to teach every single person who deals with security vulnerabilities how to do this, and it allows us to bring more people into the CVE process as they don’t have to be as technical. So how is this a good thing; won’t less technical people make more mistakes? On their own, yes, they could. But if they are working with the people who have found and reported the vulnerability, and have access to other more technical CVE Mentors who can provide assistance as needed, we can expand the pool of people who can handle CVE assignments.

Want to learn more? If you’re attending RSA 2017, come and see the talk and stay tuned for more on Saving CVE after the show!