Figure 4-12. Report dashboard
When you select the scan you want the report from, you will be presented with a list
of all vulnerabilities that were found. When I use the word
report
, it may sound like
we are talking
about an actual document, which you can certainly get, but really all
we’re looking for is the list of findings and their details. We can get all of that just as
easily from the web interface as we can from a document. I find it easier in most cases
to be able to click back and forth from the list to the details as needed. Your own
mileage will, of course, vary, depending on what’s most comfortable for you.
Figure 4-13
shows the list of vulnerabilities resulting from the scan of my network. I
like to keep some vulnerable systems around for fun and demonstration purposes.
Having everything up-to-date wouldn’t yield us much to look at.
Figure 4-13. List of vulnerabilities
136 | Chapter 4: Looking for Vulnerabilities
You’ll see seven columns. Some of these are fairly self-explanatory. The Vulnerability
and Severity columns should be easy to understand. The vulnerability is a short
description of the finding. The severity is worth talking about, though. This assess‐
ment is based on the impact that may result from the vulnerability being exploited.
The issue with the severity provided by the vulnerability scanner is that it doesn’t take
anything else into account. All it knows is the severity that goes with that vulnerabil‐
ity, regardless of any other mitigations that are in place that
could limit the exposure
to the vulnerability. This is where having a broader idea of the environment can help.
As an example, let’s say there is an issue with a web server, like a vulnerability in PHP,
a programming language for web development. However, the website could be con‐
figured with two-factor authentication and special access could be granted just for
this scan. This means only authenticated users could get access
to the site to exploit
the vulnerability.
Just because mitigations are in place for issues that may reduce their overall impact
on the organization doesn’t mean those issues should be ignored. All it means is that
the bar is higher for an attacker, not that it’s impossible for the exploit to happen.
Experience and a good understanding of the environment will help you to key in on
your findings. The objective shouldn’t be to frighten the
bejeebers out of people but
instead to provide them with a reasonable expectation of where they sit from the
standpoint of exposure to attack. Working with the organization will ideally get them
to improve their overall security posture.
The next column to talk about is the QoD, or Quality of Detection, column.
As noted
earlier, the vulnerability scanner can’t be absolutely certain that the vulnerability
exists. The QoD rating indicates how certain the scanner is that the vulnerability
exists. The higher the score, the more certain the scanner is. If you have a high QoD
and
a high severity, this is probably a vulnerability that someone should be investigat‐
ing. As an example, one of the findings is shown in
Figure 4-14
. This has a QoD of
99% and a severity of 10, which is as high as the scanner goes. OpenVAS considers
this a serious issue that it believes is confirmed. This is
shown by the output received
from the system under test.
Figure 4-14. Ruby finding in OpenVAS
