RE: families

>What do people actually use the plugin families for?
I'll interpret this as what would I like to use plugin families for.

a) Enabling or disabling a whole group of tests because of potential side
effects.

I'm really looking for a finer classification than "dangerous plugins", as
the "big switch" isn't always good enough. For example, "will cause DoS on
vulnerable systems", "might kill service if running on early xyz operating
system", "might send output to vulnerable printers" are options that I might
select or deselect depending on purpose of tests. 

b) Disabling tests not relevant to the type of system

The main objective is to get more accurate reports, e.g. don't report Tomcat
web problems on an IIS box. That doesn't help the credibility of the reports
when passed to our IT guys. Yes, really this should be part of Nessus core
and automatically handled by the optimisation, but it's not always so.
The second objective is to speed up the testing, by not applying router
tests to windows systems, etc. Not as important as the system information is
not always accurate.

c) Making the plugin selection options manageable

Fundamentally having sufficient number of categories - not so few categories
that the plugin lists are too long, not so many that they only contain a
small number of items (like current NIS category). I seem to remember
usability studies for menu systems (remember Prestel/Viewdata?) concluded
that around 10 items at each hierarchy level was about right - maybe p to 20
with modern screen sizes. An extra hierarchy level could be effectively
added if plugin names were sorted into alphabetical order, and some naming
consistency were imposed.

d) Selecting vulnerability severity

I'd sometimes like to filter out the inconsequential informational items.
Things like "traceroute info", "digital cert info". So an "Info only"
category would be nice. I suppose this is the converse of the request for
SANS top 20, which is looking for "most severe", though personally I'd like
to know about any severe items, whether or not they were in SANS' list.

e) Selecting by service

On occasion I'd like to select by the TCP service. So far, I've only needed
this when trying to find which plugins test which services - in other words
I don't need to select "all HTTP" for an actual test, just like to know all
the HTTP tests and to find the plugin code for a specific vulnerability.
Actually, rather than using families for this, I'd really prefer more
consistency in the plugin filenames and descriptions - and for the client
and reports to list filenames as well as descriptions. The sort of
consistency would use names like <proto>_<platform>_<vuln>, such as
http_iis_dir-traversal.nasl.

Andrew Yeomans


--------------------------------------------------------------------------------
The information contained herein is confidential and is intended solely for the
addressee. Access by any other party is unauthorised without the express 
written permission of the sender. If you are not the intended recipient, please 
contact the sender either via the company switchboard on +44 (0)20 7623 8000, or
via e-mail return. If you have received this e-mail in error or wish to read our
e-mail disclaimer statement and monitoring policy, please refer to 
http://www.drkw.com/disc/email/ or contact the sender.
--------------------------------------------------------------------------------

_______________________________________________
Nessus-devel mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus-devel