Service Level Agreement (SLA) Detailed Walkthrough

Summary: An in-depth guide to the Service Level Agreements (SLA) feature, including a walkthrough of creating an SLA from scratch, and how to modify settings on existing SLAs.

For an introduction to Service Level Agreements (SLA) and their use in the RiskSense Platform, visit our Overview article. This guide presents a detailed walkthrough of SLA structure and components and how to create your first SLA automation.

Anatomy of an SLA

This section will introduce the structure of Service Level Agreements (SLAs), and you will be shown how all of the various components are displayed and categorized.

The SLA system utilizes the architecture of Playbooks in the RiskSense platform. At the topmost level, you will first create a Remediation SLA, similar in nature to a Playbook, which will contain all of your individual SLAs that govern specific groups and your networks as a whole. This single Remediation SLA will govern all of the specified rules that you create for assigning due dates in your organization and will be the only item that appears in this view once created.

This Remediation SLA contains the following properties visible on the main list view:

SLA Name: Listed as “Remediation SLA,” set by the system.
Frequency: How often the system will run the actions to assign due dates.
Number of SLAs: The total count of rulesets configured for assigning due dates.
Status: Whether or not the SLA will run on a schedule (Enabled) or not (Disabled).
Last Updated On: The timestamp on which the most recent changes to the SLA were made.
Last Updated By: The user who made the most recent change to the SLA.
Last Run: The most recent timestamp on which the actions in the SLA were executed.

Clicking on the name of the Remediation SLA will bring you to the Group-Specific SLA View, displaying a card view that summarizes each of the individual Group-Specific SLAs, as well as the Default SLA.

The Default SLA and each Group-Specific SLA contains the following properties visible on the main list view:

SLA Name: The user-designated name of the SLA.
Groups Included: The groups targeted by this particular SLA for finding due date assignments.
Assets Under SLA: The number of distinct assets within the targeted groups.
Open Findings Under SLA: The total count of currently open findings targeted by the SLA.
Last Run On: The most recent timestamp that the SLA was executed.
Tolerance: The range of days out from ingestion or discovery that the SLA will use for assigning due dates.

Clicking anywhere inside the card for a specific SLA will invoke this view’s detail pane, showing information about the SLA’s creation, impact on your network, last run summary, group associations, and current performance.

Creating an SLA

This section will walk through creating a new Service Level Agreement (SLA) from start to finish. To begin, first, navigate to Automate > Service Level Agreements (SLAs).

If your organization has an existing Remediation SLA, it will be shown here. If this is your first time setting up an SLA, you will be presented with a prompt to create a new Remediation SLA.

You will then be taken to the Create Remediation SLA wizard and can begin configuring your SLA.

Default vs. Group-Specific Remediation SLA

First, you’ll choose whether you would like your SLA to govern the entire organization as a Default SLA or whether you would like to have it only govern a sub-set of findings within a specific Group or set of Groups as a Group-Specific SLA. When the SLA system executes the assignment of due dates, all Group-Specific SLAs are run first in the order they appear in the list view, and the Default SLA (shown at the top of the list view) will run last. Therefore, all assets in groups not already covered by a Group-Specific SLA will be assigned due dates based on the Default SLA. Note that you are not required to have a Default to create Group-Specific SLAs.

If you choose the Default SLA option, the name and group inclusion will be provided for you. If Group-Specific SLA is chosen instead, you’ll enter in the name and description of the SLA, as well as the Group(s) you would like it to govern. If a Group has already been previously assigned to another Group-Specific SLA, it will not be available here, as a Group may only have one SLA governing it at a time.

Choosing a Time Reference

Due dates for findings are assigned based on the Time Reference configuration for that SLA. Users may set this configuration in the Pick Time Reference step of setup. If the First Discovered On option is chosen, the platform will use the discovery date of the finding according to the scanner information as the starting date. If First Ingested On is selected, the platform will use the upload date of ingestion and assessment as the starting date. If the scanner does not provide a discovery date, then the ingestion date is used instead by default.

If First Assigned On is selected, the platform assigns due dates to findings based on the earliest instance of user assignment. Until a finding has been assigned to a user, the platform will not set a due date for it. The platform always bases a due date on the first instance of user assignment even if that user has subsequently been unassigned from the finding.

(Note that the platform started to track the date of user assignment after September 17, 2021. If you want to set the due date for a finding assigned to a user prior to this date, you must unassign these findings and then reassign them to the user.)

Selecting a Score Metric

The due date assigned to a finding by the SLA system depends on the risk posed by the individual finding. The amount of risk can be measured using RiskSense’s proprietary Vulnerability Risk Rating (VRR), which takes threat intelligence and other factors into consideration when assigning a numerical risk score (recommended). Alternatively, the industry-standard CVSS scores and Scanner Severity may be used instead as risk quantification by selecting the Severity option. Both are measured on a numerical scale from 0.0 (no risk) to 10.0 (highest risk).

Configuring Risk Tolerance

The Risk Tolerance Matrix is the heart of the SLA system, and it represents exactly how much time your organization has to remediate a finding based on that finding’s risk score, as well as the criticality of the asset containing it. The matrix is displayed as a 5-by-5 grid, with columns representing the five levels of risk (critical, high, medium, low, and informational) and rows representing the criticality of the associated asset from 1 (least critical) to 5 (most critical). Each cell within the matrix shows the number of days that your organization has to remediate a finding with the corresponding risk and asset criticality before it is due.

For example, the organization would have 7 days to remediate a critical finding on a level 5 asset in the screenshot shown below. In other words, the due date for such a finding will be set as 7 days out from the date of ingestion/discovery.

The platform offers three options for a remediation strategy to utilize in your SLA: Standard, Accelerated, and Aggressive. The Standard option presents typical industry-standard remediation times recommended for each risk level, excluding Informationals. The Accelerated option shortens these time windows for a faster remediation strategy, and the Aggressive option shortens them even more drastically for a highly motivated remediation plan. Additionally, users may choose the Custom option instead and enter their preferred number of days in each cell individually, up to 365 days out from discovery/ingestion time.

Update Preferences

In the final two steps of SLA configuration, you’ll select the update and apply preferences of due dates.

Over time, known threat information, CVSS categorization, and other parameters related to findings may change, thus affecting the finding’s VRR and/or Severity. If you would like the due date of findings to update accordingly with these changes, check the box labeled Update the SLA if VRR/Severity changes. If you prefer to leave your due dates fixed, leave them unchecked.

A newly created SLA may be applied to all findings currently existing in your networks or selected group(s) as well as newly identified findings or to newly identified findings only. This option is presented as the Apply To configuration by choosing to have this SLA govern all existing and future findings or only new future findings.

Once all of your configuration preferences have been set, click the Save button to create your new SLA.

If this is your first time configuring any SLAs, the top-level Remediation SLA will automatically be created, and you’ll be redirected to the new Default or Group-Specific SLA configured in the above steps. Otherwise, your newly configured SLA will appear alongside existing ones in the Group-Specific SLA view.

SLA Detailed Information

Clicking anywhere inside the card for a specific SLA will invoke this view’s detail pane. This section provides additional information about each area of the detail pane.

Configuration

At the top of the SLA detail pane, the individual SLA’s configuration options are displayed, including the creation and update info and which options have been chosen for measuring risk tolerance and due date application.

The following fields are displayed in this area of the detail pane:

SLA Name: Name of SLA rule.
Description: User-provided description of SLA rule.
Created on: Date the SLA was created.
Created by: User that created the SLA.
Last Updated on: Date and time SLA was last updated.
Last Updated by: User that last updated the SLA.
Risk Tolerance: Click Show Matrix to view the risk matrix associated with this SLA.
Time Reference: Displays the time reference used for setting the SLA.
Score Metric: Displays score metrics used by the SLA and if updates are applied when scores change.
Applies to: If the SLA rule applies to either Existing Findings or New Future Findings.

Impact

The SLA Impact section displays counts of findings and assets that are affected by that specific SLA. Finding counts are broken down according to threat category and the source that applied existing due dates. Counts are further broken down by asset type: Host and Applications.

The following fields are displayed in this area of the detail pane:

Assets under SLA: Number of hosts and applications under this SLA.
Open Findings under SLA: Number of currently open host and application findings under this SLA.
Total CVEs: Number of unique CVEs associated with open host and application findings under this SLA.
Ransomware: Number of host and application ransomware vulnerabilities under this SLA.
RCE/PE: Number of host and application remote code execution (RCE)/privilege escalation (PE) vulnerabilities under this SLA.
Trending: Number of host and application trending vulnerabilities under SLA.
Open Findings with Due Dates: Number of open findings with due dates by how these due dates were set.
- Set Manually: Number of host and application findings with due dates set manually by a user.
- Set by Playbooks: Number of host and application findings with due dates assigned via playbook automation.
- Set by SLA: Number of host and application findings with due dates set by the SLA automation system.
Findings NOT under SLA - Number of host and application findings that do not have any due date assigned.

Last Run Summary

The Last Run Summary provides information on the most recent execution of the SLA, including how many assets and findings are included in the target groups and how many had any changes applied that affected due dates. Counts are further broken down by asset type: Hosts and Applications.

The following fields are displayed in this area of the detail pane:

Date: Last date the SLA ran and if it ran successfully.
Assets Targeted: Number of hosts and applications targeted by the SLA.
Assets Updated: Number of hosts and applications targeted by the SLA.
Findings Targeted: Number of host and application findings targeted by the SLA.
Findings Updated: Number of host and application findings updated by the SLA.

Performance

The SLA Performance section of the detail pane displays how well the SLA is currently being adhered to by your organization in terms of on-time remediation efforts.

At the top, the Total Findings within assets governed by this SLA are displayed. This count is then broken down according to whether the findings are Closed; whether they are Within SLA (i.e., the finding is open and its due date is in the future); or whether they are Overdue (i.e., the finding is open and its due date is in the past).

Below this, two performance indicators are provided.

The SLA’s 30-Day Performance metric is a measure of the percent of findings closed in the last 30 days which met their SLA. In other words, this metric answers the question: “Out of all findings remediated in the past 30 days, how many of them were closed on time?” Higher percentage values indicate more findings meeting their SLA and thus better performance.
The Overdue Performance metric measures the progress of closing overdue findings and represents the ratio of findings not Overdue (i.e., Within SLA) to the total count of open findings. In other words, this metric answers the question: “Out of all findings currently open, how many of them are not overdue?” Higher percentage values indicate fewer overdue findings and thus better performance.

Viewing SLA Information in List Views

In addition to the SLA view, the above-detailed information is also visible within the findings, assets, and groups list views, within their respective detail panes.

Groups View

In the detail pane for the Groups view, performance indicators have been added to the top section, just below the group’s name. These performance indicators match those displayed in the SLA detail pane: 30-Day Performance measures how many of the findings closed in the last 30 days met their SLA; Overdue Performance measures the number of findings overdue among all open findings.

Descriptions of the associated SLA are shown in a new SLA Information section. The governing SLA is linked at the top, with an option to filter the current list view on that specific SLA if desired. A filter icon will appear on mouseover of the SLA name to provide this option. Configuration options for the SLA, including the risk tolerance matrix, time reference, and score metric data, are shown.

Below this, counts of findings with due dates are displayed according to their SLA status: Closed, Within SLA, or Overdue. The number of findings without due dates (i.e., Not under SLA) is also shown. At the bottom of this section, other groups governed by the current SLA are also displayed for reference.

Asset Views

Information on the associated SLA is shown in the detail pane for both the Host and Application views. The governing SLA is linked at the top, with an option to filter the current list view on that specific SLA if desired. A filter icon will appear on mouseover of the SLA name to provide this option. The risk tolerance range for all Finding risk categories of an asset with the current criticality is displayed, and time reference and score metric data are applied from the SLA.

Below this is shown information on which type of SLA (Default or Group-Specific) enforced the due date and Group membership for the asset associated with the governing SLA. At the bottom of this section, counts of Findings with due dates are displayed according to their SLA status: Closed, Within SLA, or Overdue. The number of Findings without due dates (i.e., Not under SLA) is also shown.

Finding Views

Information on the associated SLA is shown in the detail pane for both the Host Finding and Application Finding views. The governing SLA is linked at the top, with an option to filter the current list view on that specific SLA if desired. A filter icon will appear on mouseover of the SLA name to provide this option. The corresponding risk tolerance range is displayed for the finding and time reference and score metric data applied from the SLA. At the bottom of this section, information on which type of SLA (Default or Group-Specific) enforced the due date and the group(s) that the finding is found in associated with this SLA.

Additionally, a new set of SLA filters has been provided on the Findings views. These include:

SLA Name: The name of the SLA that enforced a due date onto the finding(s).
SLA Set By: The source of the due date assigned to the finding: either manually (“USER”), by an automation playbook (“PLAYBOOK”), or by the SLA automation system (“SLA”).
SLA Due Date Updated: A date filter is used to identify when the due date of a finding was modified.
SLA Status: The current state of a finding relative to when its due date is set: Met SLA (closed before it was due), Missed SLA (closed after it was due), Within SLA (open with a future due date), or Overdue (open with a past due date).

Managing SLA Settings

In this section, we’ll discuss how to modify the settings and structure of your SLAs.

Enabling or Disabling your SLA

To modify SLA settings, the SLA must first be in the Disabled state. By default, a newly created SLA will always be disabled. This means that its configurations have been set, but it will not yet execute any actions. To have the automation begin running according to the designated schedule, we’ll need to Enable the SLA.

To enable an SLA, click on the three-dot options menu on the right edge of the SLA card, and select Enable.

To disable an SLA, click on the three-dot options menu on the right edge of the SLA card, and select Disable.

SLA Status

The Status of an SLA shows one of four states: Enabled, Disabled, Running, or Deferred. As discussed above, an Enabled SLA is configured to run at its scheduled time, and a Disabled SLA will not run and can be configured.

An SLA in the Running state is currently executing its operations, and its state and properties cannot be modified until the run is complete.

A Deferred SLA is queued for operations and will begin executing as soon as its turn in the queue arrives. SLAs in this state can also not be modified.

Group-Specific SLA Priority Order

As discussed above, the Group-Specific SLAs will execute in the exact order seen in the Remediation SLAs list view sequentially; however, the Default SLA will always execute last. If you wish to modify the group-specific SLA priority order, first ensure that the SLA is Disabled. Once disabled, click on the Change Order option in the top-right corner of the Remediation SLAs view.

The Change SLA Order wizard will then be presented. In this window, Group-Specific SLAs may be rearranged by dragging and dropping them within the list. Arrow buttons to the right of each card can also be used to change the order. Once your rules are in the desired order, click the Save button to apply the configuration to your SLA.

Deleting an SLA

To delete an SLA rule from a disabled SLA, click on the three-dot options menu to the right of that SLA’s card in the Remediation SLAs view and select Delete.

A confirmation dialogue will appear; click Submit to delete the rule from the SLA successfully.

To delete a disabled SLA, click on the three-dot options menu on that SLA’s card in the SLA Playbooks view and select Delete.

A confirmation dialogue will appear; click Submit to delete the SLA successfully.