--- Paul Johnston <paul@westpoint.ltd.uk> wrote:
Hi Jon,
Interesting thoughts. There is certainly some scope for doing
structured
risk ratings in a vul scan tool, but the devil is in the detail.
Some
thoughts I had:
1) "likelihood" or "threat" is a two-dimensional quantity. One
dimension
is how skilled an attacker must be, the other is how "noisy" the
attack
it, and how many factors are relied on. For example, brute force
password attacks can be done by any script kiddie, but are very
noisy
and easy to see in the logs. Conversely, exploiting a buffer
overrun (no
public exploit) requires a skilled attacker, but would otherwise
be
quite easy to sneak in. Something to consider: the release of an
automated tool can instantly move a threat from skilled attacker
to anyone.
Something to consider: How do things change if your systems are
protected by an IPS which will block "all known viruses and
attack tools"?
As you know, detection != prevention. Nessus is a tool that can
test either or both (and verify correction sometimes). Nessus
itself can usually be the stimuli to test detection issues, but in
my opinion it focuses more on prevention.
2) A vul scan tool has more info than a vulnerability database.
For
example, sometimes there are potentially very serious
vulnerabilities
that are rated as low/medium, because the default configuration
is not
exploitable. Now, a vul scan tool (ideally) can tell if the
actual live
running config is vulnerable or not, and adjust the risk rating
accordingly. Of course, vulnerable software with non-vulnerable
configuraiton is still a worry (someone could change config at
any time)
but the risk is certainly reduced.
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). 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.
Ultimately I expect this won't be implemented because it's a lot
of work
and too easy to get wrong. Also, consultants who run vul scanners
need
to do value-add somehow, and this is one of the most promising
avenues
to explore.
It's already in Nessus, it's just not formal (Security Note,
Warning, Hole - Risk Information, Low, Medium, High, Critical).
I'd like more of a science around it, and I think Nessus can
provide objective information most of the time. When Nessus tells
you that there is a Security Warning/Hole and it is High risk, it
has made an impact statement. I would like Nessus to tell me the
attributes that got it to a High risk so I can map them against my
own mappings. If you don't like Nessus's rating, then roll your
own! That should keep discussions down to better logic :)
I honestly would like this to occur and would spend hours
contributing code. I've made a couple small contributes already
because I wish to make this great tool even better. As for value,
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
what are the business and IT asests. I've uncovered bank vault
codes on basic workstation because PC Everywhere [sic] was
installed. How would the tool figure that stuff out? Sometimes
computers just can't replace warm bodies (since we're the ones
causing the issues ;)
Interesting URL to read about bike sheds, definitily something to
bear
in mind. However, in this case I think your suggestions is closer
to
building a nuclear power plant!
Heh, I'm happy you enjoyed the link. If it is a nuclear plant,
then I hope more people ask questions!
Jon
Best wishes,
Paul
Jon Passki wrote:
Hello,
I hope not to start a bikeshed [1] about a discussed topic, but
offer a way to extend Nessus to allow risk ratings without
upsetting the status quo. Please do everyone a favor and think
about the thousands of people that will receive your response
_before_ you send it (I have already). I follow this highly
generalized risk rating method:
--) What does the vulnerability need to be exploited
(likelihood)
--) What does the exploit (possible or actually done) return or
produce? (results)
--) Do I or does the 3rd party care? (impact)
This can refined even in greater detail by weighing the
information
w/ accuracy (banner grab versus actual exploit), correlation
with
other exploits, and related in terms of confidentiality,
integrity,
and availability. I'm sure there's more that I'm missing.
Anyway...
The first two questions (three if you're counting question
marks)
can be described by the person creating the plugin and possibly
enhanced/refined/debated-at-great-lengths in the future. The
third
will never be answered by someone that does not know the
systems.
Even if I have a little bit of experience with the systems, I do
not volunteer such opinions unless asked.
Would Tenable/Nessus consider committing a framework that allows
this information to be assigned to a vulnerability? One
implementation could be a plugin setting a local KB object
listing
the likelihood (e.g. requires local access, non-default
configuration, requires non-anonymous account, etc) and return
(e.g. host name discovery, account name discovery, configuration
information). Then the knowledgeable person that knows the
systems
can rank the general impact (e.g. host name retrieval is
'informational'; configuration retrieval is a 'low' risk).
Maybe the risk ratings I picked are not the best, but let's save
that discussion _after_ someone from Tenable/Nessus thinks it's
even worth importing. There would be a lot of work afterwords
to
do (retrofit plugins, documentation, etc.) outside of the work
to
get it done (nessusd changes, etc). But the advantage is that
neither Tenable/Nessus nor the plugin authors are responsible
for
assigning a risk that includes impact. And if it's deemed
important to have some impact rating (I'm a CFO, tell me what I
need!), there could be a default one that is easily
configurable.
From my understanding, Nessus uses a severity rating and risk
factor. The severity rating includes impact as is (e.g.
retrieval
of a password is a 'high' severity). The risk factor is
likelihood,
but is not formal. Likelihood isn't really consistent across
multiple plugins and the elements that define the likelihood for
each plugin are not always enumerated. The severity rating and
risk factor labels could stay the same. It's the information
and
framework that feeds these labels that would be changed/created.
So, Tenable/Nessus, is this something that would be
imported/created? If so, let's discuss the architecture! I'm
ready to start giving this a shot and giving up some nights :)
Jon Passki
[1]
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
--
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!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
