25

Say, I have scanned our Cisco Router, and it returned 20 vulnerabilities back. However, most of them are tied to specific services that this router is not running, for example CVE-2016-6380 - we are not running dns server on our cisco thus we are not vulnerable to it.

On one hand, I should exclude this vulnerability from the report - we are not ACTUALLY vulnerable, and all this white noise quickly adds up and the report becomes useless, because nobody reads it.

On the other hand, what if one day we decide to turn dns or other service on? We won't know we are vulnerable because it is no longer in scope.

So I wonder whether you can point me in the right direction here. I'm currently skimming through NIST 800-115, but can't find the answer yet. Does NIST say anything about it at all?

TLDR

Should a vulnerability in a service that is present on the device, but not running and not used at all, be mentioned in the vulnerability report?

shivelin
  • 458
  • 4
  • 7
  • 17
    Practical note: If you are mostly worried about the readability of the report, consider presenting these kind of vulnerabilities in a clearly separated way. For instance in a different paragraph, or even in an appendix. – Dennis Jaheruddin Jul 27 '17 at 12:49
  • 1
    Mention it as outdated software/firmware with known vulnerabilities. Attach a low risk to the issue and mention that they seem not exploitable. You say "most of them", did you validate all 20 vulnerabilities? – Silver Jul 27 '17 at 14:11
  • Depending how likely you think it is that the service will be enabled in future, you might consider the fact it isn't running now as (a) strong enough mitigation to make the vuln not worth mentioning; (b) a reasonable mitigation to downgrade this vulnerability from critical to "worth mentioning in the appendix"; (c) no mitigation at all. That is, unless you know what the router is for (and can be confident it won't be re-purposed while still relying on your report), you can't make sensible decisions what to leave out. – Steve Jessop Jul 27 '17 at 16:09
  • 1
    Specifically, "if one day we decide to turn dns or other service on? We won't know we are vulnerable" suggests to me that you would *not* repeat the vulnerability scan at the point of enabling additional services. But this is kind of "obviously" a bad idea, when I put it like that, so maybe that's not really what would happen :-) – Steve Jessop Jul 27 '17 at 16:12

4 Answers4

32

It depends on how your organization uses these kind of reports.

If the people responsible for planning and/or implementing security controls read these documents once and then never look at them again OR see them more as a guideline than actual rules on how to set up an environment, I can see that you might want to refrain from adding too much information into the report. Just because you want to make sure that the vulnerabilites that are acutally present are met with saftey measures.

On the other hand if these are "living" documents that set rules on how controls have to be planned and implemented AND the people who are responsible update these documents if the infrastructure changes at a certain point, you definitely want to include these vulnerabilites.

IMHO as someone who organizes information security in an institution this is the kind of culture you should push for.

If you are afraid that your document will become too cluttered, you can always work with its structure. Something that was done in an organization I worked with, was, that vulnerabilites like this or possible future vulnerabilities were added in an annex to the main document. If the infrastructure was changed in any way, admins could check the annex first, if any of the changes would bring in the vulnerabilities listed there.

One last point I would like to make: although YOU didn't enable those features, this doesn't mean an attacker won't do it after he/she got access to the router. So implementing security measures just in case can be reasonable. This might be something that should be evaluated in a risk analysis though.

To quote ISO/IEC 27005:

The presence of a vulnerability does not cause harm in itself, as there needs to be a threat present to exploit it. A vulnerability that has no corresponding threat may not require the implementation of a control, but should be recognized and monitored for changes.

Tom K.
  • 7,913
  • 3
  • 30
  • 53
  • 3
    Vulnerability report, pirate's code—eh, same difference. – Wildcard Jul 27 '17 at 21:15
  • 1
    Structuring the document is very important; put known but (currently) inactive vulnerabilities in a separate section, and call them out as such -- indicate that they are not *active* but should still be considered when changing configurations or upgrading. – Doktor J Jul 28 '17 at 17:47
10

As a customer of vulnerability reports, I would say yes, but it is certainly a waste of time to give it equal weight as other vulnerabilities. E.g., live, exploitable massive remote access holes or active malicious backdoors wouldn't get the same coverage as something like a DoS vulnerability or in this case a vulnerability in a disabled bit of software.

IMHO the report should have an executive summary, a technical findings, then go into the tedious detail.

Something like what you describe would be a one-liner in the technical findings and have some info in the tedious details section.

CVE-2016-6380 would however mean that you're not regularly patching the devices, or you have a very slow patch cycle. This might be an accepted risk on the customer's part, but it should be reviewed. It may be worth mentioning this in the executive summary. No CVE# stuff, execs don't care.

See further in NIST 800-115 7.3

...

While individual vulnerabilities need to be identified and resolved, identifying the root cause of vulnerabilities is key to improving the organization’s overall security posture because a root cause can often be traced to program-level weaknesses. Some common root causes include:

  • Insufficient patch management, such as failing to apply patches in a timely fashion or failing to apply patches to all vulnerable systems

...

Community
  • 1
mgjk
  • 7,535
  • 2
  • 20
  • 34
6

First of all you need to have a scope of what you are scanning for and what you are reporting on.

For example is the scope of the scanning to discover and report on all vulnerabilities including low risk vulnerabilities, or just high risk one, or maybe just critical vulnerabilities. This should have been defined before you even started the vulnerability scanning.

If it is a confirmed false positive then remove it from the report.

If it a service that is present but not used and it is a confirmed in scope vulnerability then include it in the report so the service can be removed from the target.

TheJulyPlot
  • 7,669
  • 6
  • 30
  • 44
2

If someone makes a buying decision, they might say "this router supports DNS resolution in the router. We don't use this now, but we might do so in the future, so we buy this router and not a slightly cheaper one without the feature".

That vulnerability means the router cannot be used that way, so the feature mustn't be used for the buying decision. In other words, it should be in your report for this reason. And if the service can be removed from the device, then it should be removed. (You might find out that your assumption that it wasn't used was actually wrong if the service is removed and people complain).

gnasher729
  • 1,823
  • 10
  • 14