Large enterprises often outsource some of their security needs to Managed Security Service Providers (MSSPs). When alert volumes are high, this is a simple way to onboard trained security professionals and stay on top of a daily queue of incidents. However, when working with third parties, security managers need to have management systems in place to ensure the dollars they’re spending are going towards the services they expect. One of these services that MSSPs are often expected to deliver is the timely response and closure of open incidents.
How each enterprise calculates these metrics varies, but one way we’ve seen clients accomplish this is to start and stop a timer each time the incident status is changed. In D3 Smart SOAR, an incident can be in one of four states at any given time:
- Open
- In Progress
- On Hold, or
- Closed
Two important metrics are:
- Time to Respond
- Time to Contain
Time to respond is key because it shows the enterprise SOC manager how efficiently their MSSP partner is assigning tickets and taking action on any suspicious alerts. Ultimately, the faster a potential breach can be isolated, the less economic impact their business faces, and this is one of the main metrics to which they will be held accountable. Time to respond can be tracked in D3 Smart SOAR as the time between when a ticket is “Open” and the status is changed to “In Progress”. This indicates that there are eyes on the incident and the investigation has begun.
Time to contain is calculated as the time between when an incident is first changed to “In Progress” and when it is “Closed”. This can be accomplished using incident playbook triggers inside of Smart SOAR.
Incident Playbook Triggers
A unique aspect of Smart SOAR incident playbooks is the trigger feature. This is a list of five cases where a new workflow begins based on an action taken on an incident. The five triggers are:
- On Incident Close
- On Incident Reopen
- On Incident Change
- On Incident Status Change, and
- On Incident External Action
There are many use cases for each trigger, but in this article we will show how to use On Incident Status Change and On Incident Close in order to start and stop an SLA timer to track Time to Respond and Time to Close.
Time to Respond
When an incident is first created in Smart SOAR, the default status will be ‘Open’. To calculate time to respond, we monitor the incident status and stop the timer when the status changes to ‘In Progress’ and the previous status was ‘Open’. Sometimes the status will change from ‘On Hold’ to ‘In Progress’ and we don’t want this scenario to trigger our workflow.
The first two tasks after the trigger are self-explanatory. They check if the current status is ‘In Progress’ and if so, then check if the previous status was ‘Open’. The teal task takes the time the incident was reported (ReportingDate) and subtracts it from the current time. Here is the code that prints the difference:
{% set response_time == date("utcnow") %}
{% set start_time == PlaybookData | jsonpath('$.DataSource.incident.ReportingDate') %}
{% set time_to_respond == response_time - start_time %}
{{response_time}}
{{time_to_respond}}
These two values are then pushed to the incident form with the final task, so they can be reviewed at-a-glance, included in KPI reports, and used in the next workflow.
Time to Contain
When an incident has been assigned to someone and they are actively working on it, all time they spend working on it is considered as time taken to contain the incident. In Smart SOAR, we use the previous value {{response_time}}, as well as the On Incident Close trigger, to calculate this metric. The following workflow outlines this process.
This workflow is simple; it gets the response time calculated from the previous workflow and uses similar code to calculate the time to contain. See it below:
{% set response_time == PlaybookData | jsonpath('$.["Get Response Time"].returnData') %}
{% set contain_time == date("utcnow") %}
{% set time_to_contain == contain_time - response_time %}
{{contain_time}}
{{time_to_contain}}
Then, the result is pushed to the incident form for review and reporting.
Metrics
Once all the calculations are complete, users and managers can see these values at-a-glance in the incident overview. Here we’re showing a screenshot of summary KPIs on a closed incident. It took the team 23 minutes and 29 seconds to respond to the incident, then 18 minutes and 58 seconds to contain it. It was also tagged as a false positive and closed at 8:37.21 on July 4th, 2023.
With this information, managers can easily keep track of the time their partners are taking to address crucial incidents. This is helpful for understanding risk and also ensuring your partners are following the SLAs you set out for them in the contract.
Takeaway
Enterprise security teams are finding new ways to use SOAR every day. The example in this article extends beyond standard incident remediation and helps address challenges with KPI tracking and partner management. With built-in reporting and analytics, a SOAR tool capable of executing the workflows above can be a helpful, centralized platform for all incident response activities.
