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.
You can use recast rules to modify the severity of vulnerabilities. Vulnerabilities that you recast are identified as such on the Vulnerability Details page. If you specify an expiration date for a recast rule, upon expiration Tenable.io reverts existing dashboards back to their original severity. Historical scan results, however, remain unchanged.
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 NNM plugins, the original severity is unknown.
Note: Upon creation, recast rules do not apply to historical scan results; however, they do apply to existing data in Tenable.io.
Note: Because 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.
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.io no longer accepts the risk of the vulnerability. Historical scan results, however, remain unchanged.
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.io reflects the effect of an accept rule. Accepted vulnerabilities are hidden, and can be viewed using the Recast & Accepted filter.
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: