[Openvas-discuss] Getting the OpenVAS NVT/Plugin feed to start

[Tim Brown]

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
> creation.

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.

Tim
-- 
Tim Brown
<mailto:timb at nth-dimension.org.uk>
<http://www.nth-dimension.org.uk/>