--- Paul Johnston <paul@westpoint.ltd.uk> wrote:
Hi,
True. These are details which should be accounted for. I use a
ranking model that relates default versus non-default
configurations as part of likelihood (along w/ known or unknown
exploit/POC).
Ok, I'd be interested to know more about your model and how you
developed it. If the risk rating is lessened to account for
"default
config not exploitable", how does this hold up when a vul scan
demonstrates an exploitable configuration is in use?
Those fall under likelihood. If you've proved that the likelihood
is certain (you performed the exploit), then in my model it gets
the highest ranking (for that specific instance). In general,
though, the vulnerability uses a non-default configuration (library
compiled in, switch toggled in config file, etc). Think of it like
an object, with your tests being specific instantiation of the
object. The attributes will probably change with the instantiation
(especially if the impact is not provided), and in this case the
likelihood became certain.
Other ones to think about would be remote versus
local, user account needed versus anonymous/no account, etc.
There
will always be vulnerabilities that are hard to describe. This
is
not trying to create a taxonomy for vulnerabilities; this is
trying to detail the risks a bit more. A bit more IMO would be
better than what's going on now.
Wise words... it is easy to get carried away on such discussions.
So,
lets think about what structured information we'd want for each
plugin:
Well, let's see if the Nessus project even wants to go down these
lines. If you are a committer or if there is a Nessus committer
currently following this thread, I'd like to know. Otherwise we
may have a very wonderful conversation with no goal on this list :(
Impact
Confidentiality/Integrity/Availability??
With this, both "server type & version" and "directory traversal"
would
be "confidentiality", probably not granular enough. And what
about SQL
injection? It's impractical to tell if this affects integrity
without
doing a manual audit. Something different probably required.
Class of Attacker
0 (anyone) -> 10 (NSA only)
Difficulty of attack
Requires:
users to be dumb? (e.g. phishing)
user interaction? (e.g. XSS)
credentials?
many attempts before success? (e.g. brute forcing return
address)
This one is very hard to get a handle on!
If you don't like Nessus's rating, then roll your
own! That should keep discussions down to better logic :)
Not sure that's particularly constructive, but anyway...
you can put the value in relating the objective issues
(likelihood
= remote; non-default configuration; no known exploit --
produces =
arbitrary access to the root account) to a company's subjective
setup (Low/Medium/High/Whatevr risk because blah blah blah). I
can't think of an automated tool that does that right now,
knowing
I think FoundStone has a quantitative/automated way of doing
this.
Perhaps you could get an eval license to take a look?
Regards,
Paul
--
Paul Johnston, GSEC
Internet Security Specialist
Westpoint Limited
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
England
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: paul@westpoint.ltd.uk
web: www.westpoint.ltd.uk
__________________________________
Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
http://info.mail.yahoo.com/mail_250
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
