The results of a scan are summarized in a report. Reports can be viewed with a browser and downloaded from the Appliance in different formats. Once a scan has been started the report of the results found so far, can be viewed. Once a scan is complete its status changed to Done. From now on no additional results will get added. For more information on reports please refer to the Reports chapter as well.
The report summary gives an overview over vulnerabilities found.
The report summary gives a quick overview over the current state. It shows if a scan is complete and how many vulnerabilities have already been found. From the summery a report can be downloaded directly in many different formats. The following formats are supported (see also section Report Plugins)
Like XML but anonymous.
ARF: Asset Reporting Format v1.0.0
This format creates a report that represents the NIST Asset Reporting Format.
CPE - Common Enumeration CSV Table
This report selects all CPE tables and creates a single comma separated file.
This report creates a comma separated file containing the systems discovered.
This report creates a comma separated file with the results of a scan.
This is a shortened report for management.
This report is in HTML format.
ITG - IT-Grundschutz catalogue
This report is guided by the BSI IT-Grundschutz catalogue.
This report is offered as LaTeX source text.
This is the old Nessus report format.
Verinice ISM, ITG
For Import into veri.nice.
A single XML file is created from the report details. This should be the basis for creating your own style for a report or post-process the results in other ways.
Details of a report can be viewed in the web UI as well.
Different views of the same report.
Since a report often contains a lot of findings, the complete report as well as only filtered results can be viewed and downloaded. In the default setting only the High and Medium risks are being displayed. This can be changed very easily.
In the Filtered Results section shows the filtered results. As long as the scan is still running can cause rearrangements here.
To interpret the results please note the following information:
A false positive is a finding that describes a problem that does not exists in reality. Vulnerability scanners often find evidence that point at a vulnerability. However, a final judgment cannot be made. There are two options available:
- Reporting of a potentially nonexistent vulnerability (False Positive).
- Ignoring reporting of a potentially existing vulnerability (False Negative).
Since a user can identify, manage and as such deal with false positives compared to false negatives, the Mageni Vulnerability Scanner reports all potentially existing vulnerabilities. Mageni assists with several automatic and semi-automatic to categorize them.
This problem is very common with Enterprise Linux distributions. If, for example, a SSH service in version 4.4 is installed and the software reports this version during a connection attempt, a vulnerability scanner, that knows of a vulnerability in this version, will report this as such. The vendor potentially already addressed the vulnerability and released version 4.4-p1 that is already installed. This version still reports to the outside version 4.4 so that the vulnerability scanner cannot differentiate. If the user knows of this circumstance an Override can be configured (see section Overrides and False Positives). The AutoFP function (see section Automatic False Positives) can assist here as well.
- Multiple findings can have the same cause. Is an especially old software package installed often multiple vulnerabilities exist. Each of these vulnerabilities is tested by an individual NVT and causes an alert. The installation of a current package will then remove a lot of vulnerabilities at once.
- Important are findings of the levels High high and Medium medium. Address these findings in order of priority. Before addressing medium level findings, high level findings should get addressed. Only in exceptional cases, when it is known that the high alerts need to be less considered (because the service cannot be reached through the firewall) should this approach be deviated from.
- Low and Log are mostly interesting for detail understanding. This is why these findings are filtered out by default. These findings can hold very interesting information however and considering them will increase the security of your network and systems. For their understanding often a deeper knowledge of the applications is required. Typical for an alert at the log level is that a service uses a banner with its name and version number. This could be useful for an attacker during an attack if this version has a known vulnerability.
- To simplify the remediation of vulnerabilities every alert offers a solution for problems directly. In most cases it will be referred to the latest vendor software package. In some cases a configuration change will be mentioned.
- References explain the vulnerabilities further. Even though the alerts contain a lot of information external references are always listed. These refer to web sites 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 the vulnerability can be remediated.