On Wed, Jan 15, 2003 at 12:35:07PM +0100, Javier Fernandez-Sanguino wrote:
> 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).
I agree on that.
> 2.- sessions run plugins against a set of hosts (information available
> should include: start time/end time, session configuration: specified
> plugins, parameters...)
So we need a session field in the host table then.. or maybe a session
glue table. We need
TABLE session (
scanid # the run of the scan. Refered by hosts.scan_id
# and data.scan_id among others
scan_start # When did nessus commence the scan
scan_end # When did it finish
username # Who requested it
host # Where did the user come from
)
and in the
TABLE reports (
scan_id, # Refer to hosts.scan_id/session.scanid
plugin_start, # When did we start this scan?
plugin_end, # When did this plugin end?
plugin_id, # Plugin number
plugin_version, # (is there such a thing? if not, something
# for NASL2?)
port_number, # What port is it we scanned?
port_protocol, # and what protocol is it using?
serverity, # Number refering to serverity.serverity_id
completed, # did the plugin actually finish or did nessusd
# kill it?
#ifndef If people want to store plugin output in several languages
lang # I don't know how relivant this is, but some
# ppl might want to store what lang the message
# is written in. Do we want to store several languages at once?
data # plugin output
#endif
)
#ifdef If people want to store plugin output in several languages
TABLE data (
scan_id # refer to hosts.scan_id
+ plugin_id # which plugin gave us the output
lang # language
data # plugin output
)
#endif
if we want to be really nasty we could have a plugin table looking
something like this:
TABLE plugins (
id # autoinc value used internally
plugin_id # The real plugin number
plugin_version # the real plugin version
)
The thing is that not only do I want to store a lot of data in the
database, I also want to queries to be executed fairly quickly. That
means that we should be careful how many tables we are using as the more
tables you need to search through the slower the query will be.
> 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).
Then it would be reported as the port is open but without any particular
vulnerability for it.
> 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)
That won't work as several plugins output dynamic vulnerability
description (usernames, banners etc).
> 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.
My scheme does that.
> - keep track of vulnerabilities associated with detected services.
Will port/protocol be enough, or do we want to mark it as a particular
software or operating system? I always wade through the reports and
confirm any dubts as I have had a lot of hosts that shows both IIS and
Apache vulnerabilities on the same system...
> - 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'.
Why not just mark it as a informal "vulnerability" with the "the port
was listening" kind of message?
> 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)
Of course the report will only be based on the vulnerabilities found, but
shouldn't the actual message from the plugin tell you exactly _what_ it
found as well? If the data is there it's up to you to use it. Modify your
SELECT statement to include or exclude data you are (not) interested in.
Best regards
Michael Boman
PS
Sorry for the late reply, have been busy
DS
--
Michael Boman
Security Architect, SecureCiRT (A SBU of Z-Vance Pte Ltd)
http://www.securecirt.com
> 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).
I agree on that.
> 2.- sessions run plugins against a set of hosts (information available
> should include: start time/end time, session configuration: specified
> plugins, parameters...)
So we need a session field in the host table then.. or maybe a session
glue table. We need
TABLE session (
scanid # the run of the scan. Refered by hosts.scan_id
# and data.scan_id among others
scan_start # When did nessus commence the scan
scan_end # When did it finish
username # Who requested it
host # Where did the user come from
)
and in the
TABLE reports (
scan_id, # Refer to hosts.scan_id/session.scanid
plugin_start, # When did we start this scan?
plugin_end, # When did this plugin end?
plugin_id, # Plugin number
plugin_version, # (is there such a thing? if not, something
# for NASL2?)
port_number, # What port is it we scanned?
port_protocol, # and what protocol is it using?
serverity, # Number refering to serverity.serverity_id
completed, # did the plugin actually finish or did nessusd
# kill it?
#ifndef If people want to store plugin output in several languages
lang # I don't know how relivant this is, but some
# ppl might want to store what lang the message
# is written in. Do we want to store several languages at once?
data # plugin output
#endif
)
#ifdef If people want to store plugin output in several languages
TABLE data (
scan_id # refer to hosts.scan_id
+ plugin_id # which plugin gave us the output
lang # language
data # plugin output
)
#endif
if we want to be really nasty we could have a plugin table looking
something like this:
TABLE plugins (
id # autoinc value used internally
plugin_id # The real plugin number
plugin_version # the real plugin version
)
The thing is that not only do I want to store a lot of data in the
database, I also want to queries to be executed fairly quickly. That
means that we should be careful how many tables we are using as the more
tables you need to search through the slower the query will be.
> 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).
Then it would be reported as the port is open but without any particular
vulnerability for it.
> 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)
That won't work as several plugins output dynamic vulnerability
description (usernames, banners etc).
> 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.
My scheme does that.
> - keep track of vulnerabilities associated with detected services.
Will port/protocol be enough, or do we want to mark it as a particular
software or operating system? I always wade through the reports and
confirm any dubts as I have had a lot of hosts that shows both IIS and
Apache vulnerabilities on the same system...
> - 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'.
Why not just mark it as a informal "vulnerability" with the "the port
was listening" kind of message?
> 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)
Of course the report will only be based on the vulnerabilities found, but
shouldn't the actual message from the plugin tell you exactly _what_ it
found as well? If the data is there it's up to you to use it. Modify your
SELECT statement to include or exclude data you are (not) interested in.
Best regards
Michael Boman
PS
Sorry for the late reply, have been busy
DS
--
Michael Boman
Security Architect, SecureCiRT (A SBU of Z-Vance Pte Ltd)
http://www.securecirt.com