Re: The CVE-10K Problem (fwd)
"It doesn't scale" are words that I've heard too often to discredit
something out-of-hand. Expecting a constant effort to be able to handle
any number of vulnerabilities doesn't make sense. However, the effort
necessary to enumerate products should scale linearly with the number of
products. So should enumerating already discovered vulnerabilities (not
discovering them). If you see any reason why this wouldn't work, please
enlighten me (I assume this is what you mean by "doesn't scale"?). The
question is how to get resources proportional to the number of
discovered vulnerabilities. Not increasing the funding of the CVE
effort when the number of vulnerabilities increases so dramatically
doesn't make sense, and we've had many years of that.
To continue your metaphor, if the U.S. keeps playing alone, there is no
doubt that we'll drown. You'll have to try to guess which products are
the most used or deployed and it will be ugly. Involving other
countries and requesting participation (i.e., funding) proportional to
the number of products they develop, which should be roughly
proportional to the number of vulnerabilities overall, is the way to go.
I don't know how to make it all happen but it doesn't matter. I know
how to start: by engaging people from different countries. Some of
them will know how to make it happen in their home countries. The U.S.
should stop trying to be the Lone Ranger, and should recruit to create a
Mann, Dave wrote:
> pmeunier wrote:
>> Funding for the CVE should be a requirement for the DHS, at whatever
>> level is needed for it to function correctly and without undue stress
>> on team members. The CVE is a necessary foundation for vulnerability
>> handling and research (or as I said before, "the key"), and many
>> aspects of security.
> Paraphrasing a quote that my wife used to have taped on our
> refrigerator door when we were in grad school...
> Of the making of software packages there is no end, and
> much vulnerability research is a weariness of the flesh.
> (It's from the last chapter of Ecclesiastes and originally stated
> about the making and study of books, for those dying to know).
> I see this as being much, much bigger than a DHS or US Government
> funding issue.
> As you've correctly noted Pascal, software is being authored
> globally at a mindblowing rate. I have this picture in my
> mind. It's of the little Dutch boy with his fingers in the
> leaking dike. And on the other side of the dike, is the
> massive tsunami wave of the global software market. I don't
> think the problem of software package identification is
> scalable in this new world, much less the problem of
> vulnerability identification *within* those packages.
> My sense is that end consumers of vulnerability management
> solutions have learned that their limited dollars will only
> buy partial coverage and are willing to settle for coverage
> of the most important (to them) issues. Dan Geer (and others)
> has said that enumerative security models don't scale and I
> tend to agree with him.
> This is why I don't think this is *only* a government
> funding issue. More generally, I don't think the world is
> willing to pay for coverage of all vulnerabilities in
> all software packages at any part of the VM life-cycle.
> We are all ears on ways to restructure the CVE id assignment
> process to reduce the bottle neck. I think we can make
> substantial progress but I think we all must recognize that
> a wave is coming. Here is a list of things for us all to consider
> and discuss...
> + Can we agree on a list of "must be covered and covered quickly"
> set of software? This would allow CVE to better focus it's
> energy. But other things will be excluded.
> + Can we streamline or automate the Candidate Naming process?
> And if this introduces more errors and duplicates, to what
> extent can the community deal with errors?
> + Can we figure out reasonable ways to divide up the problem
> as Pascal suggests?
> David Mann | CVE Project Lead | The MITRE Corporation
> e-mail:email@example.com | cell:781.424.6003