Re: The CVE-10K Problem
This seems like a great deal of conversation for a pretty simple issue.
Steve, perhaps you could solve it unilaterally?
On 1/16/07 4:12 PM, "pmeunier" <email@example.com> wrote:
> "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
> cavalry regiment.
> 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:firstname.lastname@example.org | cell:781.424.6003