Status Configurations

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:

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.

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

  • The lifecycle status on the Unified data model (UDM) indicates the current status of the dataset based on the Data lifecycle management (DLM) policy. Lifecycle statuses include active, inactive, or not applicable.

• 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

  • Status category is calculated based on the asset’s or finding’s status. It simplifies the status by grouping statuses into broader categories. See Asset status categories and Finding status categories for additional information.

Asset statuses

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

Table 1: Normalized Asset statuses

Status Value	Description
Assumed active	The data integration cannot confirm if the asset is active, stopped, or terminated. The status configuration assumes that the asset is active and running.
Assumed inactive	The 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 active	The data integration confirms that the asset is in a running state.
Stopped	The asset is in a non-running state but could run again.
Terminated	The asset is discontinued and cannot run again.
Unknown (default)	There 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 Category	Description
Active	The status category of an asset is considered active if the asset has one of the following statuses: confirmed active, assumed active, or unknown.
Inactive	The 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 Value	Description
Assumed active	The data integration cannot confirm if the finding is active, stopped, or terminated. The status configuration assumes that the finding is active and current.
Assumed fixed	The data integration cannot confirm if the finding has been fixed. The status configuration assumes that the finding has been fixed.
Confirmed active	The data integration confirms that the finding is current.
Confirmed fixed	The data integration confirms that the finding has been fixed.
False positive	The status configuration determines that the finding is a false positive.
Risk accepted	The status configuration determines that the risk associated with the finding is acceptable to the business and won't be remediated.
Risk temporarily accepted	The 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).
Unknown (default)	There 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 Category	Description
Open	The 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.
Closed	The 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

Name	Description	Condition	Preset
Asset source status is active	If the source status of the asset is active, set the normalized status to "confirmed active".	sourceStatus = "active"	Default value: confirmed active
Asset source status is terminated or stopped	If 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"]	Value from the Source status attribute
Asset has no valid source status but data lifecycle is active	If 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"	Default value: assumed active
Asset has no valid source status but data lifecycle is inactive	If 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"	Default value: assumed inactive
Asset has no source status or data lifecycle	If there is neither a valid source status nor a data lifecycle status for the asset, set the normalized status to "unknown".	true	Default value: unknown

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

Name	Description	Condition	Preset
Finding source status is fixed	If the source status of the finding is fixed, set the normalized status to "confirmed fixed".	sourceStatus = "fixed"	Default value: confirmed fixed
Finding has approved false positive request	If 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"	Default value: false positive
Finding has approved remediation validation request	If the finding is an approved remediation validation request, set the normalized status to "confirmed fixed".	approvedRemediationValidationRequest = true	Default value: confirmed fixed
Finding has approved risk acceptance request	If 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"	Default value: risk accepted
Finding has approved exception request	If 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"	Default value: risk temporarily accepted
Finding source status is active	If the source status of the finding is currently active, set the normalized status to "confirmed active".	sourceStatus = "active"	Default value: confirmed active
Finding source status is reopened	If the source status of the finding is reopened, set the normalized status to "reopened".	sourceStatus = "reopened"	Default value: reopened
Finding targets status category is inactive	If the status category of the finding's target is inactive, set the normalized status to "assumed fixed".	targets.statusCategory = "inactive"	Default value: assumed fixed
Finding has no valid source status but data lifecycle is inactive	If 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"	Default value: assumed fixed
Finding has no source status or data lifecycle	If there is neither a valid source status nor a data lifecycle status for the finding, set the normalized status to "unknown".	true	Default value: unknown

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 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":

   

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

Tutorial: Create a status configuration for retired hosts

This tutorial demonstrates how to create a custom status configuration model that updates the status of hosts to "Confirmed inactive" if their Source status attribute is set to "retired". Normalizing source-specific statuses, such as "retired", to standardized values like "Confirmed inactive" helps maintain consistency of status values across the Brinqa Platform. To create this status configuration, follow these steps:

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

2. Click Add .

3. Complete the following fields:

   • Name: Type "Retired Hosts".

   • Description: Type "This status configuration updates the status of hosts to "confirmed inactive" if their Source status is set to "retired" or "Retired".

   • Preset: Click the drop-down, select Default value, and then type "confirmed inactive" in the Default value text box.

     The Preset field determines how the status is calculated. By selecting Default value, you can set a fixed status value to be used for any host that meets the specified conditions.

   • Conditions: Click +. Additional options display below.

     • Target data model: Type "Host" or click the drop-down and select Host.

     • Toggle Active.

     • Order: Type "100".

       The Order field determines the sequence in which the Brinqa Platform evaluates the conditions for the Host data model. Setting the order to "100" ensures that this status configuration is evaluated after other conditions with lower order values but before configurations with higher values. Use "100" here as a general starting point, and adjust as necessary based on your specific configuration needs.

     • BCL: Type the following BCL: sourceStatus CONTAINS ANY ["retired", "Retired"].

       This BCL statement identifies hosts where the sourceStatus attribute is set to "retired" or "Retired", accounting for possible case variations in the attribute values.

     • Test: Click Test to see if the BCL retrieves the expected results.

   • Active: Keep as is. Active is selected by default.

   The screenshot below illustrates the completed configuration setup:

   

4. Click Create.

The Manage status configuration models page reloads, and the "Retired Hosts" status configuration model appears in the list view. This status configuration automatically updates the status of hosts with a Source status of "retired" to "confirmed inactive". You can use this configuration to easily identify and manage retired hosts.

To put the new status configuration model into effect, see Launch status configuration models for information on how to do so.

Troubleshooting tips

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

Unable to create a new status configuration or clone an existing one

If you encounter the following error when trying to create a new status configuration model or clone an existing one, it indicates that another status configuration model already exists with the same target data model and order value. To ensure proper condition evaluation, the Brinqa Platform requires unique combinations of target data models and order values:

Unable to validate attribute constraints.

There is already a condition on a <StatusConfigurationModel> targeting a <DataModelName> with order <OrderNumber>.

In the above error message, "StatusConfigurationModel" is the name of the existing status configuration causing the conflict, "DataModelName" is the name of the target data model, and "OrderNumber" is the order value assigned to the condition.

To resolve this issue, modify the Order field in the new or cloned status configuration model to a different value that does not conflict with any existing status configuration model. For example, if the new or cloned model uses "100", try using another available order number.