Service Level Agreements (SLA): Overview

Summary: A high-level overview of the Service Level Agreements (SLA) feature and how it can assist users in remediation and setting due dates.

A Service Level Agreement (SLA) represents an agreement between entities about how much time can elapse before a specific action is done. In the realm of vulnerability management, this usually means the amount of time that an individual vulnerability can exist within a network or application until it is required to be remediated. Often, this amount of time depends on factors like how much risk is posed by the vulnerability or how important the containing asset is to the organization.

The RiskSense platform allows users to set Due Dates on vulnerabilities that represent when they must be closed, either by standard remediation, marking as a false positive, or risk accepting it. Setting due dates can often become tedious since these dates must be set on a per-vulnerability level. Many organizations have a standardized set of requirements that dictate Service Level Agreements with their partners or vendors, such as “All critical-risk vulnerabilities must be remediated within 14 days”. These are applicable across the entire network. The Automation suite’s Playbooks feature can assist with this process but still requires the creation of many rules, limiting an organization’s ability to automate in other areas.

The Service Level Agreements (SLA) feature in the RiskSense platform solves these problems. The SLA feature is a special type of automation that allows an organization to have the system assign due dates to mass collections of Findings according to a set of specified criteria, including the finding’s Severity or Vulnerability Risk Rating (VRR), the asset’s criticality, and the date of finding discovery.

An SLA is actually a special type of Automation, housed in its own dedicated section of the RiskSense platform. When an SLA for an organization is created, the system will automatically assign due dates to all findings that satisfy the criteria provided in the SLA. These due date assignment criteria include:

Users will create a Risk Tolerance matrix that specifies the number of days a finding may persist in the platform. That number of days depends on the VRR/Severity Group of the finding, as well as the Business Criticality of the asset on which the finding is detected. For example, a user may specify that findings with High VRR on Criticality 3 assets must be remediated 30 days after ingestion; this will result in the SLA system assigning a due date to any finding meeting that description that is exactly 30 days out from its ingestion/discovery time.

The ability to view SLA information is available to users with the Core Read IAM privilege (included with all system and custom roles). The ability to modify SLAs is housed in the following IAM privileges:

SLA Control is available to users with the Automation SLA Owner supplemental role while Finding SLA Control is available to the SLA Owner supplemental role. The Core Read privilege is included in both of these roles.

To view a step-by-step explanation of how to set up Service Level Agreement due date automation, visit the SLA Detailed Walkthrough guide.