Saving CVE with open source

Part 1 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.

Put bluntly, 2015 signaled a possible failure of Common Vulnerabilities and Exposures (CVE), the widely-accepted standard and repository for vulnerability reporting. This, however, wasn’t a sudden problem: For a variety of reasons, getting CVEs assigned was becoming a test of patience for many researchers and reporters.

Like many things in life, it is often the times of crisis where we have the best opportunity to actually make change and improve. I’ve been involved with CVE for some time now (since 2001 or so?) and when I joined Red Hat in 2011, a major part of my job was CVE-related (I took over assigning them at Red Hat from Josh Bressers). It was clear to me that CVE needed saving, the biggest question was how? After I spent some time (months) looking at the challenges and trying to find ways to address them, it became apparent to me that the problems with CVE were symptoms, and that the underlying causes went deep enough that they would need to be addressed before we could fix anything else with the standard.

Let’s take a moment to segue sideways into a favorite topic of mine: small independent local restaurants. Traditionally, if you wanted to open a restaurant, you took one or more concepts (burgers, pizza, unlimited refills, etc.), developed a plan, executed on it and hoped that it would work. Despite excellent planning, about 59 percent of these ventures fail in the first year in the U.S But now, I’m seeing a change on how people open restaurants.

For example, we have a new chicken restaurant where I live that did three “pop-ups” long before opening their first location. Basically, they made arrangements with other small restaurants to use their spaces for one day and serve their food for the day, spreading awareness via Twitter and other social media. I went to the first one, and waited in line for quite some time, but the wait was totally worth it. Speaking with the owners now, they shake their heads talking about that first day, but they say something important: “We learned a lot that day, and from the following pop-ups.”

By doing a pop up, they hacked the system and found a way to experiment with a restaurant concept, and iterate it several times to perfect it before actually opening. Rather than running these experiments “in house” (while trying to pay the rent, wages, etc.), they were able to spend a few thousand dollars on food costs (which I suspect they mostly recouped by selling a lot of really good fried chicken) and learn, with time in between pop-ups to analyze what happened. This is in many ways the epitome of the Open Source Way - people sharing and borrowing resources, lessons, expertise and releasing early and often, iterating their way towards success.

This kind of thinking is what needed to be applied to CVE. So I started a project, the Distributed Weakness Filing (DWF) Project, with the idea being to rapidly experiment and iterate with CVE-style assignments and see what would work/didn’t work. I also wanted to poke the CVE system (gently) to wake it up to the realities of what was required of a modern system, which involved conversations with the CVE board. The good news is that CVE took notice and was receptive to change.

Since 2015, we’ve created and accepted a new board charter, and new guidelines for CNAs (CVE Numbering Authorities; in other words, the groups/people who assign CVE IDs). MITRE, the ultimate authority for all things CVE, has created a large number of new CNAs ranging from well-known open source groups like the Apache Foundation to Larry Cashdollar and companies like TIBCO. We’ve also looked at new ways CNAs operate and what exactly CNAs need to do, with an eye towards simplifying the process and making it much faster (the goal is <5 minutes for a requestor to generate a CVE request and <1 minute for the assigner to assign it).

That’s what happened in the past year and half, but in part two, we’ll look at exactly how the sausage is made with CVE and how this impacts (or doesn’t impact) DWF.