> From: WILLIAM HEINBOCKEL [mailto:wjh3710@osfmail.isc.rit.edu]
> Sent: Sunday, January 05, 2003 4:20 PM
> http://www.rit.edu/~wjh3710/plugin_stats.html
> ... The stats were surprising and lead me to believe that the
> vulnerability levels need defined.
William, thanks for analyzing those risk levels.
I recommend that risk levels be assigned numeric scores from 0
(for low-risk info like traceroute) increasing as vulnerability
worsens. I don't care what the max value is, 6, 9, or 100.
A plugin might indeed kick out two numbers, a risk score which
focuses on the worst case, and a false-alarm fuzz-factor.
This kind of scoring--approximate and faulty though it may be--
helps in situations like mine where I must prioritize attention
to 15,000 plus devices.
I kludged a post-processing script that maps NSR text
risk factor ("None" to "Critical") and selected plugin IDs to a
priority number 0 (info like traceoute) to 9 (already compromised).
I calculate for each system its largest risk score 0-9. I also
find its total score which can be up around 200 or 300.
I modify a plugin risk score based on factors outside the scope
of that one plugin. In my post-processing, Plugin 10350 "Shaft" I
initially assess as level 9, Extreme Badness.
But Shaft is a Unix affliction. If nmap reports an OS guess of
"Windows" or "HP Printer" and that guess is verified by port 139
or 9100 being open, then I reduce the plugin 10350 score to level 5.
Not lower; the OS guess might be wrong, and it really is a Unix box
with Shaft. Thus I avoid losing credibility as a security analyst.
Meanwhile, I feel guilty for not carefully investigating a possible
false alarm and improving plugin 10350.
Some existing categories such as "Security Note" and "Low Risk"
can indeed be combined. In my experience, refining assessments
especially in the "High" range is desirable. In that spirit,
I initially assign "High" risks to a score of 7. I found that
the word "write" in English plugin results, especially for SMB
plugins, indicates a writeable filesystem or writeable registry
in addition to other badness. So I increment the plugin risk
score up by 1. If the plugin mentions a possible "false positive",
the score decrements by 1. This is voodoo, but so far this spread
has helped me statistically attend to the most needy systems first.
In short, a better way would be for plugin writers to carefully
adjust the risk score depending on factors that mitigate or worsen
the exposure.
System scores and other refinements drawing on results of multiple
plugins could be calculated by a final plugin instead of post-processing.
Instead of adjusting plugin score as my post-processing now does, one might
accumulate "false alarm" credits against the total. Or a plugin might
yield a score and a fuzz factor. In any case, if plugins would at least
yield a numeric score, rather than just "Low", "Critical", etc. that
would help those of us dealing with large quantities of systems.
-- Greg Johnson, University of Missouri