Skip to main content

Status Configuration

This article details how the status for assets and findings are determined, the built-in status configuration models, and how to configure the status behavior for a given dataset.

What is status configuration?

Status Configuration in the Brinqa Platform is a mechanism for managing and tracking the status of your assets and findings. It ensures that the status of your assets and findings accurately reflects their current state by using contextual information from your data integrations and data lifecycle management policies. Status configuration enables you to adjust how the status of your assets and findings are determined to better meet the business logic needs and requirements of your organization.

The Brinqa Platform provides built-in status configuration models that define the rules and conditions under which statuses are determined and assigned. Status configuration models work by using the status information from your data integrations, lifecycle information from Source data models (SDMs), and contextual information specific to each record. This approach ensures flexibility and reliability in determining the status of your assets and findings, even when direct status information may not be available from your sources. The following diagram illustrates the status configuration model workflow:

Status configuration workflow overview

Figure 1: Status configuration model workflow.

Let's examine the scenario depicted in figure 2 below. The diagram illustrates the possible relationship between three different records, Violation, Container, and Host, with an emphasis on how the status of one record can impact the status of others. In this diagram, the Host serves as the underlying infrastructure on which the Container runs. The Container, in turn, is associated with a Violation through a targeting relationship. In this setup:

  • The Violation has an "active" lifecycle status and status, indicating that it is presently residing in the Container.

  • The Container has an "active" lifecycle status and status, indicating that it is operational and running.

  • The Host has an "active" lifecycle status and status, indicating that it is operational and running.

Status configuration example

Figure 2: Status configuration example.

If the Host is terminated, the system updates the Container's status to "stopped." Subsequently, the status of the Violation targeting the Container also updates to reflect the new status of the Container, changing from "active" to "inactive."

This updating ensures that the status configuration models in the Brinqa Platform accurately reflect the current state of your assets and findings.

Key terms

Before we dive into the details, let's clarify some key terms you'll see throughout this article and while working with status configuration models in the Brinqa Platform:

  • Lifecycle status

  • Source status

    • The raw status provided by data integration. It represents the status before being normalized by the Brinqa Platform.
  • Status

    • The normalized status of the asset or finding after it has been consolidated into the UDM. See Asset statuses and Finding statuses for additional information.
  • Status category

Asset statuses

Status configurations can return the following possible normalized status values for assets:

Table 1: Normalized Asset statuses

Status ValueDescription
Assumed activeThe data integration cannot confirm if the asset is active, stopped, or terminated. The status configuration assumes that the asset is active and running.
Assumed inactiveThe data integration cannot confirm if the asset is active, stopped, or terminated. The status configuration assumes that the asset is inactive and not running.
Confirmed activeThe data integration confirms that the asset is in a running state.
StoppedThe asset is in a non-running state but could run again.
TerminatedThe asset is discontinued and cannot run again.
UnknownThere isn't enough information to determine the status of the asset.

Asset status categories

Asset status categories are used to simplify the status of assets by grouping them into two broad categories, active or inactive.

Table 2: Asset status categories

Status CategoryDescription
ActiveThe status category of an asset is considered active if the asset has one of the following statuses: confirmed active, assumed active, or unknown.
InactiveThe status category of an asset is considered inactive if the asset has one of the following statuses: assumed inactive, stopped, or terminated.

Finding statuses

Status configurations can return the following possible normalized status values for findings:

Table 3: Normalized Finding statuses

Status ValueDescription
Assumed activeThe data integration cannot confirm if the finding is active, stopped, or terminated. The status configuration assumes that the finding is active and current.
Assumed fixedThe data integration cannot confirm if the finding has been fixed. The status configuration assumes that the finding has been fixed.
Confirmed activeThe data integration confirms that the finding is current.
Confirmed fixedThe data integration confirms that the finding has been fixed.
False positiveThe status configuration determines that the finding is a false positive.
Risk acceptedThe status configuration determines that the risk associated with the finding is acceptable to the business and won't be remediated.
Risk temporarily acceptedThe status configuration determines that the risk associated with the finding is temporarily acceptable to the business and won't need to be remediated within the normal Service-Level Agreement (SLA).
UnknownThere isn't enough information to determine the status of the finding.

Finding status categories

Finding status categories are meant to simplify the status of a findings by grouping them into two broad categories, open or closed.

Table 4: Finding status categories

Status CategoryDescription
OpenThe status category of a finding is considered open if the finding has one of the following statuses: assumed active, confirmed active, risk temporarily accepted, reopened, or unknown.
ClosedThe status category of a finding is considered closed if the finding has one of the following statuses: assumed fixed, confirmed fixed, false positive, or risk accepted.

Built-in status configuration models

The Brinqa Platform provides a set of predefined status configuration models that apply to assets and findings. These models determine the status of a record based on various criteria, such as whether a data source indicates that an asset is active, inactive, or deleted, the data lifecycle status of the record, and specific conditions defined in the configuration model. Each status configuration model uses the Brinqa Condition Language (BCL) to target and group records based on specific conditions.

For example, the built-in asset status configuration model, "Asset has no valid source status but data lifecycle is inactive", uses the following BCL query to identify and group asset records where there is no valid source status for the asset, and its data lifecycle status is inactive:

(sourceStatus IS NULL OR sourceStatus NOT IN ["active","stopped","terminated"]) AND lifecycleStatus = "inactive"`

Asset status configuration models

Users with the Configurator or System Administrator role can access the pre-defined asset status configuration models by navigating to Administration > Configuration > Status configuration models. The following table details the built-in status configuration models for assets:

Table 5: Asset Status Configuration Models

NameDescriptionCondition
Asset source status is activeIf the source status of the asset is active, set the normalized status to "confirmed active".sourceStatus = "active"
Asset source status is terminated or stoppedIf the source status of the asset is terminated or stopped, set the normalized status to the same value as the source status, which will be either "stopped" or "terminated".sourceStatus IN ["terminated", "stopped"]
Asset has no valid source status but data lifecycle is activeIf there is no valid source status for the asset, but the data lifecycle status is active, set the normalized status to "assumed active".(sourceStatus IS NULL OR sourceStatus NOT IN ["active","stopped","terminated"]) AND lifecycleStatus = "active"
Asset has no valid source status but data lifecycle is inactiveIf there is no valid source status for the asset, and the data lifecycle status is inactive, set the normalized status to "assumed inactive".(sourceStatus IS NULL OR sourceStatus NOT IN ["active","stopped","terminated"]) AND lifecycleStatus = "inactive"
Asset has no source status or data lifecycleIf there is neither a valid source status nor a data lifecycle status for the asset, set the normalized status to "unknown".true
info

All built-in asset status configuration models cover the following data models: Account, API endpoint, Application, Certification, Cloud resource, Code project, Code repository, Container, Container image, Device, Host, Host image, IP range, Network segment, Package, Service, Site, Site certificate, and Subnet.

Finding status configuration models

Users with the Configurator or System Administrator role can access the pre-defined finding status configuration models by navigating to Administration > Configuration > Status configuration models. The following table details the built-in status configuration models for findings:

Table 6: Finding Status Configuration Models

NameDescriptionCondition
Finding source status is fixedIf the source status of the finding is fixed, set the normalized status to "confirmed fixed".sourceStatus = "fixed"
Finding has approved false positive requestIf the finding is an approved false positive request or the source status is a false positive, set the normalized status to "false positive".approvedFalsePositiveRequest = true OR sourceStatus = "false positive"
Finding has approved remediation validation requestIf the finding is an approved remediation validation request, set the normalized status to "confirmed fixed".approvedRemediationValidationRequest = true
Finding has approved risk acceptance requestIf the finding is an approved risk acceptance request or the source status is risk accepted, set the normalized status to "risk accepted".approvedRiskAcceptanceRequest = true OR sourceStatus = "risk accepted"
Finding has approved exception requestIf the finding is an approved exception request or the source status is risk is temporarily accepted, set the normalized status to "risk temporarily accepted".approvedExceptionRequest = true OR sourceStatus = "risk temporarily accepted"
Finding source status is activeIf the source status of the finding is currently active, set the normalized status to "confirmed active".sourceStatus = "active"
Finding source status is reopenedIf the source status of the finding is reopened, set the normalized status to "reopened".sourceStatus = "reopened"
Finding targets status category is inactiveIf the status category of the finding's target is inactive, set the normalized status to "assumed fixed".targets.statusCategory = "inactive"
Finding has no valid source status but data lifecycle is inactiveIf there is no valid source status for the finding, and the data lifecycle status is inactive, set the normalized status to "assumed fixed".(sourceStatus IS NULL OR sourceStatus NOT IN ["active","fixed"]) AND lifecycleStatus = "inactive"
Finding has no source status or data lifecycleIf there is neither a valid source status nor a data lifecycle status for the finding, set the normalized status to "unknown".true
info

All built-in finding status configuration models cover the following data models: Alert, Dynamic code finding, Incident, Manual finding, Open source finding, Pentest finding, Static code finding, Violation, and Vulnerability.

Create a new status configuration model

If the built-in status configuration models do not fit your criteria or needs, users with the Configurator or System Administrator role can create a new one. Creating a status configuration model defines the rules and conditions under which statuses are determined and assigned to assets or findings.

To create a new status configuration model, follow these steps:

  1. Navigate to Administration > Configuration > Status configuration models.

  2. Click Add add or create button and complete the following fields:

    • Name: Provide a name for the status configuration model.

    • Description: (Optional) Provide a description for the status configuration model.

    • Preset: The different ways that the status is determined. Click the drop-down and select one of the following:

      • Value from attribute: Use the value of a specified attribute on any dataset or related data to determine the status. You must select the Preset attribute when specifying the condition(s).

      • Keep existing value: Preserve the current status value without making any changes.

      • Default value: Specify a default status to be used.

    • Conditions: Specify the conditions under which the status should be applied to your assets or findings. Click + and more options display below:

      • Target data model: Click the drop-down and type or select the data model to which the status configuration applies, e.g., Host.

        warning

        Avoid selecting a parent data model (such as Asset or Finding) as the target. For example, instead of Asset, select a data model that extends Asset, such as Account, Host, Cloud Resource, and so on. This is because parent data models are not computed during consolidation and choosing a parent data model results in empty counts in the status configuration model.

      • Preset attribute: If you selected Value from attribute for the Preset, click the drop-down and choose the attribute that contains the value to be used.

      • Active: Indicate whether the condition is active. This field is enabled by default.

      • Order: Specify the condition evaluation order for the target data model.

      • BCL: In the blank line, type your BCL query to specify the condition for the target data model. For example, status IS NOT NULL or id EXISTS.

      • Test: Click Test to see the results retrieved by the condition.

      Click + to add additional conditions to the status configuration model.

    • Active: Select Active. Inactive status configuration models are effectively archived.

  3. Click Create.

    The screenshot below illustrates what a new status configuration model may resemble. In this example, any Host record with a compliance status of "Compliant" is set to the normalized status of "confirmed active":

    Status configuration model example

The Manage status configuration models page reloads and your new status configuration model displays in the list view.

Clone an existing status configuration model

Rather than creating a new status configuration model from scratch, you can clone a built-in one and modify it to better fit your needs. Cloning not only allows you to keep the built-in status configuration model intact but also ensures that your modifications won't be overwritten during release updates. This way, you get a duplicated version to tailor as you like without unintentionally altering important default settings.

To clone an existing status configuration model, follow these steps:

  1. Navigate to Administration admin icon > Configuration > Status configuration models.

  2. Hold the pointer over the status configuration that you want to modify and click Clone.

  3. Make any necessary changes.

    note

    For each target data model included in the cloned status configuration models, you must modify the Order attribute. Failing to do so results in an error message when you attempt to create the clone.

    The Order attribute signifies the sequence in which the Brinqa Platform evaluates the conditions specified for the target data model. Therefore, the same data model cannot share the same order in both the built-in and cloned status configuration models.

  4. Select Active to activate the cloned status configuration model, and then click Create.

    The page reloads, and the cloned status configuration model displays in the list view.

    note

    If the cloned status configuration model's conditions include multiple target data models, your changes apply to all of them. For instance, if you clone a status configuration model that applies to the Open source finding, Pentest finding, and Violation data models, the cloned status configuration model displays on the respective data model pages.

Launch status configuration models

Your new status configuration model applies when the data orchestration runs. However, if you want the new status configuration model to go into effect immediately, follow these steps:

  1. Navigate to Administration admin button > Data > Models.

  2. Navigate to the data model you've selected as the target data model for the status configuration model, and click Flows.

  3. Click the compute flow for your data model. For example, if you have added a new status configuration model for the Host data model, click Host compute flow.

  4. Click Launch, and then click Launch again in the confirmation dialog.

  5. Repeat steps 2-4 for each target data model you've selected during the status configuration model creation process.

  6. Navigate to the Status configuration model data model and click Flows.

  7. Click Status configuration model compute flow, then Launch, and then click Launch again in the confirmation dialog.

The Status configuration model compute flow runs and computes the status for your status configuration model. Upon completion, check the status configuration model's detail page to verify the updated counts.

Activate or deactivate a status configuration model

If you want to activate a status configuration model, whether built-in or cloned, do the following:

  1. Hold the pointer over the status configuration model in the list view.

  2. Click Activate.

If you want to deactivate a status configuration model, whether built-in or cloned, do the following:

  1. Hold the pointer over the status configuration model in the list view.

  2. Click Deactivate.

This prevents any overlapping conditions from being applied twice.

Troubleshooting

Before troubleshooting your status configuration models, ensure that the data orchestration has successfully run. If you're still experiencing issues with the counts, one reason could be recent modifications to the status configuration model(s) haven't been applied. To resolve these issues, follow these troubleshooting tips.

Inaccurate or outdated counts

If you see inaccurate or outdated counts for the new status configuration model, clearing the cache may resolve the issue. Only users with the System Administrator role can clear caches. To do so, follow these steps:

  1. Navigate to Administration admin-button > System > Advanced.

  2. Select BQL Count cache and BQL Query cache.

    BQL Count cache is for charts and BQL query cache is for tables and list views.

  3. Click Clear data.

    Navigate to the status configuration model to see if the counts issue has been resolved.

Empty counts

If your newly created status configuration models contain no assets or findings, but the query produces results when you test the conditions, the issue might be due to selecting a parent data model during the creation process. Parent data models, such as Asset or Finding, are not computed during the consolidation process. As a result, selecting these as your target data model can lead to empty counts in the status configuration model.

To avoid this issue, make sure to select a child data model that extends one of these parent data models.

Statuses are not being set correctly

If the status of your assets and findings are not being set correctly, perform a full data orchestration. While you can follow the steps in the Launch status configuration models section to apply your new status configuration model immediately, running a full data orchestration ensures comprehensive processing and integration of all your data.