再保险:CVE-10K问题(fwd)

戴夫,“它不规模”的话,我经常听说败坏的东西。期待着不断努力能够处理任意数量的漏洞没有意义。然而,列举产品所需的努力应该与产品的数量呈线性比例关系。所以应该列举已发现漏洞(没有发现)。如果你看到任何原因不能工作,请告诉我(我想这就是你说的“规模”,不是吗?)。问题是如何让资源发现漏洞的数量成正比。不增加资金的CVE努力当漏洞的数量急剧增加,所以没有意义,我们已经有许多年。继续你的比喻,如果美国继续独自玩,毫无疑问,我们会被淹死。你必须试着去猜测哪些产品是最使用或部署和丑陋。涉及其他国家和(即要求参与。, 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 > ================================================================== > >