> > can somebody tell me wat is the definition of > > Not quite, RISKS classify the severity of a vulnerability. The security notes/warnings/hole do too, but to a lesser extent. I research this a couple of months ago, you can find more information at my website: http://www.rit.edu/~wjh3710/plugin_stats.html
I like the page you put together.
I notice you compiled a risk rating scale (quoting Renaud in 2000). I'm concerned about this 6 point scale (none, low, medium, high, serious and critical).
Stictly, considering that risk cannot always be completely eliminated "none" may not be realistic. However, an item Nessus flags could be informational considered no risk (or requiring human analysis).
Serious includes information disclosure. Although important, I feel this is too high a rating considering the lesser rating of High covers "executing arbitrary commands". From a system/OS perspective (discounting the classification of any other information that may reside on the system), disclosing system configuration (read-only) is less serious than modifying system configuration or running unauthorized commands/programs. If "serious" refers to disclosing authentication data like passwords it should be explicitly stated.
My primary beef of Nessus is the use of "Note", "Warning" and "Hole". I don't feel the terms are clearly defined or consistently applied. Even if they were, I think a risk rating and vulnerability type/family/classification (such as from Aslam or Krsul) would be more useful.
Mitre combines vulnerability and exposure and makes no effort to differentiate between them. Some may argue finger or SNMP discloses information that could be useful to an attacker. However, these applications may be working as designed/intended so Mitre does not diffeentiate or debate wether it's a vulnerability or expousre.. but agrees it's one of them.
I'm not a hardcore programmer, but if you want any help from a documenation, design, or strategy perspective please let me know. I have been doing alot of research lately on designing an open and collaborative vulnerability database. This has involved considering the data base schema to be used and clearly defining risk ratings and vulnerability classifications. There are aspects of NIST's ICAT database schema that I like combined with risk and classification guidlines used by SANS, ISS and Symantec/SecurityFocus.
Some of what I'm talking about may not even require modifying NASL2. The current work being done to have the Nessus server save scan results directly to MySQL includes a DB schema. The early scripts I believe parsed all the NASL scripts into a separate table of the database. This table does not affect the scanning. The table could be extended to include this static information about each plugin. The table that contains scan results uses only the plugin ID which correlates with the details found in the plugin table.
I do feel a guide on assigning risk and classifying the vulnerability is required for programmers to maintain consistency of the plugins. This would improve understanding and decision making of people who rely on these ratings and classifications.
When I have the time, I'm going to design some crystal report templates to query this new Nessus DB schema. If anyone knows what reports they use on a regular basis (technical, security manager and executive level) please let me know. If you have sample reports that you've designed you can forward to me so I can start a list of reports to work on. Or, if you just it scribble down in any form what you think would be useful please forward to me.
Regards, Brian
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
