RE: Sources: Full and Partial Coverage

["Williams, James K" <James.Williams@ca.com>]

I believe that Harold has brought up a very important point. For the reasons outlined by Harold, and also by Mark Cox in a previous email, a "product-centric" approach makes much more sense than a "vuln-source-centric" approach. When managing vulnerabilities for 3rd party components/products used in our products, we do not limit ourselves to a set, limited list of vuln sources. 

Instead, we also monitor: 
* each 3rd party vendor site
* ALL vendor mailing lists and forums
* vendor support sites (even if hidden behind a login)
* ALL other sites, blogs, forums, mailing lists, using appropriate search queries via google, bing, marc.info, etc
* all of the major vulnerability sources (bugtraq, full-disclosure, Secunia, X-Force, CVE, etc etc)

Consequently, CVE would be much more useful for us if coverage was product-centric, and ideally if that product-centric coverage included ALL of the 3rd party components/products used in our products.

We do also of course obtain CVE identifiers for ALL vulnerabilities, disclosed by us or by others, in CA products.

Thanks and regards,
Ken


-----Original Message-----
From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Booth, Harold
Sent: Wednesday, June 13, 2012 1:53 PM
To: Mann, Dave; cve-editorial-board-list
Subject: RE: Sources: Full and Partial Coverage

Harold Booth wrote:
>Dave has stated that this discussion is about what the scope for CVE 
>should be. As I review the discussion it seems the focus has been 
>predominately on what sources should be covered. I think the focus of 
>the discussion should be on what products should be covered.

Then Dave Mann replied:
>I think we are very close in our thinking and would suggest this is a 
>both/and situation, not an either/or one.

<elided text>

>A list of "must-have" products won't eliminate the need for us, as a 
>Board, to come to agreement on the question of sources.  Too many 
>products require more than one source to adequately track.  And we 
>clearly need to track some sources because they alert us to critical 
>vulnerabilities that occur in products that won't make a "must-have"
>product list.

I recognize that my suggestion to scope CVE on products may seem equivalent or duplicative to a scope of focusing on sources, but I strongly believe that talking in terms of products leads to a different way of thinking about how to manage the CVE dictionary than talking about sources does. I don't think the CVE dictionary should be about "vulnerabilities found in this list of sources" but instead should be about "vulnerabilities found in this list of products." From my viewpoint I see the discussion about sources as a discussion of "how to" acquire vulnerabilities to be added to the CVE dictionary, while a discussion about products is a discussion on what vulnerabilities will be included. As I quoted before, "What gets measured, gets done," and I think product coverage should be the measure of success for the CVE dictionary and not source coverage. I don't believe for a second that all the vulnerabilities for all products in the product list will ever make it into the CVE Dictionary, but I do think that should be the stated goal. Additionally, I think the product list should act only as a guideline, and if an important vulnerability is discovered that needs to be included, but applies to a product not included in the list, then by all means it should be included.

Before going further, it is important to state that implicit in my argument is the assumption that a vulnerability will always be related to one or more products. Given that a vulnerability is defined by the CVE initiative as "a mistake in software that can be directly used by a hacker to gain access to a system or network," I don't think this is an unreasonable assumption.

As I indicated in an earlier email, the product list could, where necessary, be more fluid than specifying Product A, Product B, Product C, etc.., and could be framed in terms of important attributes of the products themselves. For the case where a source is considered important enough that any vulnerability identified by the source should be added as a CVE entry, a sort of catch-all entry in the product list could be: 

"All product vulnerabilities identified by Very Important Source A for those products not previously included in the product list."

Another possible entry could be:

"All product vulnerabilities which have been exploited for those products not previously included in the product list."

An additional benefit to a product-centric view is that downstream users of the CVE Dictionary will have a better idea of what they are getting. Currently, as a downstream user I would need to go visit each and every source, and determine what their product coverage is in order to discover this information.

Finally, at the risk of expanding the discussion beyond the currently imposed guidelines, my proposal was sparked by some of the messages regarding partial vs full coverage of sources, scaling of effort, additional funding, etc... I think that if the CVE dictionary is scoped in terms of products the "how to" for accomplishing the goal of product coverage will likely look different from the "how to" for source coverage. To go a step further, I think some of the issues being experienced by the CVE effort are a result of a focus on sources instead of products. As an example, if the focus were on products, there would likely not be a discussion of partial vs. full coverage for a given source since products are the thing that are of interest. (I would hope that discussions of partial coverage of a product would not occur.) If products are the focus, CNAs can be "assigned", scoped to work on, or volunteer for a given set of products. This would allow for a greater emphasis on bringing in CNAs, educating them, allowing them to be more independent in terms of CVE creation, and held accountable for the CVEs they do create. It seems to me that CNAs are more difficult to manage in a source-centric view since a vulnerability may appear in multiple sources, it is not as clear-cut who does what, and a central authority is necessary to manage every CVE. I recognize that what I am suggesting is different from the way things are done, but I don't think what is being done now is meeting all of our needs or is sustainable in the long run. I also understand that even if a product centric scope is agreeable to everyone that it will take time to make the necessary process changes, and stand-up the necessary infrastructure. I don't think there is a "quick-fix" and that defining everything in terms of products will make everything simple; new problems will manifest that are not experienced now, but intractable problems now will at least have a practical solution. I have lots of ideas on "how to" make this sort of solution work, but I ca
n save them for whenever that topic of conversation formally comes up.

Regards,

-Harold