Home page logo

basics logo Security Basics mailing list archives

RE: Vulnebrability level definition
From: "Rob Shein" <shoten () starpower net>
Date: Thu, 13 Feb 2003 18:52:16 -0500

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. 

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: 

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]