DRAFT
...
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
- Recast Risk is when Tenable is giving an inaccurate answer based on unknowns, aka false positive
- Recast Risk is when disagree with Tenable ranking based on risk of the asset or
- Must enter comment (reason why accepted or recast)
- If server is being shut down, don't recast, just .
- 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 or create rather than accept risk rule with an expiration of the shut down date
- False positives should be recast risk, not an accepted risk
- If intentionally not addressing issue, that should be an accepted risk not a recast risk
- Accepted risk should not be noted as recast risk too
- Don't use recast risk for "low risk server" or "no important data" reasons, that is an accepted risk
- Don't use recast risk if unable to fix, that is an accepted risk
- No need to accept/recast risk if Low severity (or lower)
- If fully mitigated and tool isn't recognizing that, then recast risk
- If partially mitigated then accept residual risk and put in comments how much was mitigated
- "No known exploits" is not a valid reason by itself for accepted or recast risk (an exploit could come out tomorrow)
- If there is a time period involved, should be accepted risk until that time period, don't use recast risk
Questions:
YES: Can you recast risk and then accept it (what's left) so that on the accepted risk report it shows the recast risk severity? Or we can assume that all recast risk is also accepted at that new severity. User training: if doing both, have to do recast first
If someone accept/recast risk now because of false positive, if there was something legit in the future for the same issue how would we know? (When no expiration date is given, otherwise it should pop up again after expiration date).
What are acceptable expiration date lengths?
Scope - can the tool accept all vulnerabilities for a system, or a vulnerability for all systems? Should that be allowed?
- .
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