All Vulnerabilities in SecurityCenter

Don't accept/recast risk for Critical vulnerabilities that are also Exploitable without first discussing with the security team for approval.
Should always either remediate, accept, or recast Critical and High vulnerabilities.
If you are going to Accept or Recast Risk, comments and expiration date (reasonable length no longer than a year) are always mandatory.
- An expiration date is how long you are going to accept or recast risk for, when a risk is accepted or recast it falls off the vulnerability reports and into the accepted/recast risk reports reviewed by a committee. When the day of the expiration comes around those vulnerabilities will fall off the accepted/recast risk reports and return to the vulnerability reports.
"No known exploits" is not a valid reason by itself for accepted or recast risk (an exploit could come out tomorrow).
No need to accept/recast risk if Low severity (or lower).

Accepted Risk

Accepted Risk is accepting you won't/can't fix (intentionally not addressing the issue), at the Tenable reported severity.
Put reason why you can't fix in the comments, especially highlighting if due to lack of resources.
Should be accepted risk if there is a time period involved (i.e. decommissioning system soon, expiration date as the shutdown date), "low risk server", "no important data", or if unable to fix.
If implemented compensating controls, use this to accept the residual risk (explain compensating controls in the comments).
If system has already been shut down, re-run scan to verify it is no longer there rather than accept risk.

Recast Risk

Recast Risk is when you disagree with the Tenable ranking based on risk of the asset, whether it they think it should be higher or lower.
False positives, an inaccurate answer based on incomplete data, should be labeled as recast risks after you've verified it. Mention in the comments you believe it is a "false positive". (Can also run a credentialed scan to be more accurate and less likely occurrence of false positives).

Examples for Accepted Risks

Good Example #1

Comment :

We are accepting risk on this high severity vulnerability as of Sept. 1st, 2017 since we have a current working plan in place to migrate this server to a newer version of the OS with up to date patches on Oct. 1st, 2017 (within 30 days). There is a current working project for this in ServiceNow under ticket # PRJ12345678. There is no restricted or sensitive data on this system, it is used to store pictures of Peter the Anteater only. We currently have several security controls in place to help mitigate the risk, including having this system behind a departmental firewall, the system is only accessible from 1 IP (1.1.1.1) at this time and access is restricted down to just port 123. Only one account is able to login to this system and has a complex password with multi-factor authentication required.

Expiration Date: 10/1/2017

Good Example #2

Comment:

We are accepting risk on this high severity vulnerability as of Sept. 1st, 2017 since the vendor has no patch available at this time to remediate the issue. In the meantime we have locked down this system by removing it from the border firewall so it can't be accessible off campus, we have placed it behind a departmental firewall and locked down the access to just 3 IPs (1.1.1.1, 1.1.1.2 & 1.1.1.3). At this time there is no restricted or sensitive data on the device, only information on the device is configuration information. We will set expiration date for 30 days so we can re-evaluate with the vendor to see if a new fix has come out.

Expiration Date: 10/1/2017

Bad Example #1 (likely to be rejected by review committee)

Comment:

This server will be decommissioned ASAP

Expiration Date: None

Bad Example #2 (likely to be rejected by review committee)

Comment:

There are no current exploits for this system, accepting risk.

Expiration Date: None

Bad Example # (likely to be rejected by review committee)

Comment: None

Expiration Date: None

Examples for Recast Risks

Good Example #1

Comment :

We are recasting the risk from High to Info on this vulnerability as of Sept. 1st, 2017. We believe that is vulnerability is a false positive because we are currently on RedHat software libraries and they are using backporting to apply new security updates to older versions of software but they do not change the version number. Here is a link to the release notes showing the security patch backported into the version we using which would resolves this vulnerability. We have reached out the to the Security team regarding this false positive to let them know in order to resolve with Tenable. Putting an expiration 2 months out so we can review again to see if this false positive was resolved by the vendor.

Expiration Date: 11/1/2017

Bad Example #1 (likely to be rejected by review committee)

Comment:

This is a false positive.

Expiration Date: None

Browser not supported