(Image via GotCredit.com)
At Red Hat, we strongly believe that IT innovation is born of open, transparent and collaborative communities. From cloud computing to Linux containers, we believe the datacenter of the future isn’t built in a proprietary lab, but in public code repositories and community project sites. Our viewpoint, however, isn’t limited to just building open source offerings - it also applies to providing security for these technologies.
We believe that truly open source software can be more secure than proprietary or open core models. It’s really about scale - when vulnerabilities or exploits are discovered, how many contributors do you want working on them? Because that’s a difference between open source and proprietary software: open source has the power and scale of community behind it, with hundreds to thousands of individual contributors finding and fixing bugs, while proprietary software is typically backed by a single vendor with it’s own internal team and view of security.
As a security professional with decades of experience in finding, reporting and ultimately fixing vulnerabilities, I strongly believe that the methodology of reporting and cataloging vulnerabilities needs to reflect the community behind it, thus following the tenets of open source. I’m also a strong supporter of and involved with the CVE standard, and I believe that these open source principles can greatly help this broadly-supported standard.
The Common Vulnerabilities and Exposures standard, or CVE®, has been maintained by the MITRE Corporation since 1999. In order to communicate about and fix security issues, vulnerabilities require a naming scheme. As vulnerabilities are discovered across the software world, these issues are submitted to MITRE, assigned a CVE number and entered into the CVE catalog, which typically leads to public and private organizations across the world fixing the potential holes in their systems.
At least, that’s how it’s supposed to work.
CVE’s structure hasn’t changed much since 1999; the enterprise IT world, however, has changed dramatically. Software is everywhere and, in many cases, it can be everything to the modern organization. While MITRE has done an admirable job in trying to keep pace with the tens of thousands of CVE requests that come in each year, it has become purely an issue of scale.
More software means more bugs and exploits. Last year, we saw a record number of vulnerabilities. In the age of the Internet of Things (IoT) and SCADA (supervisory control and data acquisition), I don’t expect that trend to slow. A single organization simply cannot address every issue as it comes in with the expected level of expediency or even acknowledgement.
MITRE has acknowledged the challenge, but the follow-up question is always: How? The problem is real, today: thousands of vulnerabilities are without CVE, which means that IT security professionals aren’t fixing them. That’s a problem. CVE is simply too important to fail.
Having assigned thousands of CVEs myself, I thought that there must be a more scalable way to handle vulnerability reporting. One that could use the power of the IT security community without breaking the accepted standard of CVE. Looking to the open source model, I asked: Why only have one team’s experts cataloging bugs when you can have hundreds or thousands of contributors?
So over the past few months, I, with Red Hat’s support, built and launched the Distributed Weakness Filing system (DWF), a community-powered supplement to CVE. DWF gives those doing IT security’s dirty work - the independent experts, software vendors, academic institutions, and many others - control of cataloguing. Rather than having to submit security reports through a single funnel, anyone within the community can work through a more streamlined reporting mechanism and receive a DWF number.
But I’m sure you are asking: "it’s not a CVE number, right?"
Actually, it is. With the backing of MITRE, DWF now issues official CVE numbers and, on May 18, 2016, logged its first vulnerability - CVE-2016-1000000. This collaboration allows for not only a system that catalogs exploits and vulnerabilities in a highly-scalable manner but also supports CVE as the standard for IT security processes. This reaffirms that DWF is not a replacement for CVE but complementary to it. In fact, CVE numbers issued by DWF will be consumed by MITRE, providing additional scale to an ever-growing database.
I believe strongly in CVE and have been a strong supporter of CVE from the very beginning. I now believe DWF is the right way to provide a powerful extension that can ultimately help CVE scale to meet demands that simply could not be conceived in 1999. Open source changed how software is written; now it’s time for open source to change how IT security is managed.
I encourage everyone, from Red Hat partners to independent researchers and security experts, to consider contributing to DWF in addition to their existing work with CVE.