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