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.

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:

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:

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.

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.

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.

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

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

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.

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.

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.

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:

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:

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:

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.

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.

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.

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.

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:

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

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.

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.

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.

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.