OpenVAS Change Request #59: NVT Feed message consolidation
Status: Voted +5. In Progress.
Consolidation of messages sent by NVTs in order to simplify writing a NVT, lower maintenance effort and avoid mistakes due to redundancies.
Currently 3 types of messages define a security alert: security_hole(), security_warning() and security_note(). So far the use was decided by the authors of a NVT and do not necessarily correspond to the CVSS. Especially because CVSS can change over time.
A single message type "security_message()" for security alerts would be sufficient once all NVTs are associated with CVSS values. The risk/severity can then be decided automatically.
This would mean to reduce from total 5 to total 3 message types: security_message(), log_message() and debug_message().
No immediate effect for OpenVAS-4 users.
It would be optional to start using security_message for NVT developments.
After OpenVAS-4 is retired, NVT developers don't need to consider different severity message types anymore and all remaining NVTs can be converted to use security_message only.
Design and Implementation
As a precondition it is necessary that all NVTs using security_message do offer a CVSS (which is in progress, see CR#58).
As a first step the NASL method security_message() is added. However, there is no immediate need to use this function already now. In fact it should only be used for NVTs that do have a CVSS already. After OpenVAS-4 retired, in one go, all security_note, security_warning and security_hole can be renamed to security_message in all of the NVTs.
For OpenVAS-5, internally the functions security_hole, security_warning and security_note are mapped to security_message. The function security_message will look into the CVSS and then actually call the respective command using the currently applied CVSS range scheme.
Developments beyond OpenVAS-5 can remove the mapping in scanner and instead send the message right to Manager who then decides the current status. Thats is, however, another story.
Some NVTs currently use more than one message type (e.g. security_hole and security_warning, depending on some detections). Either this behaviour is in conflict with associated CVEs. Or if indeed it makes sense regarding the severity, then in fact it should be split into two NVTs. Each of them dealing with an aspect of a certain severity.
To treat some special situations optional parameters (cvss and msgtype) for security_message are added that allows to specify a certain CVSS is available. cvss is a value like "9.6" and msgtype is one of "hole", "warning", "note". This is also helpful for the transitional phase.
After OpenVAS-4 retired, all (semi-)automated NVT creation needs to be adapted to only apply security_message().
- 2012-02-09 Jan-Oliver Wagner <jan-oliver.wagner at greenbone dot net>:
Marked as "In Pogress" after vote.
- 2012-02-03 Jan-Oliver Wagner <jan-oliver.wagner at greenbone dot net>:
Updated the change request.
- 2011-11-01 Jan-Oliver Wagner <jan-oliver.wagner at greenbone dot net>:
Changed implementation concept regarding legacy options. In fact these are not necessary at all and we save one change process of all NVTs. Thanks for Thomas Reinke for this idea.
- 2011-10-30 Jan-Oliver Wagner <jan-oliver.wagner at greenbone dot net>: