Re: Sources: Full and Partial Coverage

[Damir Rajnovic <gaus@cisco.com>]

Hello,

On Tue, Jun 12, 2012 at 11:51:37AM -0400, Adam Shostack wrote:
> I don't see this as a justification for a product-centered view. If
> Shiny has 10 vulns, and only one has made an exploit kit, I have no
> use for the other 9 cves.  So it's an argument against a purely
> product-centered view.

As you said earlier "....vulns exploited by exploit packs are selected by 
the authors of the packs...." for a specific purpose. They may not care 
about the other 9 vulns but I, as system administrator, may care about
all 10 of them. Using a vulnerability to crash my box is useless for
an attacker who wants root access to the box so it may not end up in a exploit
kit. As a system admin I do care about acrash as it prevents my users
doing daily business so I would like to have CVEs for all 10 vulns
and not only one that made into the exploit kit.

Gaus



> 
> It is an argument that at least some level of source-cetricity may
> be useful, but that's probably not the only thing that can be taken
> from it.
> 
> Adam
> 
> On Tue, Jun 12, 2012 at 11:38:16AM +0100, Damir Rajnovic wrote:
> | 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