DRAFT
- Accepted Risk is accepting you won't/can't fix 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?