Re: The CVE-10K Problem
From all the replies, it seems that most of this board stopped reading
after your list of 4 options and missed your additional request for
thoughts regarding funding and related issues. I suggest you resend
that as a separate message.
Alfred Huger wrote:
> 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" <firstname.lastname@example.org> 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:email@example.com | cell:781.424.6003