RE: Vulnebrability level definition

From: Rob Shein (shotenat_private)
Date: Thu Feb 13 2003 - 15:52:16 PST

  • Next message: Romes, Randall J.: "MS Office Files"

    Yes, but that's a matter of the importance of the asset in combination with
    the impact of the vulnerability.  A root compromise of a database that holds
    credit cards is a different impact than a simple DoS of the same database.
    For this reason, there is a need of a rating for the vulnerabilities
    themselves.  You can't just say "oh, this is an important system so any
    vulnerability to it will have maximum impact," even though that may be a
    tempting thing to do.
    
    > -----Original Message-----
    > From: Damir Rajnovic [mailto:gausat_private] 
    > Sent: Thursday, February 13, 2003 5:44 AM
    > To: pen-testat_private; security-basicsat_private
    > Subject: RE: Vulnebrability level definition
    > 
    > 
    > At 13:33 12/02/2003 -0500, Rob Shein wrote:
    > >I disagree.  The question isn't the severity of the compromise, but 
    > >rather the severity of the vulnerability.  Many factors come 
    > into this, 
    > >such as the ease of exploitation and frequency of attempted 
    > >exploitation.  A good
    > 
    > The vulnerability of a product must be put into a perspective 
    > of your organization. My guess that the whole point of this 
    > rating is so that customers can prioritize their work an 
    > decide if they need to apply the patch (or the workaround) 
    > right now or it can wait until the next week. Is that so or 
    > not? If it is so, then you also must take into account where 
    > and how you are using that vulnerable product. If you are 
    > using this product as a part of your critical infrastructure 
    > then you may have 1:1 mapping of the advisory rating and 
    > importance to you. If you are mixed environment and using 
    > many different products then it is not that straightforward. 
    > Yes, a vulnerability may be grave by 
    > itself but, the way how you use this product may mitigate the danger. 
    > 
    > >example of a severe bug would be the unicode exploit on IIS; no 
    > >firewall can mitigate it (without voiding the point of the 
    > web server), 
    > >anyone with a browser can exploit it (no need to know 
    > offsets or write 
    > >shellcode, it's the
    > 
    > You are assuming that IIS is the one running a publicly 
    > accessible server. If IIS is used in some remote office deep 
    > within you organization then it is less exposed. Thus, one 
    > may not rush to patch this vulnerability but wait some time.
    > 
    > >In risk management, we think in terms of likelihood of 
    > occurrence and 
    > >impact of event.  Certain vulnerabilities are more likely to be 
    > >exploited than others, and some are worse than others, so 
    > these factors 
    > >need to be considered before someone can even begin to try to manage 
    > >the risks.
    > 
    > Agreed. There are few examples where a vulnerability may look 
    > like a hard to exploit until someone make a script. I do not 
    > know how many vendors will go back and update their rating. 
    > Even worse, how many customers would know that the rating has 
    > been changed? Anyway, you are applying information about the 
    > vulnerability to your environment and then making decisions 
    > how relevant and important it is to you. This is something 
    > that only you can do. Vendor can not do that for you.
    > 
    > Anyway, my point is that severity of the vulnerability is not 
    > automatically the priority of how fast you need to apply 
    > fixes. For that reason I do not believe that assigning 
    > severity to an advisory gives you much. The advisory must 
    > contain enough information that will enable you to make your 
    > own decision how severe it is in your environment. 
    > 
    > Gaus
    > ==============
    > Damir Rajnovic <psirtat_private>, 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? 
    > 
    > 
    > --------------------------------------------------------------
    > --------------
    > This list is provided by the SecurityFocus Security 
    > Intelligence Alert (SIA) Service. For more information on 
    > SecurityFocus' SIA service which automatically alerts you to 
    > the latest security vulnerabilities please see: 
    https://alerts.securityfocus.com/
    
    
    ----------------------------------------------------------------------------
    This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
    Service. For more information on SecurityFocus' SIA service which
    automatically alerts you to the latest security vulnerabilities please see:
    https://alerts.securityfocus.com/
    



    This archive was generated by hypermail 2b30 : Fri Feb 14 2003 - 08:49:38 PST