Date: Thu, 10 Mar 2016 09:33:37 -0800 From: "Timothy D. Morgan" <tim-security@...tinelchicken.org> To: oss-security@...ts.openwall.com Subject: Re: Concerns about CVE coverage shrinking - direct impact to researchers/companies Hi Kurt, I don't mean to ignore what you guys have been working on. It is arguably the most mature of the alternatives so far, and we need people experimenting with real tools right now. All I was trying to point out was that we should keep this discussion going even if MITRE gets their act together in the short term. More comments below. > > Suppose MITRE fixes their issues tomorrow and the CVE goes back to the > > way it was. Is that really want we need going forward? A system > > that's based on sending emails between humans and posting only > > one-line descriptions with a series of links (half of which are broken > > after a short time)? A system which tries to distribute the load by > > using "big" software vendors, many of whom have a vested interest in > > limiting what vulnerabilities get published in their software? > > > > It seems like we can do better than this. Infosec hasn't been > > "working" for some time. Perhaps we need better tools to help us get > > ahead of the game. > > > > Even if Mitre had unlimited funding there will be a need for the community > to be involved, especially if we're going to make sure that CVE/DWF cover > important flaws (of which there are thousands right now, and we haven't > even dealt with the IoT or non english software markets like China....). > > Putting on my info security economics hat: > > And I suspect the solution to this is the same as Open Source, we scale > out, build a community and process that works and change as needed. DWF is > one such effort. We aim to reduce the cost of vulnerability identification, > and vulnerability coordination so that there's more less negative incentive > (cost in time and effort) to do this right. > > As I've repeatedly stated the DWF wants to work with CVE/Mitre if possible, > forking vulnerability identification will create additional costs > (retooling all the systems and process that rely on CVE) so I want to > minimize that as much as possible, the goal is to make things better and > easier, not to add another standard for the sake of itself. Looking at DWF, it seems to have a few advantages over CVE, particularly for researchers, but it's hardly what I would hope for as a solution for the public. Please view this as *constructive* criticism: * It is unclear to me on how the system is currently "distributed". Yeah, it's in git, but that basically means it is just hosted on GitHub. What if GitHub's policies change tomorrow on distribution of vulnerability information? I imagine you've thought about this, so I'm probably just pointing out the obvious. * There's no facility to describe anything about the vulnerabilites in the DWF-database. As you've probably seen from my past emails, I'm arguing for a system that tracks more than just metadata and links. (DWF doesn't appear to have links or even simple descriptions.) The "end user" (sys admins, pentesters, other auditors) need a database of vulnerability information that is actually useful and isn't going to go away. Tomorrow your vuln scanner finds a box missing a patch in obscure software X from 5 years ago. All patch info and researcher info has been taken offline. How do you represent that risk to your management? If the software is no longer supported by the vendor, but it is still in production in your org, how do you argue for funds to replace the software? THIS HAPPENS ALL OF THE TIME. We literally need a way to copy/paste vendor and researcher advisories, when the bug is first published, into a central database. (Of course there's copyright/IP concerns there, but if it is valuable to the community, that can be worked out.) You can argue that this archival should be handled by third-party databases, but pretty much all of them are commercial and many have gone offline years after inception. I recognize you're just getting this started, but I feel when building a new system, it's always best to tackle the hard problems first. Best, tim @ecbftw
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.