Tracking SLAs for security incidents using QRadar SOAR

Security, orchestration, automation, and response, or SOAR, is a software solution that enables security teams to integrate and coordinate separate security tools, automate repetitive tasks, and streamline incident and threat response workflows.

When discussing the IBM Security QRadar SOAR platform and the work of security analysts on cases or incidents, several specific metrics and concepts are particularly relevant. These metrics are essential for evaluating the performance and efficiency of security operations within an organization, especially in the context of handling cybersecurity threats and incidents.

Some of the key metrics and concepts include:

• Mean Time to Identify (MTTI): The average time it takes to identify a security incident. In the context of IBM SOAR, this would be how quickly the system and analysts can detect a potential security breach or threat.
• Mean Time to Respond (MTTR): In cybersecurity, this often refers to the average time it takes to respond to a security incident once it has been identified. This includes the time taken by automated systems like QRadar SOAR and the time taken by analysts to take action.
• Mean Time to Contain (MTTC): The average time it takes to contain an incident once it has been identified. This is crucial in cybersecurity to prevent further damage or data loss.
• Mean Time to Resolve (MTTR, again): The average time it takes to fully resolve and close an incident. This includes not only addressing the immediate threat but also implementing solutions to prevent similar incidents in the future.
• Incident Volume: The number of incidents identified over a given period. This metric helps in understanding the workload and the types of threats faced.
• False Positive Rate: The rate at which the system incorrectly identifies normal activity as a security threat. High rates can waste analyst time and resources.
• Incident Severity Classification: The categorization of incidents based on their severity, which helps in prioritizing the response efforts.
• Automation Rate: The percentage of incident response processes that are automated through SOAR. This metric is key to understanding the efficiency gains from using such a platform.
• Threat Intelligence Integration: The effectiveness of integrating external threat intelligence into the SOAR platform to enhance incident detection and response capabilities.
• Compliance Reporting: The ability to generate reports that demonstrate compliance with various regulatory requirements. This is crucial for organizations subject to regulations like GDPR, HIPAA, and others.
• Case Management Efficiency: How effectively the SOAR platform and the analysts manage and track incident response activities, including documentation, evidence collection, and workflow management.
• Post-Incident Analysis and Reporting: The thoroughness and effectiveness of post-incident analysis and reporting, which is crucial for understanding and learning from security incidents to improve future responses.

In the context of QRadar SOAR and security analysts, these metrics are not only indicators of current performance but also guideposts for continual improvement in handling cybersecurity threats and incidents.

Many of the metrics mentioned, such as MTTI, MTTR, MTTC, and others, are related to service level agreement (SLA) tracking, especially in the context of cybersecurity and IT services.

Incident management

In this article, we delve into the detailed timeline and key metrics associated with security incident response. The data presented here offers a comprehensive overview of the typical stages in incident management, from the initial detection of an offense to the final closure of the case. This information is crucial for understanding the efficiency and effectiveness of response protocols in cybersecurity operations.

Important: The tables presented below are intended for reference purposes only. They provide an in-depth view of the processes involved in cybersecurity incident management, encompassing everything from the initial detection of an offense to its eventual resolution.

Offense and case timeline

The following table outlines the sequence of events in the management of a cybersecurity incident. This timeline provides insight into the rapid actions taken from the moment an offense is detected to the eventual resolution of the case.

Key metrics formulas

The following table presents formulas for calculating key performance metrics in incident management. These metrics are vital for evaluating the responsiveness and timeliness of the incident response.

SLA metrics with severity

SLA metrics are critical benchmarks in cybersecurity operations. The table below shows the SLA severity categories and the corresponding time windows for various stages of incident response.

SLA use case and implementation details

Following is a use case and details that show how an SLA is applied, including scripts, variables, and outputs.

SLA use case

1. When an offense is escalated from QRadar SIEM, a case is created on QRadar SOAR. As soon as an analyst is assigned as owner and picks up the case, the SLA pick-up time should be recorded on the case.

2. When an L2 analyst completes the task, "Review the alert triage data and provide investigation verdict," the time to investigate is recorded on the case.

3. When an analyst completes the "Respond" phase, the remediation time is recorded.

4. When an analyst closes the case, the total time to close is recorded.

Scripts and custom variables

Following are the scripts and custom variables used in the solution:

Timestamp scripts

• SLA-1-Case_pickuptimestamp: Captures case_pickuptimestamp
• SLA-2-Investigation-timestamp: Captures case_investigated_timestamp.
• SLA-3-Remediation-timestamp: Calculates case_remediated_timestamp.

SLA calculation scripts

• SLA-4-case_pick_up_sla: Calculates case_pick_up_sla.
• SLA-5-CASE-Investigation-SLA: Calculates case_investigation_sla.
• SLA-6-case-Remediation-SLA: Calculates case_remediation_sla.
• SLA-7-Case-Closed: Calculates total time taken for closure.

Important: All scripts adjust the SLA calculations according to severity value set by the user.

Script: SLA-1-Case_pickuptimestamp Captures case_pickuptimestamp [custom variable].

from datetime import datetime
incident.properties.case_pickuptimestamp = datetime.now()

Script: SLA-2-case_investigated_timestamp Captures case_investigated_timestamp [custom variable].

from datetime import datetime
incident.properties.case_investigated_timestamp = datetime.now()

Script: SLA-3-Remediation-Timestamp Captures case_remediated_timestamp [custom variable].

from datetime import datetime
if incident.phase_id == 'Post-Incident':
    incident.properties.case_remediated_timestamp = datetime.now()
    incident.addMilestone('Respond Phase Completed', 'Phase was changed to ' + incident.phase_id, incident.properties.case_remediated_timestamp)

Script: SLA-4-case_pick_up_sla Captures case_pick_up_sla [custom variable].

import time
from datetime import datetime

# Assuming stime and etime are Unix epoch timestamps
stime = incident.create_date  # Incident created timestamp
etime = incident.properties.case_pickuptimestamp  # Incident resolved timestamp

# Function to check and convert timestamps from milliseconds to seconds if needed
def convert_timestamp(timestamp):
    # Check if the timestamp is in milliseconds (length of digits is greater than 10)
    if len(str(timestamp)) > 10:
        # Convert from milliseconds to seconds
        timestamp = timestamp / 1000.0
    return timestamp

# Check if stime and etime are valid integers or floats (to handle milliseconds)
if isinstance(stime, (int, float)) and isinstance(etime, (int, float)):
    stime = convert_timestamp(stime)
    etime = convert_timestamp(etime)

    # Convert Unix epoch timestamps to datetime objects
    stime = datetime.utcfromtimestamp(stime)
    etime = datetime.utcfromtimestamp(etime)

    # Calculate the time difference
    time_difference = abs(etime - stime)
    time_difference_seconds = time_difference.total_seconds()

    # Convert seconds to days, hours, minutes, and remaining seconds
    days, remainder = divmod(time_difference_seconds, 86400)
    hours, remainder = divmod(remainder, 3600)
    minutes, seconds = divmod(remainder, 60)

    # Format the total duration
    total = f"{int(days)}d {int(hours)}h {int(minutes)}m {int(seconds)}s" if time_difference_seconds != 0 else "0s"

    # Calculate SLA based on severity
    severity = incident.severity_code
    SLA = {"Low": 24, "Medium": 4, "High": 1}
    sla_hours = SLA.get(severity, "Unknown")

    # Assign the formatted string to the desired property
    incident.properties.case_pick_up_sla = f"{total} (SLA {sla_hours}h)"
else:
    # Handle invalid timestamp formats
    incident.properties.case_pick_up_sla = "Invalid timestamp format, unable to calculate SLA"

Script: SLA-5-CASE-Investigation-SLA Captures case_investigation_sla [custom variable].

import time
from datetime import datetime

# Assuming stime and etime are Unix epoch timestamps
stime = incident.create_date  # Incident created timestamp
etime = incident.properties.case_investigated_timestamp  # Incident resolved timestamp

# Function to check and convert timestamps from milliseconds to seconds if needed
def convert_timestamp(timestamp):
    # Check if the timestamp is in milliseconds (length of digits is greater than 10)
    if len(str(timestamp)) > 10:
        # Convert from milliseconds to seconds
        timestamp = timestamp / 1000.0
    return timestamp

# Check if stime and etime are valid integers or floats (to handle milliseconds)
if isinstance(stime, (int, float)) and isinstance(etime, (int, float)):
    stime = convert_timestamp(stime)
    etime = convert_timestamp(etime)

    # Convert Unix epoch timestamps to datetime objects
    stime = datetime.utcfromtimestamp(stime)
    etime = datetime.utcfromtimestamp(etime)

    # Calculate the time difference
    time_difference = abs(etime - stime)
    time_difference_seconds = time_difference.total_seconds()

    # Convert seconds to days, hours, minutes, and remaining seconds
    days, remainder = divmod(time_difference_seconds, 86400)
    hours, remainder = divmod(remainder, 3600)
    minutes, seconds = divmod(remainder, 60)

    # Format the total duration
    total = f"{int(days)}d {int(hours)}h {int(minutes)}m {int(seconds)}s" if time_difference_seconds != 0 else "0s"

    # Calculate SLA based on severity
    severity = incident.severity_code
    SLA = {"Low": 24, "Medium": 4, "High": 1}
    sla_hours = SLA.get(severity, "Unknown")

    # Assign the formatted string to the desired property
    incident.properties.case_investigation_sla = f"{total} (SLA {sla_hours}h)"
else:
    # Handle invalid timestamp formats
    incident.properties.case_investigation_sla = "Invalid timestamp format, unable to calculate SLA"

Script: SLA-6-case-Remediation-SLA Captures case_remediated_timestamp [custom variable].

fimport time
from datetime import datetime

# Assuming stime and etime are Unix epoch timestamps
stime = incident.create_date  # Incident created timestamp
etime = incident.properties.case_remediated_timestamp  # Incident resolved timestamp

# Function to check and convert timestamps from milliseconds to seconds if needed
def convert_timestamp(timestamp):
    # Check if the timestamp is in milliseconds (length of digits is greater than 10)
    if len(str(timestamp)) > 10:
        # Convert from milliseconds to seconds
        timestamp = timestamp / 1000.0
    return timestamp

# Check if stime and etime are valid integers or floats (to handle milliseconds)
if isinstance(stime, (int, float)) and isinstance(etime, (int, float)):
    stime = convert_timestamp(stime)
    etime = convert_timestamp(etime)

    # Convert Unix epoch timestamps to datetime objects
    stime = datetime.utcfromtimestamp(stime)
    etime = datetime.utcfromtimestamp(etime)

    # Calculate the time difference
    time_difference = abs(etime - stime)
    time_difference_seconds = time_difference.total_seconds()

    # Convert seconds to days, hours, minutes, and remaining seconds
    days, remainder = divmod(time_difference_seconds, 86400)
    hours, remainder = divmod(remainder, 3600)
    minutes, seconds = divmod(remainder, 60)

    # Format the total duration
    total = f"{int(days)}d {int(hours)}h {int(minutes)}m {int(seconds)}s" if time_difference_seconds != 0 else "0s"

    # Calculate SLA based on severity
    severity = incident.severity_code
    SLA = {"Low": 24, "Medium": 4, "High": 1}
    sla_hours = SLA.get(severity, "Unknown")

    # Assign the formatted string to the desired property
    incident.properties.case_remediation_sla = f"{total} (SLA {sla_hours}h)"
else:
    # Handle invalid timestamp formats
    incident.properties.case_remediation_sla = "Invalid timestamp format, unable to calculate SLA"

Script: SLA-7-total_time_for_closer Captures `the time difference between [Date Closed - Date Created].

import time
from datetime import datetime

# Assuming incident.create_date and incident.end_date could be either datetime strings or Unix timestamps
date_created = incident.create_date  # Incident created timestamp
date_closed = incident.end_date  # Incident closed timestamp or use datetime.now().timestamp() if live timestamp needed

# Function to check and convert timestamps from milliseconds to seconds if needed
def convert_timestamp(timestamp):
    # If the timestamp is a string, parse it
    if isinstance(timestamp, str):
        try:
            # Try parsing assuming the string format is known, e.g., "%m/%d/%Y %H:%M:%S"
            return datetime.strptime(timestamp, "%m/%d/%Y %H:%M:%S")
        except ValueError:
            # Fallback for other possible formats
            try:
                return datetime.strptime(timestamp, "%m/%d/%Y %H:%M")
            except ValueError:
                return None  # Invalid format
    # Check if the timestamp is in milliseconds (length of digits is greater than 10)
    elif isinstance(timestamp, (int, float)) and len(str(timestamp)) > 10:
        # Convert from milliseconds to seconds
        timestamp = timestamp / 1000.0
        return datetime.utcfromtimestamp(timestamp)
    elif isinstance(timestamp, (int, float)):
        return datetime.utcfromtimestamp(timestamp)
    else:
        return None

# Convert timestamps
date_created = convert_timestamp(date_created)
date_closed = convert_timestamp(date_closed)

if date_created and date_closed:
    # Calculate the time difference
    time_difference = abs(date_closed - date_created)
    time_difference_seconds = time_difference.total_seconds()

    # Convert seconds to days, hours, minutes, and remaining seconds
    days, remainder = divmod(time_difference_seconds, 86400)
    hours, remainder = divmod(remainder, 3600)
    minutes, seconds = divmod(remainder, 60)

    # Format the total duration
    total = f"{int(days)}d {int(hours)}h {int(minutes)}m {int(seconds)}s" if time_difference_seconds != 0 else "0s"

    # Assign the formatted string to the desired property
    incident.properties.total_time_for_closure = total
else:
    # Handle invalid timestamp formats
    incident.properties.total_time_for_closure = "Invalid timestamp format, unable to calculate closure time"

Rules used in the solution

1. Rule: If an owner is assigned and Casepickuptimestamp custom field does not have a value.
   • Action: Capture the case_pickuptimestamp and then calculate case_pick_up_sla.
2. Rule: If the task name is equal to "Review the alert triage data and provide investigation verdict" and the status is changed to close.
   • Action: Capture the case_investigated_timestamp and then calculate case_investigation_sla.
3. Rule: If the Respond Phase is completed and a Milestone is created.
   • Action: Capture the case_remediated_timestamp and then calculate case_remediation_sla.
   • Milestone Example
4. Rule: If the case is closed then the Total time taken to close case will be calculated.
   • Action: Capture the `Total time to close the case``.

Rules view under Customization Settings

CASE outputs examples for different severity

1. Low Severity:
2. Medium Severity:
3. High Severity:

Summary

The implementation of QRadar SOAR for tracking SLAs for security incidents significantly enhances an organization's ability to meet and exceed service expectations. This system not only automates the response to security threats but also ensures that every incident is addressed within the stipulated timeframe, thereby upholding stringent compliance standards and maintaining operational integrity.

By integrating QRadar SOAR, organizations can achieve a higher level of security efficacy and operational efficiency, ensuring that they remain ahead in managing and mitigating security risks in a timely and effective manner.

Next steps

Now that you understand how to track SLAs using QRadar SOAR, check out the full range of IBM Security QRadar products and other resources to improve your SOC efficiency, accelerate incident response, and close your security skill gaps:

• IBM Security QRadar SOAR
• IBM Security QRadar Suite
• IBM Security QRadar Price Estimator
• Webcast: 4 Impactful steps to help scale your SOC and follow regulatory reporting requirements