Re: The CVE-10K Problem

[Alfred Huger <alfred_huger@symantec.com>]

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" <pmeunier@cerias.net> wrote:

> Dave,
> "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.
> 
> Regards,
> Pascal
> 
> 
> 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?
>> 
>> Thoughts?
>> 
>> -Dave
>> ==================================================================
>> David Mann     |   CVE Project Lead   |  The MITRE Corporation
>> ------------------------------------------------------------------
>>      e-mail:damann@mitre.org    |      cell:781.424.6003
>> ==================================================================
>> 
>>