--- Paul Johnston <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> 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
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus
