DRAFT
...
Both
- Comments and Expiration Date (reasonable length no longer than a year) are always mandatory
- "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 re-run scan to verify it is no longer there or create 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?
- .
- 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).