Remediation Requests
This article details the different remediation requests you can create in the Brinqa Platform and the request workflow.
What are remediation requests?
In vulnerability management, an exception is a decision to deviate from the standard remediation process for a known vulnerability. Exceptions are typically granted when the vulnerability is a false positive, implementing the mitigation needs more time, or remediation of the vulnerability is deemed infeasible.
As you adopt the Brinqa Platform to prioritize vulnerabilities and accelerate the remediation process, you can create remediation requests to handle exceptions. You can select the relevant findings and create requests for time-based extension, false positives, or risk acceptance. The following table provides more details on each type of the requests:
| Request Name | Description | What happens if the request is approved |
|---|---|---|
| Exception | This request asks for a time-based extension on the selected findings. You need to specify the extension date by which the findings must be resolved. | If the request is approved, the status of active findings change to "Risk temporarily accepted" while the status of fixed findings remain unchanged. Findings with the risk-temporarily-accepted status still count as active risks for reports and tickets. Their Extended due date attribute is set to the date specified in the exception request and the compliance status is evaluated against the extended due date instead. If the findings are not resolved by the extended due date, the approved exception request expires and the status of the findings are reverted. The extended due date entries are removed and the compliance status is re-evaluated against the original due date. You must re-submit the request if it still applies. Un-approved exception requests do not expire. |
| False positive | This request nominates the selected findings to be false positives. | If the request is approved, the status of the findings change to "False positive". Findings with the false-positive status do not count as active risks for reports or tickets. False positive requests do not expire but they can be canceled, whereupon the findings' status are reverted. |
| Risk acceptance | This request accepts the risks associated with the selected findings. | If the request is approved, the status of the findings change to "Risk accepted". Findings with the risk-accepted status still count as active risks for reports, but they cannot generate tickets because they are considered closed. Risk acceptance requests do not expire but they can be canceled, whereupon the findings' status are reverted. |
The remediation request workflow
In the Brinqa Platform, a remediation request workflow involves a submitter and a reviewer. Submitters can create requests or submit requests created by other authorized personnel. Reviewers evaluate the selected findings and approve or reject the requests. The designated users receive notifications when they need to perform an action and they must provide a justification for each action they take. All activities in the workflow are audited for compliance purposes. The following diagram illustrate the process:
Figure 1. The remediation request workflow
Submitters and Reviewers must be able to view the findings included in a remediation request, but only system administrators can view all the findings by default. However, you can provide users of the Risk analyst role access to the relevant findings by creating a risk owners and remediation owners cluster respectively.
Create remediation requests
There are two methods to create remediation requests:
Select the findings manually. The list of findings in the request does not change if you select the findings manually.
Use automations. The list of findings in the request updates automatically each time the automation runs.
The benefit of using automations is that you can set the automation to run at a schedule or as part of the data orchestration, so that the Brinqa Query Language (BQL) query you specify to identify the findings is executed every time the automation runs, keeping the findings in the request dynamic and up-to-date.
To create a request manually, follow these steps:
Navigate to Findings.
Select the findings you want to include in the request.
Click the Select an action drop-down to choose the request you want to create.
A request form displays with the following fields:
Name: Enter a name for your request.
Description: Provide a description for the request.
Justification: Provide an explanation for the request.
Evidence: Provide evidence to support your explanation.
Exception request date: Select the extension date for the exception. This field is only available in exception requests.
Submitter: Select the user designated to be the submitter.
Reviewer: Select the user designated to be the reviewer.
Click Submit.
To create a request through automation, follow these steps:
Navigate to Automation.
Click Create.
Provide a title and description for the automation.
Type a BQL query to limit your findings.
Click Test to ensure that your query is valid and returns the expected data.
In Actions, select the request you want to create and fill out the following fields:
Name: Enter a name for your request.
Description: Provide a description for the request.
Justification: Provide an explanation for the request.
Evidence: Provide evidence to support your explanation.
Exception request date: Select the extension date for the exception. This field is only available in exception requests.
Submitter: Select the user designated to be the submitter.
Reviewer: Select the user designated to be the reviewer.
In Run, select a method to run the automation:
Manual: Select this option if you don't want any changes to the list of findings in the request. You can manually run the automation once.
Schedule: Select a schedule from the drop-down.
Orchestration: Select After consolidation from the drop-down.
If you want the list to be updated automatically, select a schedule for the automation to run or set it to run as part of your data orchestration.
Click Create.
The Automation page reloads and your new automation appears in the list of available automations.
After a request has been created, submitters can revise the requests before submitting. The reviewer specified in the request receives an email after a request has been submitted. Reviewers then evaluate the findings and offer an approval or rejection. Submitters have the option to re-submit a request after it has been rejected. Submitters can also cancel requests. If the request has already been approved when it is canceled, the findings are removed from the request and their status are reverted.
Navigate to Remediation > Requests to view the requests. Users can only see the requests that they have access to, including the following:
Requests that you have created
Requests on findings that you can view
Requests of which you are a reviewer
Hold the pointer over the request and click Details to launch the detailed view of the request. The designated owners can perform actions through the buttons on the upper-right corner. Click the Comments & Attachments tab to view the justification (as comments) for each action and the Activity tab for the timeline.