Service-level Agreements

This article details the service-level agreements (SLAs) data model and how to create or adjust service levels in your Brinqa Platform.

What is an SLA?

An SLA is a concept commonly used in service and support management. SLA establishes response times and due dates for incidents, tickets, or issues based on their severity or priority.

For example, you may define an SLA for vulnerabilities detected on assets with a compliance requirement:

• Critical vulnerabilities must be resolved within 30 days from the time they are initially identified.
• High vulnerabilities must be resolved within 60 days from the time they are initially identified.
• Medium vulnerabilities must be resolved within 90 days from the time they are initially identified.
• Low vulnerabilities must be resolved within 120 days from the time they are initially identified.

On the other hand, since SLA is not one-size-fits-all, you can define another SLA for vulnerabilities detected on assets without a compliance requirement:

• Critical vulnerabilities must be resolved within 90 days from the time they are initially identified.
• High vulnerabilities must be resolved within 120 days from the time they are initially identified.
• Medium vulnerabilities must be resolved within 365 days from the time they are initially identified.

With the Brinqa Platform, you can establish and oversee SLA definitions to ensure that your organization complies with specific requirements.

Brinqa built-in SLA definitions

The Brinqa Platform includes two SLA definitions out of the box. Users with the Configurator or System Administrator role can view the definitions by navigating to Administration and under Configuration, select SLA definitions.

• Default finding SLA definition: This SLA applies to all data models that extend the Finding data model. It defines service levels based on risk scores and calculates the due dates from the date that the findings are initially identified.

• Default ticket SLA definition: This SLA applies to all data models that extend the Ticket data model. It defines service levels based on risk scores and calculates the due dates from the date that the tickets are opened.

Both SLA definitions implement the following service levels:

Service levels	Risk scores	Due in
L1	9-10.1	7 days
L2	7-9	30 days
L3	4-7	90 days
L4	0-4	365 days

The risk score ranges are exclusive, so '7-9' covers risk scores from 7 to 9 but excludes 9.

Create your own SLA definitions

Users with the Configurator or System Administrator role can create new SLA definitions in your Brinqa Platform to help ensure that your organization is meeting certain compliance requirements. You can create multiple SLA definitions for a single data model or create a single SLA definition that applies to multiple data models.

To create a new SLA definition, follow these steps:

1. Navigate to Administration > Data > Models.

2. Locate the data model to which you want to add an SLA definition.

   note

   The data model must extend Finding or Ticket.

3. Click SLA.

4. Click Create and fill in the following information:

   • Name: Enter a name for your SLA.

   • Description: Provide a description for your SLA.

   • Calendar policy: Specify how to count the days for your SLA. Options include: Consecutive days or Business days. Business days include Monday through Friday.

   • Conditions: Click + to add criteria for each data model to which the SLA applies.

     • Target data model: Click the drop-down and select a data model that extends Finding or Ticket.

       caution

       Avoid selecting a parent data model (such as Finding or Ticket) as the target. For example, instead of Ticket, select a data model that extends Ticket, such as Dynamic code ticket, Manual ticket, Vulnerability ticket, and so on. This is because parent data models are not computed during consolidation and choosing a parent data model can result in inaccurate SLA calculations or issues with SLA tracking.

     • Measure attribute: Select the attribute to determine the levels of the SLA. Measured attribute is the numerical field that the service levels are based on.

       For example, the Default finding SLA definition uses Risk score as the measure attribute. This implies that the service levels are determined by the risk score of the finding, where level 1 is from 9 to 10, level 2 is from 7 to 9, and so on.

     • Start: Select the attribute to be used as the starting point of the due date computation.

       Options include all the Date Time attributes and calculated attributes that return a Date Time value. Attributes of the target data model and its direct one-to-one referenced data models are supported. For example, if you have selected the Vulnerability data model as the target, all Date Time attributes of Vulnerability and Vulnerability definition are available options for the Start field.

     • Active: Keep as is. You can click the toggle to inactivate this condition when it's no longer needed.

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

       This field is important because it signifies the order that the Brinqa Platform follows to evaluate the conditions specified in this SLA and other SLAs defined for the same data set. The evaluation stops after a match is found, ensuring that each record is subject to only one SLA. Therefore, it is logical to prioritize the most specific conditions first.

       On the other hand, if your SLA applies to multiple data models, the order you specify for each data model is independent of the others. Therefore, if you change the order in one data model after the SLA has been applied, the order of the same SLA in the other data models remains unchanged.

     • Condition: Specify the condition to which this SLA applies.

       The supported syntax is Brinqa Condition Language (BCL). For example: firstFound EXISTS or status = "active". You cannot create the SLA if the syntax is invalid.

5. Select Active. Inactive SLA's are effectively archived.

6. Click Create. The page reloads and you can now define the service levels of your new SLA.

7. In the Service levels section, fill in the following information:

   • Name: The name of the service level.

   • From and To: The measure attribute values for the service level. For example, if you choose Risk score as the measured attribute, you can set the Critical level to measure from 8 to 10.

   • Due in: The amount of time (in days or hours) before the findings or tickets are considered out of SLA.

   • Time unit: The time unit for the service level. Options include: Day or Hour.

8. Click + to add another service level or - to delete a service level.

9. Click Update.

Repeat these steps for each SLA definition you want to create.

Apply SLA definitions

Your new SLA definition applies when the data orchestration runs, which is once a day by default. If you want the new SLA to take effect immediately, follow these steps:

1. Navigate to Administration > Data > Models.

2. Navigate to the data model you've specified as the target data model in the SLA definition, and click Flows.

3. Click the compute flow for your data model. For example, if you have added a new SLA to the Vulnerability data model, click Vulnerability 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 in your SLA definition.

6. Navigate to the SLA definition data model page and click Flows.

7. Click SLA definition compute flow, then Launch, and click Launch again.

   • The SLA definition compute flow updates the total number of findings or tickets that are impacted by the new SLA definition.

During the compute flow, a due date is calculated for each finding or ticket that matches your SLA conditions. The calculation is based on the attribute selected in the Start field of your SLA definition and the service levels you have specified. Then a comparison is made between the due date and the current date. Your finding or ticket can be assigned the following compliance status:

• Exceeded SLA: the finding or ticket is resolved after the due date has passed

• Met SLA: the finding or ticket is resolved before the due date has passed

• No SLA Required: the finding or ticket does not fall under any service levels

• Out of SLA: the finding or ticket is still open after the due date has passed

• Within SLA: the finding or ticket is open and the due date has not passed

note

Although findings and tickets both use the Compliance status attribute, their meanings are different. For findings, the default SLA definition uses the First found attribute to calculate the due dates. Meeting SLA indicates that the findings are resolved timely, minimizing your risk exposure. For tickets, the default SLA definition uses the First created attribute to calculate the due dates. Meeting SLA indicates that the tickets are resolved within the required time frame.

To confirm that your new SLA has been applied, follow these steps:

1. Navigate to Findings or Remediation.

2. Click More to add the SLA definition filter if not done already.

3. Click the icon to add SLA definition, SLA level, and any attribute related to the SLA that you want to see.

4. Click the SLA definition filter and select your SLA.

The page reloads displaying findings with your SLA applied. You can verify the compliance status against the due date and SLA levels.

View and manage SLA definitions

Users with the Configurator or System Administrator role can view, manage, or add conditions for other data models to existing SLA definitions.

To view or modify your SLA, follow these steps:

1. Navigate to Administration > Configuration > SLA definitions. Your SLA definitions display in a list view.

2. Point your cursor over the SLA and click Details. Your definition of the SLA displays along with the records that the SLA has applied to.

3. To modify the SLA, point your cursor over the SLA and click Edit.

4. Modify the fields as needed or add conditions for other data models. These are the same fields as in creating the SLA.

5. Click Update.

Tutorial: Create an SLA for vulnerabilities detected on PCI-compliant assets

This tutorial demonstrates how you can create an SLA for vulnerabilities detected on assets that must meet Payment Card Industry (PCI) compliance standards. You may want to create such an SLA for the following reasons:

• Prioritize remediation efforts: By setting an SLA for the identified vulnerabilities, you can prioritize remediation efforts based on the level of risk associated with each vulnerability.

• Ensure timely remediation: SLAs provide a deadline for addressing vulnerabilities, which helps ensure that they are remediated in a timely manner before they can be exploited by attackers.

• Maintain compliance: SLAs can help you meet compliance requirements related to vulnerability management.

To create an SLA for vulnerabilities detected on assets required to comply with PCI requirements, follow these steps:

1. Navigate to Administration > Data > Models.

2. Locate the Vulnerability data model.

3. Click SLA.

4. Click Create and fill in the following information:

   • Name: Type "SLA for PCI-compliant assets."

   • (Optional) Description: Provide a description for the SLA, e.g.: "This SLA is for vulnerabilities detected on PCI-compliant assets."

   • Calendar policy: Select Business days.

   • Conditions: Click + to add the criteria for this SLA.

     • Target data model: Click the drop-down and select Vulnerability.

     • Measure attribute: Select Risk score as the field that the service levels are based on.

     • Start: Select First found as the attribute to be used as the starting point of the due date computation.

     • Active: Keep as is.

     • Order: Keep as is.

     • Condition: Enter targets.complianceFlags CONTAINS "PCI". This condition targets vulnerabilities detected on PCI-compliant assets.

5. Select Active. Inactive SLA's are effectively archived.

6. Click Create. The page reloads and you can now define the service levels of your new SLA.

   note

   If you receive an error with this message: There is already a condition on an 'SLADefinition' targeting a 'Vulnerability' with order '1', it's because the Vulnerability data model already exists in another SLA definition with the same order number. To resolve this error, change the order to a different number.

7. In the Service levels section, fill in the following information:

   • Name: Type "Critical".

   • From and To: Type "8" and "10.1" respectively. This specifies that vulnerabilities with risk score 8 to 10 are considered critical.

   • Due in and Time unit: Type "30" and select Day respectively. This specifies that critical vulnerabilities should be resolved within 30 days.

8. Click + to add service levels for high, medium, and low respectively, as shown in the following screenshot:

   

9. Click Update.