Re: Using a database as backend for Nessus (current state and volunteering for development)

Michael Boman wrote:

>Let's stop _talking_ and get down to action, shall we? I have not yet
>taken a look at the code itself, but this is a quick draft based on what
>XML_NG can do, with what people (might) want to be able to do..:
>
>This is psudo code!!!
>
>  
>
Ok. Before going in to the information that is introduced into each of 
the tables... why not talk about designing the overall schema? How about 
this one (adjointed, in raw form). Main idea is :

1- users run vulnerability sessions (it's important to keep track of who 
made what).
2.- sessions run plugins against a set of hosts (information available 
should include: start time/end time, session configuration: specified 
plugins, parameters...)
3.- vulnerabilities are associated to a given ExecutedPluginId (_not_ a 
plugin, see below) and might, or might not, discover information 
associated with it (which is kept in the plugin table, not separated).
4.- services are also detected by specific port-scan plugins (but might 
not be vulnerable in hosts in a given session).

The idea is that some administrators might want to keep track of how 
sessions have been executed: which plugins have been executed (the 
ExecutedPlugin entity has to hold also the version of the plugin), which 
hosts have been detected and which services are deemed vulnerable. This 
is why it's useful to separate plugin information (which BTW you can 
extract with 'nessus -qSp' or with the script I sent to the list), you 
don't need to duplicate plugin descriptions whenever a vulnerability is 
discovered. This also permits users to provide new translations for 
plugins by modifying the plugin table directly (or by introducing 
multiple language description cells)

Also, a given plugin might detect more than one vulnerability and these 
might/might not include information notes (banners et al). Separating 
also service discovery from other vulnerability information is done 
because, IMHO, this is one of the most important (and homogeneus) 
information a given plugin (portscanners) will provide. It's also useful 
to do an inventory of open services in the network.

Some other things you could do with this schema:

- keep track of which plugins (and specific revisions/versions) were 
executed against a given host. This allows admins to automatically rerun 
them whenever new plugins are added or a plugin has been updated. Also, 
since plugins are continously being added to Nessus it might be 
appropiate to differentiate when a vulnerability has been discovered 
when it was not previously there (but tested) and when it was discovered 
because a new plugin was added (or modified) that detected it.
- keep track of vulnerabilities associated with detected services.
- separate detected services (which might not be viewed as vulnerable 
since a plugin might not exploit them at the time of the run) from 
vulnerabilities. This allows for reports based on "seen services" in 
different sessions. Something on the lines of: 'which new services (open 
ports) have been detected on system X since the last run'.

Note that reports are generated _based_ on the information in the 
database. As such, they do not really need to be stored in the database 
itself (IMHO)

Regards

Javi


PS: I might have missed some of the discussion due to a mail server 
problem. Sorry.