[Openvas-discuss] Getting the OpenVAS NVT/Plugin feed to start
timb at nth-dimension.org.uk
Tue Oct 16 00:46:35 CEST 2007
On Thursday 11 October 2007 14:24:09 Jan-Oliver Wagner wrote:
> it is getting the time that we are ready to start the feed service
> for Network Vulnerability Tests (NVTs) aka plugins.
I agree, I'm getting impatient to write some NASLs :).
> My initial idea is to concentrate on the Debian local security
> checks in a startup phase. If we can promise that those tests will always
> be uptodate in the feed, we have reached a very important step.
> Because this will establish/test the whole process for NVT
A worthy first goal.
> There is a solution in discussion over here to offer a site to operate
> the feed. Which essentially means a central URL on a secured
> maschine from where to rsync the NVTs.
> Also we have a update script being currently tested.
> I see basically two important aspects to decide/discuss:
> 1. How to handle NVT signatures (old scripts, new ones,
> different authors/trust levels etc).
> My proposal would be:
> - sign all 'old' plugins with a special key that is exclusively
> defined to as a check that the plugins are the same as
> this from Nessus.
> -> Who should create the key, who should be the holder
> of the key+passphrase?
> - Whoever manages a group of NVTs may arrange a key
> (for the following assuming we operate the download service over here)
> - Whoever takes care of a group of plugins gets a procedure
> to add them to the feed service. Basically this means
> to provide the nasl files and a signature file. Also, some convention
> about IDs is needed. My preference is to keep efford as low as
> possible with the initial phase. Such things could easily be organized over
> our mailing lists.
> - On a web page we list the certificates, which groups of plugins
> they maintain and what is the level of QA or trust or security
> associated with these signatures. And of course it is explained who to make
> OpenVAS Server accept plugins with certain signatures.
We did talk about the use of OID to allow multiple plugin streams and I did go
as far as to register a OID for OpenVAS itself. I would like to see this
implemented at some stage, because it would allow the plugin feed to grow in
a more organic manner. I guess we need to take a look at the NASL code to
see whether this can be done without non-trivial changes.
As a further sub point I think there is need for some style guide as it were
for plugin authors:
* How far should checks go
* How do we verify vulnerabilities
* How do we handle feedback
* How do we host plugins (if we decentralise)
* How do we support commecial vendors withou damaging the core
* How do we test the more exotic NVTs
* How do we work with other vulnerability database vedors
> 2. How to organize the DSA2NVT process.
> What we over here think about this is a
> evaluation/priorisation/implementation/QA process supported by a ticket
> management system like OTRS.
> Maybe is is a good idea to set up a test instance and see how it is
> working for OpenVAS during a test-phase.
This is perhaps a case where we should look to integrate with Debian itself,
so I've explicitly copied Neil in for his input. I have also prodded re the
question of automated conversion of DSA -> NASL.
<mailto:timb at nth-dimension.org.uk>
More information about the Openvas-discuss