Re: families

Michel Arboi wrote:

>Erik <[email protected]> writes:
>
>  
>
>>What about removing the restriction for a plugin to belong to only one
>>"family"?  Instead of a 'family' field, how about something like a
>>'keywords' or 'families' field
>>    
>>
>
>This has been discussed. That looks like a good idea but need some
>changes in the core product (and the protocol?)
>  
>
I think ultimately a flat one-to-one grouping mechanism for plugins is 
going to be prone to the same ambiguities and overlap that you're seeing 
now.  Reassigning the plugins to a new list of families is still 
worthwhile, because the current list could be improved...but it won't 
really enhance the overall product.

If the changes would be significant, would it be possible to introduce 
Erik's idea as something new and maintain the existing families as a 
legacy holdover for backwards compatibility?

>Anyway, we should decide what families are used for. I think they are
>good to select or unselect a set of plugins.
>Apart from DoS (which could be removed by an enhanced safe_checks, as
>I said), I think that families are useful to find and enable or
>disable a specific plugin, or to select a whole set, e.g Windows or
>HTTP & CGI
>  
>
I think the answer to this question will make the development of a new 
list of families much easier.  However, because of the technical 
limitations of families, you can really only have one purpose.  Any more 
than that, and it becomes complicated.  What if you have a plugin that 
uses default account credentials to execute an HTTP query against a 
sample application to enumerate EJBs in a remote container through JNDI, 
possibly killing it in the process?  Obviously a rediculous example, but 
this plugin works over HTTP, exploits default passwords, uses a sample 
application, tests JNDI security and ultimately just gathers information 
in a manner that could potentially kill the service(s).  You could pick 
a family for this plugin, but there aren't really any that serve it 
best, which is probably why we currently have a set of families that are 
somewhat orthogonal.

A family, right now, is just a single valued property of a plugin...the 
grouping function of families is done through a function of searching 
those properties for equal values.  Extending that idea, would it be 
difficult to implement a generic plugin properties model, one that is 
typed, supports multi-valued and/or nested attributes?  Using this 
approach, you could implement arbitrary plugin groups like Erik was 
after above, for the purpose that Michel proposes for families (grouping 
plugins for execution).  You could then group plugins by creating simple 
queries against these properties...i.e.:

- Plugins that work over HTTP. (PROTO == (HTTP || HTTPS))
- Plugins that attack IIS. (APP == ".*IIS.*")
- Plugins that address a SANS Top 20 issue (SANS20 == TRUE )
- Plugins that could kill the service. ( DANGEROUS == TRUE )
- Plugins that are designed to kill the service. ( DOS == TRUE )
- Plugins that are really only useful if you have credentials. ( 
REQCREDS == TRUE )
- Plugins that have a CVE associated with them ( #CVEID > 0 )
- Plugins that check for HIGH severity issues ( SEVERITY == HIGH )

You could also implement something that i've been yearning for.  Some 
type of model that helps reflect the maturity/quality of a plugin so you 
can run wide open on test environments, but be more cautious in 
production/customer environments (consider the sourceforge 'development 
status' model)

- Plugins that are stable (DEVSTATUS == STABLE)

The other aspect of this, though, is that additional properties can help 
on the reporting side of things.  It takes some effort to get at the 
information that is contained in the default output of reports.  Most of 
the time, it's nothing big (having to parse a list of CVE-IDs, using 
regexes to extract data from recommendations in the info), but it slows 
the process and can be problematic.  Being able to directly access a set 
of typed properties for each plugin, possibly including associated KB 
entries/etc, would make it much easier to fold and spindle the output 
into things that are useful for a given purpose.  Looking at 
vulnerability databases such ICAT and OSVDB, there are several 
potentially useful properties of a plugin that could be added directly 
to the plugin, or indirectly by reference to the associated db.

- Vulnerability Type - Buffer Overflow, Race Condition, etc
- Attack Scope - Local, Remote
- Loss - Availability, Confidentiality, Superuser Access, Process User 
Access
- Known Exploits - True/False (or URLs)

This whole generic properties thing could be bunk, and is probably a lot 
of effort for minimal return, but i think if we're considering going 
back through and touching each of the nearly 2100 plugins that are out 
there now, it'd be good to get the most bang for the buck.

My $.02.

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