11 Reports and Vulnerability Management¶
Note
This chapter documents all possible menu options.
However, not all appliance models support all of these menu options. The model overview provides information about whether a specific feature is available on the used appliance model.
The results of a scan are summarized in a report. Reports can be displayed on the web interface and downloaded in different formats.
The appliance saves all reports of all scans in a local database. Not only is the last report of a scan saved but all reports of all scans ever run. This allows access to information from the past. The reports contain the discovered vulnerabilities and information of a scan.
Once a scan has been started, the report of the results found so far can be viewed. When a scan is completed, the status changes to Done and no more results will be added.
11.1 Configuring and Managing Report Formats¶
Report formats are defined as the formats a report is created from, based on the scan results. Many report formats reduce the available data in order to display it in a meaningful way.
The report formats can be used to export report information into other document formats, so they can be processed by other third-party applications (connectors).
The name of the exported report is configurable in the user settings (see Chapter 8.7).
The native appliance XML format contains all data and can be used to import exported reports on another appliance. To do so, create a container task (see Chapter 10.5).
11.1.1 Default Report Formats¶
All default report formats by Greenbone are data objects that are distributed via the feed. They are downloaded and updated with each feed update.
Note
Report formats may be deprecated. They are marked with (Deprecated) on the web interface, and are no longer documented in the following list.
Deprecated report formats can no longer be used. If a report is exported in such a format, the downloaded file may be empty or otherwise not suitable for use.
If no default report formats are available, a feed update may be necessary, or the Feed Import Owner may need to be set (see Chapter 7.2.1.10.1).
Default report formats cannot be edited. Furthermore, they can only be deleted temporarily by the Feed Import Owner or by a super administrator. During the next feed update, they will be downloaded again.
Note
To permanently delete a default report format, the Feed Import Owner has to delete it. Afterwards the Feed Import Owner has to be changed to (Unset) (see Chapter 7.2.1.10.1).
By default, the following report formats are available:
- Anonymous XML
This is the anonymous version of the XML format. IP addresses are replaced by random IP addresses.
- ARF: Asset Reporting Format v1.0.0
This format creates a report that represents the NIST Asset Reporting Format.
- CPE – Common Platform Enumeration CSV Table
This report selects all CPE tables and creates a single comma-separated file.
- CSV Hosts
This report creates a comma-separated file containing the systems discovered.
- CSV Results
This report creates a comma-separated file with the results of a scan.
- GCR PDF – Greenbone Compliance Report
This is the complete Greenbone Compliance Report for compliance audits (see Chapter 12.2) with all vulnerabilities in graphical format as a PDF file. The language of the report is English.
- GSR HTML – Greenbone Security Report
This is the complete Greenbone Security Report with all vulnerabilities and results. It can be opened with a web browser in which JavaScript must be enabled. It contains dynamically sortable lists as known from the web interface. The language of the report is English.
- GSR PDF – Greenbone Security Report
This is the complete Greenbone Security Report with all vulnerabilities in graphical format as a PDF file. The topology graph is not included if more than 100 hosts are covered in the report. The language of the report is English.
- GXCR PDF – Greenbone Executive Compliance Report
This is the shortened Greenbone Compliance Report for compliance audits (see Chapter 12.2) with all vulnerabilities in graphical format as a PDF file for management. The language of the report is English.
- GXR PDF – Greenbone Executive Report
This is the shortened Greenbone Security Report with all vulnerabilities in graphical format as a PDF file for management. The topology graph is not included if more than 100 hosts are covered in the report. The language of the report is English.
- LaTeX
This report is offered as LaTeX source text. The language of the report is English.
- NBE
This is the old OpenVAS/Nessus report format. It does not have support for notes, overrides and some additional information.
This is a complete report in PDF. Like the HTML format it is neutral. The language of the report is English.
- TLS Map
This is the report format for TLS Map scans (see Chapter 12.6).
- Topology SVG
This presents the results in an SVG picture.
- TXT
This creates a text file. This format is especially useful when being sent by e-mail. The language of the report is English.
- Verinice ISM
Creates an import file for the ISMS tool verinice (see Chapter 18.1).
- Verinice ISM all results
Creates an import file for the ISMS tool verinice (see Chapter 18.1).
- Verinice ITG (obsolete)
Creates an import file for the ISMS tool verinice (see Chapter 18.1).
- Vulnerability Report HTML (recommended)
This is the new complete Greenbone Security Report with all vulnerabilities and results. It can be opened with a web browser or HTML viewer. The language of the report is English.
- Vulnerability Report PDF (recommended)
This is the new complete Greenbone Security Report with all vulnerabilities in graphical format as a PDF file. The language of the report is English.
Reports with this report format are limited to the first 500 results per host. Subsequent results per host will be left out and a warning will be shown on the title page of the report.
- XML
The report is exported in the native XML format. Contrary to the other formats this format contains all results and does not format them at all.
11.1.2 Managing Report Formats¶
List Page
All existing report formats can be displayed by selecting Configuration > Report Formats in the menu bar.
For all report formats the following information is displayed:
- Name
Name of the report format.
- Extension
The file name of the downloaded report consists of the UUID (unique internal ID of the report) and this extension. Among others, the extension supports the browser to start a compatible application in case the specified content type is not recognized.
- Content Type
The content type specifies the format in use and is transmitted when being downloaded. By this, a compatible application can be launched by the browser.
Additionally, the content type is important internally: it is used to offer suitable plug-ins within its context. For example, when sending a report via e-mail all plug-ins of the type
text/\*
are offered as they can be embedded in an e-mail in a humanly readable way.- Trust
Some report formats only convert data, while others perform more complex operations and also execute programs. To prevent abuse, each report format plug-in has to be digitally signed by Greenbone. The digital signatures are distributed via the Greenbone Enterprise Feed. If a signature is authentic and the publisher is trusted, it is ensured that the report format exists in the exact format as certified by the publisher. The trust check is automatic and the result can be seen in the column Trust (Last Verified).
- Active
The report formats are only available in the respective selection menus if they are activated. Newly imported report formats are always deactivated at first. A report format can only be activated if it is trusted.
For all report formats the following actions are available:
Move the report format to the trashcan. As long as the report format is not deleted from the trashcan, it is not downloaded anew during the next feed update.
Edit the report format. Only self-created report formats can be edited.
Note
By clicking below the list of report formats more than one report format can be moved to the trashcan at a time. The drop-down list is used to select which report formats are moved to the trashcan.
Details Page
Click on the name of a report format to display the details of the report format. Click to open the details page of the report format.
The following actions are available in the upper left corner:
Add a new report format (see Chapter 11.1.3).
Edit the report format. Only self-created report formats can be edited.
Move the report format to the trashcan. As long as the report format is not deleted from the trashcan, it is not downloaded anew during the next feed update.
11.1.3 Adding a Report Format¶
Note
To prevent abuse, all additionally imported report formats have to be reviewed and digitally signed by Greenbone. Report formats that are not signed by Greenbone are not supported in GOS, and cannot be used.
For more information see Chapter 11.1.2 – Trust.
A new report format can be imported as follows:
Provide or obtain a report format plug-in that has been reviewed and accepted by Greenbone.
Select Configuration > Report Formats in the menu bar.
Click Browse… and select the report format plug-in (see Fig. 11.2).
Click Save.
→ The imported report format is displayed on the page Report Formats.
For Active select the radio button Yes (see Fig. 11.3).
Click Save.
11.2 Using and Managing Reports¶
All existing reports for all scans can be displayed by selecting Scans > Reports in the menu bar.
The total number of reports of a specific task is displayed on the page Tasks in the column Reports.
The reports for a specific task can be displayed as follows:
Select Scans > Tasks in the menu bar.
For the desired task click on the total number of reports in the column Reports to display all reports.
→ The page Reports is opened. A filter is applied to show only the reports for the selected task.
Tip
By clicking on the date in the column Last Report the details page of the latest report is opened (see Chapter 11.2.1).
For every report the following information is displayed:
- Date
Date and time of report creation.
- Status
Status of the corresponding task.
- Task
Corresponding task.
- Severity
Qualitative measure of a vulnerability’s severity according to the Common Vulnerability Scoring System (CVSS) (see Chapter 14.2.3). This includes a severity score, which is a number from 0.0 to 10.0, with 10.0 being the most severe, and a severity class based on the score:
High: 7.0–10.0
Medium: 4.0–6.9
Low: 0.1–3.9
Log: 0.0
- High/Medium/Low/Log/False Pos.
Number of found vulnerabilities for each severity class.
For all reports the following actions are available:
Create a delta report (see Chapter 11.2.5).
Note
By clicking below the list of reports more than one report can be deleted at a time. The drop-down list is used to select which reports are deleted.
11.2.1 Reading a Report¶
Click on the date of a report to display the details of the report.
The following registers are available:
- Information
General information about the corresponding scan.
- Results
List of all results in this report (see Chapter 11.2.1.1).
- Hosts
Scanned hosts with host names and IP addresses. The detected operating systems, the number of found vulnerabilities for each severity and the highest severity found by the scan are displayed.
- Ports
Scanned ports with port name, number of hosts and highest severity found by the scan.
- Applications
Scanned applications with CPE of the application, number of hosts, number of occurrences of results that detected this CPE and highest severity found by the scan.
- Operating Systems
Scanned operating systems with system name, host name, number of scanned hosts and highest severity found by the scan.
- CVEs
CVEs found with the scan.
- Closed CVEs
CVEs of originally detected vulnerabilities which were already confirmed as solved during the scan.
- TLS Certificates
TLS certificates found with the scan.
- Error Messages
Error messages that occurred during the scan.
- User Tags
Assigned tags (see Chapter 8.4).
The report content can be sorted by a chosen column by clicking on the column title. The content can be sorted ascending or descending:
in the column title shows that the objects are sorted ascending.
in the column title shows that the objects are sorted descending.
The following actions are available in the upper left corner:
Add the report contents that have at least a QoD of 70 % and enabled overrides to the assets.
Open the page Results. A filter is applied to show only the results for this report.
Open the page Vulnerabilities. A filter is applied to show only the vulnerabilities for this report.
Open the page TLS Certificates. A filter is applied to show only the TLS certificates for this report.
Open the page Performance. The system performance for the scan’s duration is displayed.
Download a filtered report (see Chapter 11.2.2).
Trigger an alert to send a report (see Chapter 11.2.4).
11.2.1.1 Results of a Report¶
The register Results contains a list of all vulnerabilities detected by the appliance (see Fig. 11.5).
Note
By default, overrides are not applied. They can be applied by filtering the report (see Chapter 11.2.1.3).
For every result the following information is displayed:
- Vulnerability
Name of the found vulnerability. By clicking on the name of a vulnerability details of the vulnerability are shown (see Fig. 11.6). The details page of the vulnerability is opened by clicking .
Vulnerabilities with an attached note are marked with . Vulnerabilities with an attached ticket are marked with .
Note
If the column of the vulnerability still appears empty the respective VT has not been updated yet.
- Solution type
Type of measure to remedy the vulnerability. The following solution types exist:
Vendor fix: Information is available about an official fix that is issued by the original vendor of the affected product. Unless otherwise noted, it is assumed that this fix fully resolves the vulnerability.
Workaround: Information about a configuration or specific deployment scenario that can be used to avoid exposure to the vulnerability is available. This is usually the “first line of defense” against a new vulnerability before a mitigation or vendor fix has been issued or even discovered.
Mitigation: Information about a configuration or specific deployment scenario that helps to reduce the risk of the vulnerability is available but that does not resolve the vulnerability on the affected product.
Will not fix: There is no fix for the vulnerability and there never will be one. This is often the case when a product has been orphaned, is no longer maintained or otherwise deprecated. Information should contain details about why there will be no fix issued.
None: Currently there is no fix available. Information should contain details about why there is no fix.
- Severity
Qualitative measure of a vulnerability’s severity according to the Common Vulnerability Scoring System (CVSS) (see Chapter 14.2.3). This includes a severity score, which is a number from 0.0 to 10.0, with 10.0 being the most severe, and a severity class based on the score:
High: 7.0–10.0
Medium: 4.0–6.9
Low: 0.1–3.9
Log: 0.0
- QoD
Short for “Quality of Detection”. The QoD describes the reliability of the executed vulnerability detection. It is a value between 0 % and 100 %, with 100 % being the most reliable.
By default, only results that were detected by VTs with a QoD of 70 % or higher are displayed. The filter can be adjusted to show results with a lower QoD (see Chapter 8.3.1).
For more information see Chapter 11.2.6.
- Host
Host for which the result was found. The IP address and the name of the host are displayed separately.
- Location
Port number and protocol type used to find the vulnerability on the host.
- Created
Date and time of the report creation.
11.2.1.2 Interpreting a Report¶
To interpret the results note the following information:
- False Positives
A false positive is a finding that describes a problem that does not really exist. Vulnerability scanners often find evidence that point at a vulnerability but a final judgment cannot be made. There are two cases:
False positive: reporting a potentially non-existent vulnerability.
False negative: not reporting a potentially existing vulnerability.
Since a user can identify, manage and as such deal with false positives compared to false negatives, the appliance’s vulnerability scanner reports all potentially existing vulnerabilities. If the user knows that a false positive exists, an override can be configured (see Chapter 11.8).
- Multiple findings can have the same cause.
If an especially old software package is installed, often multiple vulnerabilities exist. Each of these vulnerabilities is tested by an individual VT and causes an alert. The installation of a current package will remove a lot of vulnerabilities at once.
- High and Medium
Findings of the severity classes High and Medium are most important and should be addressed with priority. Before addressing Medium findings, High findings should get addressed. Only in exceptional cases this approach should be deviated from, for example if it is known that the high level findings need to be less considered because the service cannot be reached through the firewall.
- Low and Log
Findings of the severity classes Low and Log are mostly interesting for detail understanding. These findings are filtered out by default but can hold very interesting information. Considering them will increase the security of the network and the systems. Often a deeper knowledge of the application is required for their understanding. Typical for a result with the severity class Log is that a service uses a banner with its name and version number. This could be useful for an attacker when this version has a known vulnerability.
11.2.1.3 Filtering a Report¶
Since a report often contains a lot of findings, the complete report as well as only filtered results can be displayed and downloaded.
The report can be filtered as follows:
Enter a keyword which should be searched for in the input box Filter (see Fig. 11.7).
For Apply Overrides select the radio button Yes to enable overrides (see Chapter 11.8).
For Apply Overrides select the radio button No to disable overrides.
Activate the checkbox Only show hosts that have results if only the hosts with results should be included.
For QoD select the desired QoD (see Chapter 11.2.6).
For Severity (Class) activate the checkboxes of the desired severity classes.
For Solution Type select the radio buttons of the desired solution types.
Enter the (part of a) vulnerability’s name, host or location in the according input box.
Click Update.
11.2.2 Exporting a Report¶
For supported export formats see Chapter 11.1.
A report can be exported as follows:
Select Scans > Reports in the menu bar.
Click on the date of a report to open the details page of the report.
-
→ The scan report content composer is opened (see Fig. 11.8).
Note
The applied filter is displayed in the input box Filter and cannot be changed. For changing the filter see Chapter 11.2.1.3.
Activate the checkbox Notes to include attached notes, and the checkbox Overrides to label enabled overrides and include their text field content.
Note
Overrides are only considered if they are enabled when filtering the report (see Chapter 11.2.1.3).
Select the report format in the drop-down list Report Format.
Activate the checkbox Store as default to save the settings for future exports.
Click OK.
Save the report by clicking Save File.
11.2.3 Importing a Report¶
Reports can be imported to the appliance as follows:
Select Scans > Reports in the menu bar.
Click Browse… and select the XML file of a report (see Fig. 11.9).
Select the container task to which the report should be added in the drop-down list Container Task.
Tip
By clicking a new container task can be created (see Chapter 10.5).
Select the radio button Yes to add the report to the assets.
Click Import.
11.2.4 Triggering an Alert for a Report¶
Often an alert includes the sending of a report. The report sent by an alert is subject to a filter defined in the alert content composer (see Chapter 10.12). Triggering an alert for a report adds a second filter originating from the scan report content composer (see Chapter 11.2.2).
The alert can be triggered manually as follows:
Select Scans > Reports in the menu bar.
Click on the date of a report to show the results.
Filter the report so that only the results that should be sent are displayed by using the Powerfilter (see Chapter 11.2.1.3) or selecting a register.
Note
The filter that is configured in the alert content composer (see Chapter 10.12) is applied additionally.
To mimic the behavior of this filter, adjust the filter of the report in a way that no results are filtered out.
-
→ The scan report content composer is opened (see Fig. 11.8).
Note
The applied filter for displaying the results is entered in the input box Filter and cannot be changed. For changing the filter see Chapter 11.2.1.3.
Activate the checkbox Notes to include attached notes, and the checkbox Overrides to label enabled overrides and include their text field content.
Note
Overrides are only considered if they are enabled when filtering the report (see Chapter 11.2.1.3).
Select the alert in the drop-down list Alert.
Tip
A new alert can be created by clicking . For the information to enter in the input boxes see Chapter 10.12.
Activate the checkbox Store as default to save the settings for future sendings of the report.
Click OK.
11.2.5 Creating a Delta Report¶
If more than one report of a single task is available (see Chapter 11.2), a delta report can be created as follows:
Select Scans > Tasks in the menu bar.
Click on the total number of reports in the column Reports.
→ The page Reports is opened. A filter is applied to show only the reports for the selected task.
Select the newer report by clicking in the column Actions of the respective report (see Fig. 11.11).
Select the older report by clicking in the column Actions of the respective report (see Fig. 11.12).
→ The delta report with the delta results is displayed (see Fig. 11.13) and can be exported.
The type of the delta result is displayed in the column Delta. There are four types of delta results:
- Gone [–]
The result exists in the second (older) report but not in the first (newer) report.
- New [+]
The result exists in the first (newer) report but not in the second (older) report.
- Same [=]
The result exists in both reports and is equal.
- Changed [~]
The result exists in both reports but is different.
The term delta_states=
can be entered into the filter bar to show only a specific type of delta results (see Chapter 8.3).
delta_states=g
shows all results of the type Gone.delta_states=n
shows all results of the type New.delta_states=s
shows all results of the type Same.delta_states=c
shows all results of the type Changed.
Tip
Multiple types can be displayed at the same time, for example delta_states=gs
shows all results of the type Gone and Same.
11.2.6 Quality of Detection Concept¶
The quality of detection (QoD) is a value between 0 % and 100 % describing the reliability of the executed vulnerability detection or product detection.
While the QoD range allows to express the quality quite fine-grained, most tests use a standard methodology. Therefore, QoD types are associate with a QoD value. The current list of types may be extended over time.
Note
The QoD of a “Detection” result is higher than that of an actual “Vulnerability” result as it reflects the quality of the product detection itself – which is reliable – and not the quality of the related vulnerability tests which may be unreliable for various reasons (see table).
The lowest QoD that could apply is always used, for example in case of multiple detection methods (remote or local/authenticated).
QoD |
QoD Type |
Description |
---|---|---|
100 % |
exploit |
The detection happened via an exploit and is therefore fully verified. |
99 % |
remote_vul |
Remote active checks (code execution, traversal attack, SQL injection etc.) in which the response clearly shows the presence of the vulnerability. |
98 % |
remote_app |
Remote active checks (code execution, traversal attack, SQL injection etc.) in which the response clearly shows the presence of the vulnerable application. |
97 % |
package |
Authenticated package-based checks for, for example, Linux(oid) systems. |
97 % |
registry |
Authenticated registry based checks for Microsoft Windows systems. |
95 % |
remote_active |
Remote active checks (code execution, traversal attack, SQL injection etc.) in which the response shows the likely presence of the vulnerable application or of the vulnerability. “Likely” means that only rare circumstances are possible in which the detection would be wrong. |
80 % |
remote_banner |
Remote banner checks of applications that offer patch level in version. Many proprietary products do so. |
80 % |
executable_version |
Authenticated executable version checks for Linux(oid) or Microsoft Windows systems where applications offer patch level in version. |
75 % |
If results without any QoD information are processed (for example when migrating data from a legacy system to a currently supported system), they are assigned this value. |
|
70 % |
remote_analysis |
Remote checks that perform some analysis, but may not always be completely reliable depending on environmental conditions. Narrowing down suspected false-positive or false-negative edge cases may require analysis by the user (see Chapter 11.8). |
50 % |
remote_probe |
Remote checks in which intermediate systems such as firewalls may pretend correct detection so that it is actually not clear whether the application itself answered. For example, this can happen for non-TLS connections. |
30 % |
remote_banner_unreliable |
Remote banner checks of applications that do not offer patch level in version identification. For example, this is the case for many open-source products due to backport patches. |
30 % |
executable_version_unreliable |
Authenticated executable version checks for Linux(oid) systems where applications do not offer patch level in version identification. |
30 % |
package_unreliable |
Authenticated package-based checks which are not always fully reliable for, for example, Linux(oid) systems. |
1 % |
general_note |
General note on potential vulnerability without finding any present application. |
By default, only results that were detected by VTs with a QoD of 70 % or higher are displayed. Results detected by a test with a lower QoD are prone to false positives. The filter can be adjusted to show results with a lower QoD (see Chapter 8.3.1).
Note
When changing the default filter to show results detected by a test with a low QoD, it is one’s own responsibility to determine if it is a false positive.
11.3 Displaying all Existing Results¶
List Page
While the reports only contain the results of one single scan, all results are saved in the internal database and can be viewed by selecting Scans > Results in the menu bar.
Powerfilters can be used to display only interesting results (see Chapter 8.3).
For all results the following information is displayed:
- Vulnerability
Name of the found vulnerability.
Vulnerabilities with an attached note are marked with . Vulnerabilities with an attached ticket are marked with .
Note
If the column of the vulnerability still appears empty the respective VT has not been updated yet.
Note
Even though the results contain a lot of information, external references are always listed in the details. These refer to web pages on which the vulnerability was already discussed. Additional background information is available such as who discovered the vulnerability, what effects it could have and how it can be remediated.
- Solution type
Type of measure to remedy the vulnerability. The following solution types exist:
Vendor fix: Information is available about an official fix that is issued by the original vendor of the affected product. Unless otherwise noted, it is assumed that this fix fully resolves the vulnerability.
Workaround: Information about a configuration or specific deployment scenario that can be used to avoid exposure to the vulnerability is available. This is usually the “first line of defense” against a new vulnerability before a mitigation or vendor fix has been issued or even discovered.
Mitigation: Information about a configuration or specific deployment scenario that helps to reduce the risk of the vulnerability is available but that does not resolve the vulnerability on the affected product.
Will not fix: There is no fix for the vulnerability and there never will be one. This is often the case when a product has been orphaned, is no longer maintained or otherwise deprecated. Information should contain details about why there will be no fix issued.
None: Currently there is no fix available. Information should contain details about why there is no fix.
- Severity
Qualitative measure of a vulnerability’s severity according to the Common Vulnerability Scoring System (CVSS) (see Chapter 14.2.3). This includes a severity score, which is a number from 0.0 to 10.0, with 10.0 being the most severe, and a severity class based on the score:
High: 7.0–10.0
Medium: 4.0–6.9
Low: 0.1–3.9
Log: 0.0
- QoD
Short for “Quality of Detection”. The QoD describes the reliability of the executed vulnerability detection. It is a value between 0 % and 100 %, with 100 % being the most reliable.
By default, only results that were detected by VTs with a QoD of 70 % or higher are displayed. The filter can be adjusted to show results with a lower QoD (see Chapter 8.3.1).
For more information see Chapter 11.2.6.
- Host
Host for which the result was found. The IP address and the name of the host are displayed separately.
- Location
Port number and protocol type used to find the result on the host.
- Created
Date and time of the report creation.
Note
By clicking below the list of results more than one result can be exported at a time. The drop-down list is used to select which results exported.
Details Page
Click on the name of a result to display the details of the result. Click to open the details page of the result.
The following registers are available:
- Information
General information about the result.
- User Tags
Assigned tags (see Chapter 8.4).
The following actions are available in the upper left corner:
11.4 Displaying all Existing Vulnerabilities¶
List Page
While the reports only contain the vulnerabilities of one single scan, all vulnerabilities are saved in the internal database and can be viewed by selecting Scans > Vulnerabilities in the menu bar.
Powerfilters can be used to display only interesting vulnerabilities (see Chapter 8.3).
For all vulnerabilities the following information is displayed:
- Name
Title of the vulnerability.
- Oldest Result
Date and time of the oldest result that was found for the vulnerability.
- Newest Result
Date and time of the newest result that was found for the vulnerability.
- Severity
Qualitative measure of a vulnerability’s severity according to the Common Vulnerability Scoring System (CVSS) (see Chapter 14.2.3). This includes a severity score, which is a number from 0.0 to 10.0, with 10.0 being the most severe, and a severity class based on the score:
High: 7.0–10.0
Medium: 4.0–6.9
Low: 0.1–3.9
Log: 0.0
- QoD
Short for “Quality of Detection”. The QoD describes the reliability of the executed vulnerability detection. It is a value between 0 % and 100 %, with 100 % being the most reliable.
By default, only results that were detected by VTs with a QoD of 70 % or higher are displayed. The filter can be adjusted to show results with a lower QoD (see Chapter 8.3.1).
For more information see Chapter 11.2.6.
- Results
Number of results found for this vulnerability. By clicking on the number of results the page Results is opened. A filter is applied to show only the results for the selected vulnerability.
Note
By clicking below the list of results more than one result can be exported at a time. The drop-down list is used to select which results exported.
Details Page
Click on the name of a vulnerability to open the details page of the vulnerability.
The following actions are available in the upper left corner:
11.5 Trend of Vulnerabilities¶
If a task has been run multiple times the trend of discovered vulnerabilities is displayed on the page Tasks (see Fig. 11.16).
To get there select Scans > Tasks in the menu bar.
The trend describes the change of vulnerabilities between the newest and the second newest report. It is displayed in the column Trend.
The following trends are possible:
In the newest report the highest severity is higher than the highest severity in the second newest report.
The highest severity is the same for both reports. However, the newest report contains more security issues of this severity than the second newest report.
The highest severity and the amount of security issues are the same for both reports.
The highest severity is the same for both reports. However, the newest report contains less security issues of this severity than the second newest report.
In the newest report the highest severity is lower than the highest severity in the second newest report.
11.6 Using Tickets¶
Remediation tickets are used to resolve the findings of vulnerabilities. Tickets can be assigned to the current user or other users. All valuable information to understand and resolve the problem is directly cross-linked and available for the assigned user. Additionally, the status of a ticket helps to track the progress.
Alerts can be assigned for certain events related to tickets, for example a status change of an assigned ticket.
The ticket management system is capable of considering the repetition of scans automatically in order to verify that the problem has been solved.
Note
When creating a ticket for another user, that user gets read and write access to the ticket. Additionally, the user automatically gets read access to the respective task and to its reports and results.
If the assignment of a ticket is withdrawn from a user, the read access to the task and the reports remains. The permissions for a task can be checked and revoked on a task’s details page (see Chapter 10.8). If multiple tickets are created for results of the same report and assigned to the same user, the same permission will appear multiple times.
If the assignee of a ticket is changed, the new assignee does not automatically get read access to the task. Instead, the ticket owner must edit the permissions via the task’s details page (see Chapter 10.8) and grant read access to the new assignee.
11.6.1 Creating a Ticket¶
A ticket can be created as follows:
Select Scans > Reports in the menu bar and click on the date of a report to show the results.
Click on an item in the column Vulnerability and to open the details page of the result.
or
Select Scans > Results in the menu bar.
Click on an item in the column Vulnerability and to open the details page of the result.
Select the user to whom the ticket should be assigned in the drop-down list Assign to User (see Fig. 11.17).
Enter a note for the ticket in the input box Note.
Click Save.
→ The number of tickets for a result are displayed in the upper left corner of the details page of the result (see Fig. 11.18). By clicking the corresponding tickets are displayed.
11.6.2 Changing the Status of a Ticket¶
A ticket can have the following status:
Open: the vulnerability has not been fixed yet.
Fixed: the vulnerability has been fixed.
Fixed verified: the task has been run again and the vulnerability was not found anymore. This status is set automatically.
Closed: the fix of the vulnerability was verified or the ticket is not required anymore.
The status of a ticket can be changed as follows:
Select Resilience > Remediation Tickets in the menu bar.
Select the new status in the drop-down list Status (see Fig. 11.19).
Select the user to whom the ticket with the new status should be assigned in the drop-down list Assigned User.
Enter a note for the new status in the respective input box.
Click Save.
11.6.3 Setting an Alert for a Ticket¶
Alerts for tickets can be set for the following events:
A new ticket is received.
The status of an assigned ticket changed.
The status of an own ticket changed.
An alert for tickets is set up as follows:
Select Configuration > Alerts in the menu bar.
Define the alert (see Fig. 11.20).
Click Save.
The following details of the alert can be defined:
- Name
Definition of the name. The name can be chosen freely.
- Comment
An optional comment can contain additional information.
- Event
Select Ticket Received if an alert should be sent when a new ticket is assigned to oneself.
Select Assigned Ticket Changed if an alert should be sent when the status of a ticket assigned to oneself changes.
Select Owned Ticket Changed if an alert should be sent when the status of ticket assigned to another user changes.
- Method
Selection of the method for the alert. Only one method per alert can be chosen.
If different alerts for the same event should be triggered, multiple alerts must be created and linked to the same task.
The following methods are possible:
An e-mail is sent to the given address.
The transmission of the e-mail can by encrypted using a configurable S/MIME or GPG key. The encryption can be selected in the drop-down list Email Encryption or created by clicking .
- Start Task
The alert can start an additional task. The task is selected in the drop-down list Start Task.
- System Logger
The alert is sent to a Syslog daemon.
The Syslog server is defined using the console (see Chapter 7.2.12).
11.6.4 Managing Tickets¶
List Page
All existing tickets can be displayed by selecting Resilience > Remediation Tickets in the menu bar.
For all tickets the following information is displayed:
- Vulnerability
Vulnerability for which the ticket is created.
- Severity
Severity of the vulnerability for which the ticket is created.
- Host
Host on which the vulnerability was found.
- Solution Type
Solution type of the vulnerability for which the ticket is created.
- Assigned User
User to which the ticket is assigned.
- Modification Time
Date and time of the last modification of the ticket.
- Status
Status of the ticket.
For all tickets the following actions are available:
Note
By clicking or below the list of tickets more than one ticket can be moved to the trashcan or exported at a time. The drop-down list is used to select which tickets are moved to the trashcan or exported.
Details Page
Click on the name of a ticket to display the details of the ticket. Click to open the details page of the ticket.
The following registers are available:
- Information
General information about the ticket.
- User Tags
Assigned tags (see Chapter 8.4).
The following actions are available in the upper left corner:
11.7 Using Notes¶
Notes allow adding comments to a VT and are displayed in the reports as well. A note can be added to a specific result, task, severity, port or host and as such will only appear in specific reports. A note can be generalized as well so that it will be displayed in all reports.
11.7.1 Creating a Note¶
11.7.1.1 Creating a Note Through a Scan Result¶
Notes can be created in different ways. The simplest way is through the respective scan result in a report:
Select Scans > Reports in the menu bar.
Click on the date of the report to show the results.
Select the register Results.
Click on a result in the column Vulnerability.
Define the note (see Fig. 11.21).
The following information can be entered:
Note
If a note is created through a scan result, some settings are already filled in.
- NVT
VT for which the note is applied.
- Active
Selection whether the note should be activated. An activation for an arbitrary number of days is possible as well.
- Hosts
Host or range of hosts for which the result must be found for the note to apply.
Tip
It is possible to enter ranges of IP addresses and CIDR blocks. In that way, notes for entire subnets can be created without having to specify every host in a comma-separated list.
Host ranges are specified with a minus, for example
198.168.1.1-198.168.1.25
. A range bigger than 4096 is not supported.- Location
Port for which the result must be found for the note to apply. Only the following values are supported per note:
The setting Any.
A specific port supplied as a number followed by
/tcp
or/udp
.An unspecific port supplied as the text
general/tcp
.An unspecific port supplied as the text
package
.
- Severity
Range of severity of the VT for which the note should be applied.
- Task
Selection of tasks for which the note should be applied.
- Result
Selection of results for which the note should be applied.
Note
The radio button Any has to be selected if the note should be applied to reports in the future.
- Text
A text that describes the note in more detail.
Click Save.
→ The note is displayed on the details page of the result (see Fig. 11.22).
11.7.1.2 Creating a Note on the Page Notes¶
Notes can be created on the page Notes as well:
Select Scans > Notes in the menu bar.
Enter the ID of the VT in the input box NVT OID.
Define the note.
Tip
It is possible to enter ranges of IP addresses and CIDR blocks in the input box Hosts. In that way, notes for entire subnets can be created without having to specify every host in a comma-separated list.
Notes can be generalized by selecting the radio button Any for hosts, locations, severities, tasks or results.
Click Save.
11.7.2 Managing Notes¶
List Page
All existing notes can be displayed by selecting Scans > Notes in the menu bar (see Fig. 11.23).
For all notes the following actions are available:
Note
By clicking or below the list of notes more than one note can be moved to the trashcan or exported at a time. The drop-down list is used to select which notes are moved to the trashcan or exported.
Details Page
Click on the name of a note to display the details of the note. Click to open the details page of the note.
The following registers are available:
- Information
General information about the note.
- User Tags
Assigned tags (see Chapter 8.4).
- Permissions
Assigned permissions (see Chapter 9.4).
The following actions are available in the upper left corner:
Create a new note (see Chapter 11.7.1).
11.8 Using Overrides and False Positives¶
The severity of a result can be modified. This is called override.
Overrides are especially useful to manage results that are detected as a false positive and that have been given a critical severity but should be given a different severity in the future.
The same applies to results that only have been given the severity Log but should be assigned a higher severity locally. This can be managed with an override as well.
Overrides are also used to manage acceptable risks.
11.8.1 Creating an Override¶
11.8.1.1 Creating an Override Through a Scan Result¶
Overrides can be created in different ways. The simplest way is through the respective scan result in a report:
Select Scans > Reports in the menu bar.
Click on the date of the report to show the results.
Select the register Results.
Click on a result in the column Vulnerability.
Define the override. Select the new severity in the drop-down list New Severity (see Fig. 11.24).
The following information can be entered:
Note
If an override is created through a scan result, some settings are already filled in.
- NVT
VT for which the override is applied.
- Active
Selection whether the override should be activated. An activation for an arbitrary number of days is possible as well.
- Hosts
Host or range of hosts for which the result must be found for the override to apply.
Tip
It is possible to enter ranges of IP addresses and CIDR blocks. In that way, overrides for entire subnets can be created without having to specify every host in a comma-separated list.
Host ranges are specified with a minus, for example
198.168.1.1-198.168.1.25
. A range bigger than 4096 is not supported.Note
If multiple overrides match a result, for example one override for a host range and another for a host within this range, the more specific override (going by result, task, port and severity) is applied. If multiple, equally specific overrides match a result, the most recently created override is applied.
- Location
Port for which the result must be found for the override to apply. Only the following values are supported per override:
The setting Any.
A specific port supplied as a number followed by
/tcp
or/udp
.An unspecific port supplied as the text
general/tcp
.An unspecific port supplied as the text
package
.
- Severity
Range of severity of the VT for which the overrides should be applied.
- New Severity
Severity the VT should have after the override is applied.
- Task
Selection of tasks for which the override should be applied.
- Result
Selection of results for which the override should be applied.
Note
The radio button Any has to be selected if the override should be applied to reports in the future.
- Text
A text that describes the override in more detail.
Click Save.
Note
If several overrides apply to the same VT in the same report the most recent override is used and applied.
11.8.1.2 Creating an Override on the Page Overrides¶
Overrides can be created on the page Overrides as well:
Select Scans > Overrides in the menu bar.
Enter the ID of the VT in the input box NVT OID.
Define the override.
Note
For the information to enter in the input boxes see Chapter 11.8.1.1.
Select the new severity in the drop-down list New Severity.
Click Save.
11.8.2 Managing Overrides¶
List Page
All existing overrides can be displayed by selecting Scans > Overrides in the menu bar.
For all overrides the following actions are available:
Note
By clicking or below the list of overrides more than one override can be moved to the trashcan or exported at a time. The drop-down list is used to select which overrides are moved to the trashcan or exported.
Details Page
Click on the name of an override to display the details of the override. Click to open the details page of the override.
The following registers are available:
- Information
General information about the override.
- User Tags
Assigned tags (see Chapter 8.4).
- Permissions
Assigned permissions (see Chapter 9.4).
The following actions are available in the upper left corner:
Create a new override (see Chapter 11.8.1).
11.8.3 Disabling and Enabling Overrides¶
If overrides change the display of the results, the overrides can be enabled or disabled.
This is done by setting the filter as follows:
For Apply Overrides select the radio button Yes to enable overrides.
For Apply Overrides select the radio button No to disable overrides.
Click Update.
Tip
Overrides can be labelled in exported reports (see Chapter 11.2.2).