Skip to main content

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 NameDescription
ExceptionThis 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.
False positiveThis request nominates the selected findings to be false positives.
Risk acceptanceThis request accepts the risks associated with the selected findings.

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:

Remediation request workflow

Figure 1. The remediation request workflow

Submitters and Reviewers must be able to view the findings included in a remediation request. By default, only system administrators can view all the findings, but you can provide users of the Risk analyst role access to the relevant findings by creating risk owners and remediation owners clusters, respectively.

Common questions about remediation requests

What happens to the associated findings when the request is approved?

The behavior varies based on the type of request. Expand the sections below to find out the specifics:

Exception

When an exception request is approved, the status of the associated findings change as follows:

  • The status of active findings become "Risk temporarily accepted".
  • The status of fixed findings remain unchanged.

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 a finding is resolved before the exception expires, the status of the finding changes to "Fixed".

Findings with the risk-temporarily-accepted status still count as active risks for reports and tickets.

False positive

When a false positive request is approved, the status of the associated findings change to "False positive", and their compliance status is always "No SLA required”

Findings with the false-positive status do not count as active risks for reports or tickets.

Risk acceptance

When a risk acceptance request is approved, the status of the associated findings change to "Risk accepted", and their compliance status is always "No SLA required”.

Findings with the risk-accepted status still count as active risks for reports, but they cannot generate tickets because they are considered closed.

This may affect the risk score of the host that the finding resides on. Specifically, if the risk-accepted finding is the only critical finding that the host has, the host's risk level might be downgraded. This downgrade occurs because a host's risk score is based on the highest risk score of its open findings. Since this single critical finding now has a status of "Closed," the host's risk score would be adjusted to reflect the next highest risk score among its open findings.

What happens to the associated findings when the request is expired?

The behavior varies based on the type of request. Expand the sections below to find out the specifics:

Exception

If the associated findings are not resolved by the extended due date, and the exception request has been approved, the request becomes expired 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.

Exception requests that haven't been approved do not expire, even if the extended due date specified in the request has elapsed.

False positive

False positive requests do not expire but they can be canceled, whereupon the findings' status are reverted.

Risk acceptance

Risk acceptance requests do not expire but they can be canceled, whereupon the findings' status are reverted.

What happens to the associated findings when the request is reopened?

If needed, you may reopen expired exception requests, whereupon the status of the associated findings are reverted. The requests can then be submitted for review and go through the remediation request workflow again.

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.

Create a request manually

To create a request manually, follow these steps:

  1. Navigate to Findings.

  2. Click the checkbox next to the findings you want to include in the request.

  3. Click the Select an action drop-down to choose the request you want to create.

    The Select an action option doesn't display until you select at least one finding.

  4. 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 or expiration date for the exception. This field is only available in exception requests.

    • Submitter: Select the user designated to be the submitter. The user must possess the Risk analyst role, and you can restrict their access to specific findings by assigning them to a risk owners cluster.

    • Reviewer: Select the user designated to be the reviewer. The user must possess the Risk analyst role, and you can restrict their access to specific findings by assigning them to a remediation owners cluster.

  5. Click Submit.

note

When creating a remediation request, you may encounter the following error message:

"The flow cannot be launched because it does not pass the condition. All items did not meet the condition."

This error occurs when some of the findings selected have already been included in another request and therefore cannot be added to the new one. To proceed, ensure that only findings not already tied to an existing request are selected for the new exception request.

Create a request through automation

To create a request through automation, follow these steps:

  1. Navigate to Automation.

  2. Click Create.

  3. Provide a title and description for the automation.

  4. Type a BQL query to limit your findings.

  5. Click Test to ensure that your query is valid and returns the expected data.

  6. 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 or expiration date for the exception. This field is only available in exception requests.

    • Submitter: Select the user designated to be the submitter. The user must possess the Risk analyst role, and you can restrict their access to specific findings by assigning them to a risk owners cluster.

    • Reviewer: Select the user designated to be the reviewer. The user must possess the Risk analyst role, and you can restrict their access to specific findings by assigning them to a remediation owners cluster.

  7. 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.

  8. Click Create.

The Automation page reloads and your new automation appears in the list of available automations.

Review remediation requests

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.