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"?
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.
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.
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!
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 riskfactor. 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
[email protected]
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: [EMAIL PROTECTED] web: www.westpoint.ltd.uk
_______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
