Re: Sources: Full and Partial Coverage

[Damir Rajnovic <gaus@cisco.com>]

Hi Adam,

This is interesting situation you are describing. Here is how I see a potential
scenario being played out. We select to cover products and SHINY is one of
them. To get vulnerabilities in SHINY we select Contagio as the source.
Things are working fine but Contagio is also providing information about
other products that are not on our list. The question is what to do with
this extra information? Is this what you are trying to illustrate?

Regarding treating exploit kits as products - they are products. If there is 
a vulnerability in the SW _itself_ it may get CVE assigned. The confusion
may arise if we are using that product as the information source so we
may want to assign a CVE to a vulnerability being described within the
exploit kit. To me, these two facets (product vs information source), are
orthogonal and should not be mixed. We can treat a product as an information
source. After all, a mailing list can be seen as a product (ok, ok - service,
like google) and we use it as information source without even thinking
about it. In the case of exploit kit the things are just more explicit but
the principle is the same.

Gaus



On Mon, Jun 11, 2012 at 12:07:02PM -0400, Adam Shostack wrote:
> Sorry to come back into this discussion late.  I'd like to share a
> recent use case where coverage by product would have been
> insufficient.
> 
> My goal was to study how computers become compromised.  As a proxy for
> one subset of that, I was using the Contagio "overview of exploit
> packs" [1].  Foreach element in that list, I was investigating when it
> became publicly known, when it was patched, and several other
> properties of the vuln and the update.
> 
> The searches for which I had CVEs took me 5-10 minutes per CVE.
> Several of the ones for which I didn't have CVEs took between 2 hours
> and failed to finish.
> 
> The vulns exploited by exploit packs are selected by the authors of
> the packs, with a goal of compromising a large number of computers.  I
> don't believe any product-centered view of the world would be
> sufficient.
> 
> We could, perhaps, define this work as outside the goal of CVE, but I
> think that might be putting a patch management goal above a vuln
> management goal.  We should not do that accidentally, nor do I think
> it's a good prioritization.  We could work around it by adding things
> like exploit kits as 'products', but I believe that stretches the
> definition of products that most people here seem to have in mind.
> 
> Adam
> 
> [1] http://contagiodump.blogspot.com/2010/06/overview-of-exploit-packs-update.html
> 
> On Mon, May 21, 2012 at 02:35:39PM +0100, Damir Rajnovic wrote:
> | Hi,
> | 
> | No, not really. By definition CVE is the best effort project. It is so
> | because we rely on others (i.e., vendors, researches) to provide the information.
> | Until we have vendors comitted assigning CVE themselves that will continue
> | to be so.
> | 
> | Estimating how many vulnerabilities are not covered can also be questioned.
> | Some vendors may quietly fix things and never admitting that fact. Would
> | you count that as lack of coverage? I would _if_ I manage to establish that
> | this really happened. What are other ways that vulnerability may 'escape'?
> | 
> | The bottom line is that I am a pragmatist and will take what there is available
> | to get the job done. If we cannot reliably estimate coverage I would still
> | use CVE.
> | 
> | Gaus
> | 
> | 
> | On Fri, May 18, 2012 at 12:51:56PM -0500, security curmudgeon wrote:
> | > On Fri, 18 May 2012, Damir Rajnovic wrote:
> | > 
> | > : 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.
> | > 
> | > Does your answer change if the percentage cannot be answered with any 
> | > certainty at all?

==============
Damir Rajnovic <psirt@cisco.com>, PSIRT Incident Manager, Cisco Systems
<http://www.cisco.com/go/psirt>      Telephone: +44 7715 546 033
300 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