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:[EMAIL PROTECTED]] > Sent: Thursday, February 13, 2003 5:44 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]>, 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/
