RE: Counting on CVEs

[Russ Cooper <Russ.Cooper@rc.on.ca>]

I never thought CVE would ever be used as intended. As I remember it, it was intended to get all "vendors"  to call a spade a spade. If it worked, U.S gov't would be able to look at a spade called fifteen different things as a single issue, and in so doing, save a lot of money/resources/time.

There has, unfortunately, always been one insurmountable problem...my spade is better than your spade. Which, unfortunately, isn't simply a matter of detection. Seeing as a "spade" means a lot of different things, and vendors differentiate themselves on what they can do with the same CVE, is it not reasonable to understand that CVE has actually been counter-productive to its original intent?

To put it more succinctly, government wanted every vendor see report the same issues, but in enumerating those issue they forced vendors to do more with them.

When the "E" in CVE meant "Enumeration" there was a goal which government would benefit from. If it's not about coming up with a finite list of issues that need to be considered or tested, the I wonder why Government cares, or will pay for insight into...

Cheers,
Russ

-----Original Message-----
From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Adam Shostack
Sent: Friday, March 09, 2012 5:28 PM
To: Mann, Dave
Cc: cve-editorial-board-list
Subject: Re: Counting on CVEs

Dave (and all),

First, I'd like to suggest that these issues are complex, and require
more than the high-interrupt, delve-in-as-you-can attention that email
can bring. (I've had two people walk into my office as I type this.)
So I think the board should meet in person (unfortunately, we just
missed RSA as an opportunity) or with a monthly call with agendas to
work through some of these questions.  I think that email is too
narrow a mechanism for the issues.

Also, I'd like to respond to one of the things you say below:

> I think the best thing that we, the CVE community, can do to help
> facilitate the emergence of a global vulnerability reporting
> capability is to be able to speak clearly about what we can and
> can't do and to try to make as many of our lessons learned available
> to others as possible

I think we should also talk about the goals and uses that CVE
addresses, and reinforce the value to defenders of having the
concordance functions.  The reason that there's tension is that
there's value, and we should look for ways to make those explicit.

Adam

On Fri, Mar 09, 2012 at 10:07:08PM +0000, Mann, Dave wrote:
| Kent et al,
| 
| Summarizing my take on the situation...
| 
| 0) People use vulnerability data for statistics at their own peril.
| 
| 1) CVE cannot solve the global vulnerability reporting problem.  We can be a part of the solution, but not *THE* solution.
| 
| 2) To think clearly about the global vulnerability reporting problem and CVE, we need to think about "sources" of vulnerability disclosures and who is going to process which sources.  The analogy here is: sources are to vulnerability reporting as jurisdictions are to law enforcement.
| 
| 3) We, the CVE community, need to finish our discussion on which sources CVE will cover. And we will need to discuss how fast and how accurately those sources are covered.
| 
| 4) Once we agree on which sources need to be covered, and how fast and how well, then we can talk about ways to close any gaps such as resources, process improvements, expanding the CNA process and crowd sourcing.
| 
| 
| More verbose ramblings on these points follow...
| 
| 
| 1) GLOBAL VULNERABILITY REPORTING - In my opinion, one thing that CVE cannot do is solve the global vulnerability reporting problem.  This was my position in the global vulnerability reporting discussions last fall and my convictions in this regard have only solidified based on discussions with Carsten at Secunia, more detailed discussions with the folks at JP-CERT and others in the international community.  The sets of vendors/products in play are too different, the relationships between software vendors and various national governments are too different, and of course, the language barriers are too big.  The discussions of the past 2 years on this subject have led me to conclude that when the CVE community set our goal of "all publicly known vulnerabilities" 12 years ago, we did so naively and with an incorrectly parochial view of the global software market.  There may or may not be a good solution to the global vulnerability reporting problem.  But one thing I'm very sure of is that this solution, if it exists, will need to evolve organically by knitting together various regional capabilities.  
| 
| I think the best thing that we, the CVE community, can do to help facilitate the emergence of a global vulnerability reporting capability is to be able to speak clearly about what we can and can't do and to try to make as many of our lessons learned available to others as possible.  
| 
| 
| 
| 2) VULNERABILITY SOURCES - We've talked internally at great length on the subject of vendors, products and sources.  We've also talked a bit about this as a Board.  In my opinion, we'll drive ourselves bonkers if we talk about vendors and products.
| 
| The goal of law enforcement isn't to catch bad guys.  It's to create and sustain a law enforcement system that can effectively catch bad guys.  This is a critical distinction.   The first results in cops with guns running around pursuing bad guys with no regard to coordination and jurisdictional boundaries.  The latter takes seriously the idea of jurisdictional boundaries and uses this to create command and control systems to operate effectively within those boundaries.
| 
| In my opinion, we need to think in these terms regarding vulnerability reporting.  The only somewhat stable structure I can see that does this for us to think in terms of "sources" of vulnerability information.  So, instead of thinking about vendor X or the list of products produced by vendor X (all of the internationalized variants), we can talk about the English-based security bulletin web site run by vendor X.  That web site can be on the list of sites tracked by CVE or not.  The set of sources tracked by CVE become, effectively, CVE's jurisdiction.   This is the discussion we, as a Board, started last fall.
| 
| I can hear the groans of complaint already.  Vulnerabilities don't stay on a single set of sources.  Absolutely true.  In the same way, criminals don't stay in a single jurisdiction.  But we can't organize a police force around a single type of criminal or a particular gang and I see no way to structure a CVE-like capability around a set of vendors or products.   If other CVE-like capabilities emerge that can handle other sets of sources (different jurisdictions), I suggest we'll have to deal with vulnerabilities that cross jurisdictional boundaries in the same way that law enforcement types handle it.
| 
| If people can suggest other better ways to define jurisdictions (or swim lanes) I'm all ears.
| 
| 
| 3) CVE COVERAGE - This past fall, we had discussions on the Board list about what sources you all felt were "must-haves" and those you considered "nice-to-haves".  We're processing this internally and are considering what sources we're actually covering, to what extent and how fast.   We hope to present a summary of that in the next little while and I further expect that the summary will highlight some important gaps between our expectations and the realities.  We'll have more to talk about at that point.
| 
| In preparation for that discussion, I'll quote the sign that hangs on Steve Christey's office door.  Vulnerability IDs - Pick 2: Good, Fast, Cheap.
| 
| We'll need to talk about each of these dimensions more.
| 
| 
| 4) EVOLVING THE CVE PROCESS - The CVE ID assignment process has evolved over the past 12 years and will continue to evolve.  Once we gain some clarity on which sources we need to cover, how well we need to cover them and at what we speed, we as a community can discuss what, if any, changes are required of the current CVE production process. I believe that everything can be put on the table for discussion at that point, but we really need to agree on the goals in terms coverage.
| 
| 
| 0) STATISTICS - Statistics require stable social categories and stable social categories require stable shared practices.  I'm not going to shock anybody by suggesting that security practices in general, and vulnerability practices in particular are not stable.  In short, our field is too young.   
| 
| The best book on the subject that I know is "Standards and Their Stories: How Quantifying, Classifying, and Formalizing Practices Shape Everyday Life" by Lampland and Star.  The discussion of how "calendar age" became a standard in everyday life and how the age classification processes of the US census bureau evolved is particularly germane to the question of vulnerability statistics.   
| 
| I have no idea how to communicate this sort of troubling truth to upper management types but strongly suggest the book to everyone on this list.  You can thank or blame TK when you see him next.  He's the one who suggested it to me.  ;) 
| 
| 
| -Dave
| ==================================================================
| David Mann | Principal Infosec Scientist | The MITRE Corporation
| ------------------------------------------------------------------
| e-mail:damann@mitre.org | cell:781.424.6003
| ==================================================================