This article covers what each risk exception is and how to effectively manage exceptions in the “Exception Request” page.
Prerequisites
– User should be logged in as administrator or Security Champion
This area focuses on managing exceptions to security risks identified across the organization’s applications and environments. It categorizes exceptions into various statuses, such as “In Queue,” “Mitigation Accepted,””Recasting Accepted”, “False Positive,” and “Rejected,” allowing for structured tracking and resolution of exceptions. This section is important for security users to view all the vulnerabilities set as false positives or mitigations, and for engineering users to approve/reject false positives or risk mitigations.
Navigation
In Queue
This section is to be used by Security users to manage risk exceptions, including false positives and risk mitigations, proposed by engineering users. It includes a queue-structured table with exceptions for higher priority/significance at the top of the table/queue.
To accept/reject a proposal, follow this process:
- Click on the Grey empty box in the first field of the exception to be rejected/accepted. There is an option to select multiple exceptions by clicking on other grey boxes, as indicated by the red arrow. However, this is not advised as a reason must be given for the rejection/acceptance and is unlikely to be valid for multiple risk exceptions.
- Click on the blue Accept/Reject risk button on the top right hand side of the table.
- Enter the reason for the acceptance/rejection and click on the blue Accept or Reject button to remove the exception from the queue. Rejected exceptions will appear in the rejected section table, while accepted exceptions will appear in either the Mitigation accepted or False Positive section, depending on the exception type.
Mitigation Accepted
Risk mitigation is to be set for vulnerabilities/assets that aren’t as severe as they appear to be.
This section is to be used by security users to view and manage approved risk Mitigations as well as Risk Acceptance. There is an option to filter the exceptions by application/environment on the top left-hand side of the page, which caters to faster searching for exceptions. This app/env filter can be used as a filter to find exceptions you or your team is responsible for by searching for an application/environment assigned to your team. The exceptions are ordered by risk level, with the highest at the top. You can also hover over each row to see the original risk level to review the effect of each risk mitigation.
A risk acceptance should be created when a user encounters a failing API gate due to a specific finding, and needs that finding to be excluded in order to proceed with the deployment to production. For example, the API gate may require that there to be no more than 3 critical findings, and it is failing because there are 4. This API gate would be blocking deployment to production due to policy enforcement, so one of these criticals could be marked as a “Risk Acceptance” to ensure the API gate passes. This is not recommended for criticals, but more so for lower risk levels, where ignoring a finding will not put you at risk.
To delete a Mitigation, click on the three dots on the right-hand side of a row and select “Delete”.
Recasting Accepted
This section is used by security administrators and security champions to view and manage all approved Risk Recasts. A risk recast is a reassessment of a vulnerability’s severity—typically used when the default risk score does not accurately reflect the real-world impact within your specific environment.
You can filter the displayed risk recasts by application or environment using the filter menu on the top left-hand side of the page, allowing for faster identification of items relevant to your team. Each recast entry displays both the adjusted risk level and the original risk level, so you can clearly assess the impact of the recast decision.
To delete a risk recast, click on the three dots on the right-hand side of a row and select “Delete”. This action will remove the adjusted severity and return the vulnerability to its original classification.
False Positive
Setting an asset/vulnerability/finding as a false positive will mark it as no longer a threat and will mean it no longer contributes to the global risk score/risk score of the application/environment it is within.
This section is for security users to view approved false positives and is essential for administrators to regularly review false positives accepted to ensure there are no inconsistencies or wrongly accepted false positives. The acceptance date field can be used as a guide to identify newly accepted false positives.
Rejected
When a security user rejects an exception from the queue section, it will appear here. It has a rejection date field so users can see when it was rejected and who the responsible user is. To view exception details, click on the exception.
You can view the proposed reason for the false positive by clicking on a rejected exception. Underneath, there is also a reason why the exception proposal has been rejected.
