[openvas-discuss] OpenVAS DevCon 1 write up
Norm.Donovan at Sentrik.com
Thu Apr 6 22:44:36 CEST 2006
>If you look into the database schema I pointed to you will see that the
>schema included information on the plugins themselves too (at least the
>relevant metadata sans the code itself).
>Results databases need this information too, since you want to know what
>plugins (version and data) was used in a given test. Just the number is not
>sufficient since plugins are updated with new references, content and >useful metadata
Of course the results database needs some of the same information as the plugin database (if that is what we can call it for now), but the plugin database will contain
Multiple plugins for the same problem (from different sources)
Version history of plugins (what changed when)
Plugins that have not been released
Plugins that are in test
Plugins that have been obsoleted
Structures to support some type of release workflow
None of these will simply pass through into the results database (assuming the client even has a database). Also the results database will have information not applicable to the plugin database, for example, what nodes contain the vulnerability.
If are simply saying that we should look at the results database for ideas about a metadata, then I am 100% in agreement. If you are saying that we should use these schemas for a plugin database, then I respectfully disagree.
>Well, "gaps" are easy to identify. Just go to the National Vulnerability
>Database and search for all CVE references that are "Remotely exploitable".
>If there is no plugin for that CVE reference then you have a gap :-)
I think you are oversimplifying the process of identifying gaps. :-) If the reports and plugins were in the same database, we would not have to analyze across databases. I am sure that OpenVAS will contain concerns that are not in a national databases? For example if OpenVAS was unable to access a node with the specified credentials, this would be a significant concern to an OpenVAS user, but I doubt would show up in a vulnerability database. Also why do you restrict yourself to remotely exploitable vulnerabilities?
>And your point is? I'm not asking for OpenVAS and Nessus to be instalable
>side by side, I'm saying that there should not be an 'openvas-libraries' or
>'openvas-libnasl' unless absolutely necessary and OpenVAS should use the
>'nessus-libraries' and 'libnasl' upstream
I assume that some people may install OpenVAS and Nessus on the same box and I think that it is prudent to not have them conflict or overlap. Is your concern that the Debian distribution may be a bit larger? I think many people will download OpenVAS separate from Debian.
All comments are made with the greatest respect.
From: Javier Fernández-Sanguino Peña [mailto:jfs at computer.org]
Sent: Wednesday, April 05, 2006 5:05 PM
To: Norm Donovan
Cc: openvas-discuss at openvas.org
Subject: Re: [openvas-discuss] OpenVAS DevCon 1 write up
On Wed, Apr 05, 2006 at 01:07:08PM -0700, Norm Donovan wrote:
> My understanding is that the database we discussed was to be a database of
> vulnerabilities used to generate and/or store plugins before they were
> collected into a library, not a database to store the results of scans,
> which I think is what you are discussing. The ideal solution would be if
> OSVDB had extensions to hold plugins. There was no discussion of results
> databases as people should be free to use whatever client they choose.
> We need a tool to handle sets of plugins coming from various sources that
> overlap. We also need to identify where we have gaps.
> I would guess that if a database was ever built into Nessus, it would be
> part of Nessus3 not Nessus2.
It's not going to be part of either. It was ruled out.
> If OpenVAS maintained the same naming conventions as Nessus, would not that
> lead to conflicts if both tools were installed on the same machine?
And your point is? I'm not asking for OpenVAS and Nessus to be instalable
side by side, I'm saying that there should not be an 'openvas-libraries' or
'openvas-libnasl' unless absolutely necessary and OpenVAS should use the
'nessus-libraries' and 'libnasl' upstream. That way the distributions
shipping both Nessus and OpenVAS (like Debian) would not carry two libraries
which are, esentially, the same thing for two different tools (the
Nessus/OpenVAS core daemon).
There might be a need to fork the libraries in the future but if the need
isn't there just yet, please don't just fork the libraries if all the
changes are just 's/nessus/openvas/' in the source code.
More information about the Openvas-discuss