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
