Recast/Accept Rules

Note: If a rule is targeted by IP address, that rule applies to the specified IP in each network in which it is found. For more information, see networks.

Recast Rules

You can use recast rules to modify the severity of vulnerabilities. Vulnerabilities that you recast are identified as such on the Findings Details page. If you specify an expiration date for a recast rule, upon expiration Tenable Vulnerability Management reverts existing dashboards back to their original severity. Historical scan results, however, remain unchanged.

For Tenable Vulnerability Management standalone customers, recasted severities do not affect scores such as VPR, CES, or AES. Tenable One and Tenable Lumin customers, however, may notice updated scores if a recasted severity is included in their score calculations.

Note: When recasting custom scan targets, Tenable Vulnerability Management supports only the following asset values:
  • IPv4
  • IPv6
  • Hostname
  • FQDN

For example, you may have a set of internal servers that you scan regularly. These internal servers use self-signed certificates for SSL connections. Since the certificates are self-signed, your scans have been reporting vulnerabilities from plugin 51192, SSL Certificate Cannot Be Trusted, which has a Medium severity. Since you are aware that the servers use self-signed certificates, you create a recast rule to change the severity level of plugin 51192 from Medium to Info, and set the target to those internal servers.

The dashboards reflect the effect of a recast rule. A tag appears to indicate when vulnerabilities have been recast. The rule applies to all assets or a specific asset based on the rule's parameters. As long as the rule remains in effect, the rule applies to the corresponding data and scan results.

Note: While recasting Tenable Nessus Network Monitor plugins, the original severity is unknown.

  • Because Tenable PCI ASV scans using the PCI Quarterly External Scan template have their own set of rules, any recast rules do not apply to the scan results.
  • Frictionless Assessment connectors do not support recast rules.

Accept Rules

You can use accept rules to accept the risk of a vulnerability without modifying the severity level of the plugin. Vulnerabilities that have been accepted are still identified by a scan, but hidden in the results of the scan. To view accepted vulnerabilities, you can use the Recast & Accept filter. If you specify an expiration date for an accept rule, upon expiration Tenable Vulnerability Management no longer accepts the risk of the vulnerability. Historical scan results, however, remain unchanged. Accepted severities do not affect scores such as VPR, AES, or CES.

Consider the previous example. Rather than recasting the severity level from Medium to Info, you acknowledge that there is a risk associated with using self-signed certificates, but you do not want to see the vulnerability appearing for those servers any longer. You create an accept rule to accept the risk of plugin 51192, which hides that vulnerability for the targets you specified. If the same vulnerability is identified on other assets during the scan, those still appear in the scan results.

Tenable Vulnerability Management reflects the effect of an accept rule. Accepted vulnerabilities are hidden, and can be viewed using the Recast & Accepted filter.

False Positives

Additionally, you can use an accept rule to report false positives. Tenable reviews reported false positives in order to identify potential issues with a plugin.

Consider again the previous example. In this case, you know the servers in question are in fact using certificates from a proper Certificate Authority. However, plugin 51192 continues to report vulnerabilities for those servers. To hide the false results and report the issue, you create an accept rule that accepts the vulnerability as a false positive.

Integrity of Scan History

In the case of both recast and accept rules, the historical results of a scan are not modified. Scan history is immutable in order to provide an accurate representation of the scan over time, and to prevent any internal or external auditing issues that might be created by the scan history changing.

For more information, see the following topics: