Re: Concerns about CVE coverage shrinking - direct impact to researchers/companies

[Kurt Seifried <kseifried () redhat com>]

On Thu, Mar 10, 2016 at 10:33 AM, Timothy D. Morgan <
tim-security () sentinelchicken org> wrote:

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


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

It's git. You can trivially keep an entire copy the databases trivially. It
can be hosted in many places. We'd have to redo the issue tracking, but
bugtracking systems are not exactly hard anymore.


> * 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.)

Correct, that is intentional. The database is just the ID and
assignee/requester/etc. THe Database schema would never be close to
correct/complete so I decided not to have one. The Artifacts Database
contains all that data, there will be a JSON file(s) with some semi
structured data (e.g. OSVDB, X-Force IDs, original researcher/etc.) and
then any artifacts (e.g. a copy of a security report, patch file,
whatever).


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

See above. That's the whole point of the artifacts database. Please reread
my original email maybe?


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

See above. That's the whole point of the artifacts database. Please reread
my original email maybe?


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

I am of course open to feedback, but please actually go to
https://github.com/distributedweaknessfiling/ and see what we're doing
first before assuming we aren't doing certain things (like making sure the
artifacts associated with a security vuln don't disappear).


> Best,
> tim
> @ecbftw



-- 

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