[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sources: Full and Partial Coverage

Hi Gaus,

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.

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
Page Last Updated or Reviewed: November 06, 2012