Recently Viewed Topics
About Recast Rules
To access the Recast Rules page, on the top navigation bar, click Settings, and then on the left navigation bar, click Recast Rules. The Recast Rules page appears.
Note: The Recast Rules feature replaces the Plugin Rules feature. Any existing plugin rules are migrated to recast rules.
Via the Recast Rules page, you can create, edit, and delete recast and accept rules.
Recast rules are used to modify the severity of vulnerabilities. Vulnerabilities that have been recast are identified in the results of your scan. In the results of your scan, you may have the same vulnerability identified on multiple assets but a mix of severity levels because of the targets of your recast rule. If you specify an expiration date for a recast rule, after that rule expires, severity levels that had been recast in historical scan results are not changed.
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 effect of a recast rule is reflected on your workbenches. 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. The rule continues to apply to existing data and scans as long as the rule is in effect.
Accept rules are used 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.
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.
The effect of an accept rule is reflected on your workbenches. Accepted vulnerabilities are hidden, and can be viewed using the Recast & Accepted filter.
Additionally, you can use an accept rule to report false positives. Reported false positives are reviewed by Tenable, Inc. 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.