mailing list archives
RE: Vulnebrability level definition
From: Damir Rajnovic <gaus () cisco com>
Date: Thu, 13 Feb 2003 10:43:32 +0000
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
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?
Re: Vulnebrability level definition Meritt James (Feb 12)
RE: Vulnebrability level definition Milton . Keath (Feb 13)
Re: Vulnebrability level definition Steven M. Christey (Feb 14)
Re: Vulnebrability level definition Per Niila Albinsson (Feb 14)