On Dienstag, 25. August 2009, Chandrashekhar B wrote:
> -----Original Message-----
> > I stumbled (again) across the question how we should treat
> > the results of NVTs like os_fingerprint.nasl which
> > tries to guess some information (here the OS)
> > and adds this to the KB.
> > It also sends a security_note about the result.
>
> > IMHO this should only be a log_message() as the OS
> > type as such has not relation to security status.
>
> I think all discovered information should be in the report, so
> security_note() is appropriate in this case. log_message() should only be
> used to log information such as plugins's inability to perform something,
> error messages etc.,
>
> The discovered information is always useful to analyze the effectiveness of
> the report, not everyone looks at logs.
I agree in principle.
But yet again: Should the NVTs that do collect information
into the KB report on their own Security-level message? Isn't it a better
design to have other scripts report on such information.
The significant difference is that eg. NVTs can depend on os_fingerprint
to use their results and a independent NVT can report the OS - thus allowing
to run even NVTs that need OS without getting tons of messages about NVTs
while flexible to siwth on the OS-Reporter NVT whenever wished.
In the scenario you describe: If I want some NVTs to consider OS, then I am
automatically forced to handle the OS security messages. IMHO sooner or later
this concept will cause headache in the form of false positives management or
other way to surpress unrequested secrity-levelled information.
The more we discuss this, the more I am getting convinced we
should _in general_ downgrade any such KB-feeder script to log in
order to achieve a clean design on reporting ...
Best
Jan
--
Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B
202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
_______________________________________________
Openvas-plugins mailing list
[email protected]
http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins
