Re: Sources: Full and Partial Coverage

[Damir Rajnovic <gaus@cisco.com>]

Hear, hear! Defining the goal in the scope of products is much better than
sources and I am saying this as a consumer of CVEs. I have a piece of SW
and I would like to know what is going with it. If the currently used sources
do not cover the product 100% then the workaround can be to publicly say
"we cover product X to an estimate 80% (or whatever)". That way CVE consumers
are told of the situation.

Gaus


On Thu, May 17, 2012 at 03:19:47PM -0400, Booth, Harold 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. While in some cases the terms 'sources' and 'products' have been used interchangeably I am not sure that they necessarily mean the same thing. A 'source' may change what products it covers over time, where the product that was desirable to be covered in that source may eventually get left off. I think if CVE were to define its scope in terms of products covered that would be far more useful than in terms of what sources it is covering which I view as an indirect measurement of products. I also believe that talking in terms of sources covered is presupposing a solution. If a product should be covered, then the goal of CVE would be to go identify one or more ways to obtain data about that product, as opposed to relying on a particular source. A focus on product would likely also lead to clarity on the question with what to do about a product composed of multiple components. If CVE were to say that "Red Hat Enterprise Linux 6" is covered, I think the expectation would be that all aspects of that product would be covered. To say only the 760 packages of a "default installation" would be covered is a little like saying that only the "Typical" installation of "Microsoft Windows 7 Home Edition" will be covered. I don't think either would be considered satisfactory.
> 
> In keeping with the focus on products I would like to propose that the scope for CVE be something along the following lines (I don't intend for this list to be comprehensive, just illustrative of what I am proposing):
> 
> Cover the top X Operating Systems
> Cover the top X(2) Desktop Applications
> Cover the top X(3) Mobile Applications
> Cover the top X(4) Networking Devices
> Cover the top X(5) Printers
> Cover the top X(6) Web Applications
> 
>  (Any other major category I probably missed)
> X(n) is a substitute for some number that is found to be agreeable.
> 
> In addition to the above, any additional operating systems, applications, hardware, etc... that MUST be covered, but may not necessarily show-up in the top X (i.e. perhaps a critical infrastructure item, embedded OS, security software, etc...)
> 
> Also cover any products outside the above that may appear in a pre-defined list of sources (i.e. US-CERT: Technical Cyber Security Alerts, Full Disclosure, OSVDB, SecurityTracker, oss-security, etc...)
> 
> The determination of what is the "Top X" for a category would be dependent on the category. There are always analytics organizations that are distributing lists of the most used Operating Systems so point at one of those sources and use that to guide which Operating systems should be covered and so on for the rest of the categories. The Apple Store, Android Marketplace, et al. could be leveraged for the various mobile applications. And where an easy to identify list is lacking then the board could develop its own list. For example the board will have to develop the list of additional products that MUST be covered.
> 
> Defining the scope in terms of the "Top X" would give the flexibility and coverage that I believe most of us want and need, keeping CVE relevant, and will hopefully only require occasional tweaking (as new categories are developed), instead of perpetual tweaking (when the next "DrawSomething" app comes out).
> 
> Based on the defined product list, CVE would cover any vulnerabilities for products that appear in this list, and the source (or sources) necessary to cover each product would need to be identified on an ongoing basis in order to ensure appropriate coverage.
> 
> To summarize, I think the scope of CVE should be defined, almost exclusively, in terms of products covered, and not in terms of sources covered.
> 
> Regards,
> 
> -Harold
> 

==============
Damir Rajnovic <psirt@cisco.com>, PSIRT Incident Manager, Cisco Systems
<http://www.cisco.com/go/psirt>      Telephone: +44 7715 546 033
200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
==============
There are no insolvable problems. 
The question is can you accept the solution? 


Incident Response and Product Security
http://www.ciscopress.com/bookstore/product.asp?isbn=1587052644


- - - -
Cisco.com - http://www.cisco.com/global/UK

This e-mail may contain confidential and privileged material for the sole 
use of the intended recipient. Any review, use, distribution or disclosure by 
others is strictly prohibited. If you are not the intended recipient (or 
authorized to receive for the recipient), please contact the sender by reply 
e-mail and delete all copies of this message.

Cisco Systems Limited (Company Number: 02558939), is registered in England 
and Wales with its registered office at 1 Callaghan Square, Cardiff, 
South Glamorgan CF10 5BT

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html