Reports contain a great deal of information. It’s important to study them carefully for better understanding, so that they can help you make more informed security-related decisions.
The data in a report is a static snapshot in time. The data displayed in the Web interface changes with every scan. Variance between the two, such as in the number of discovered assets or vulnerabilities, is most likely attributable to changes in your environment since the last report.
For stakeholders in your organization who need fresh data but don’t have access to the Web interface, run reports more frequently. Or use the report scheduling feature to automatically synchronize report schedules with scan schedules.
In environments that are constantly changing, Baseline Comparison reports an be very useful.
If your report data turns out to be much different from what you expected, consider several factors that may have skewed the data.
Scan settings affect report data in several ways:
If you are disseminating reports using multiple formats, keep in mind that different formats affect not only how data is presented, but what data is presented. The human-readable formats, such as PDF and HTML, are intended to display data that is organized by the document report templates. These templates are more “selective” about data to include. On the other hand, XML Export, XML Export 2.0, CSV, and export templates essentially include all possible data from scans.
Remediating confirmed vulnerabilities is a high security priority, so it’s important to look for confirmed vulnerabilities in reports. However, don’t get thrown off by listings of potential or unconfirmed vulnerabilities. And don’t dismiss these as false positives.
The application will flag a vulnerability if it discovers certain conditions that make it probable that the vulnerability exists. If, for any reason, it cannot absolutely verify that the vulnerability is there, it will list the vulnerability as potential or unconfirmed. Or it may indicate that the version of the scanned operating system or application is vulnerable.
The fact that a vulnerability is a “potential” vulnerability or otherwise not officially confirmed does not diminish the probability that it exists or that some related security issue requires your attention. You can confirm a vulnerability by running an exploit if one is available. See Working with vulnerabilities. You also can examine the scan log for the certainty with which a potentially vulnerable item was fingerprinted. A high level of fingerprinting certainty may indicate a greater likelihood of vulnerability.
You can find out the certainty level of a reported vulnerability in different areas:
Note that the Discovered and Potential Vulnerabilities section, which appears in the Audit report, potential and confirmed vulnerabilities are not differentiated.
When reviewing reports, look beyond vulnerabilities for other signs that may put your network at risk. For example, the application may discover a telnet service and list it in a report. A telnet service is not a vulnerability. However, telnet is an unencrypted protocol. If a server on your network is using this protocol to exchange information with a remote computer, it's easy for an uninvited party to monitor the transmission. You may want to consider using SSH instead.
In another example, it may discover a Cisco device that permits Web requests to go to an HTTP server, instead of redirecting them to an HTTPS server. Again, this is not technically a vulnerability, but this practice may be exposing sensitive data.
Study reports to help you manage risk proactively.
A long list of vulnerabilities in a report can be a daunting sight, and you may wonder which problem to tackle first. The vulnerability database contains checks for over 12,000 vulnerabilities, and your scans may reveal more vulnerabilities than you have time to correct.
One effective way to prioritize vulnerabilities is to note which have real exploits associated with them. A vulnerability with known exploits poses a very concrete risk to your network. The Exploit ExposureTM feature flags vulnerabilities that have known exploits and provides exploit information links to Metasploit modules and the Exploit Database. It also uses the exploit ranking data from the Metasploit team to rank the skill level required for a given exploit. This information appears in vulnerability listings right in the Security Console Web interface, so you can see right away
Since you can’t predict the skill level of an attacker, it is a strongly recommend best practice to immediately remediate any vulnerability that has a live exploit, regardless of the skill level required for an exploit or the number of known exploits.
Report settings can affect report data in various ways:
Another way to prioritize vulnerabilities is according to their risk scores. A higher score warrants higher priority.
The application calculates risk scores for every asset and vulnerability that it finds during a scan. The scores indicate the potential danger that the vulnerability poses to network and business security based on impact and likelihood of exploit.
Risk scores are calculated according to different risk strategies. See Working with risk strategies to analyze threats.