RE: Vulnebrability level definition

["Kohlenberg, Toby" <toby.kohlenberg () intel com>]

(all opinions are my own and in no way reflect the views of my employer)

While I agree that it would be good to take such things into account,
you've got to look at your ROI and level of available detail. Are you
really going to get that much more by saying "this low value database on this
system is being attacked but this high value one hasn't been _yet_" or
just saying "this system which contains high value data has been attacked"?

The additional level of information you need to collect and maintain for
that minimal increase in granularity is not small...

Just a thought.
toby

> -----Original Message-----
> From: Rob Shein [mailto:shoten () starpower net]
> Sent: Thursday, February 13, 2003 3:52 PM
> To: 'Damir Rajnovic'; pen-test () securityfocus com;
> security-basics () securityfocus com
> Subject: RE: Vulnebrability level definition
>
>
> 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:gaus () cisco com] 
> > Sent: Thursday, February 13, 2003 5:44 AM
> > To: pen-test () securityfocus com; security-basics () securityfocus com
> > 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 <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? 
> >
> >
> > --------------------------------------------------------------
> > --------------
> > 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 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/