Security operations center teams have their work cut out for them. From traditional cyber attacks, such as ransomware, DDoS and phishing, to novel schemes emerging all the time, there’s never a dull moment — or downtime. Automation is one way SOC analysts can manage the variety of incident response alerts they receive.
Security orchestration, automation and response (SOAR) tools can help SOC analysts improve incident response alert handling. Microsoft Senior Product Manager Benjamin Kovacevic wrote Security Orchestration, Automation, and Response for Security Analysts to teach security practitioners how to use SOAR tools to improve an organization’s security posture.
In this interview, Kovacevic discusses why organizations should consider deploying SOAR tools and how they can improve mean time to detect (MTTD) and mean time to respond (MTTR) — two metrics for which SOCs get judged.
Since Kovacevic works with Microsoft Sentinel, most of the book uses Sentinel to teach readers how to use SOAR tools, but it does provide an introduction to Splunk and Google Chronicle SOAR as well. “The different tools may call certain tasks or workflows something different, but they all work in much the same manner,” Kovacevic said.
Editor’s note: The following interview has been edited for clarity and length.
Can organizations of any size adopt and deploy SOAR?
Benjamin Kovacevic: I think that each organization, no matter the size, can benefit from the incident response automation features. For example, enterprise organizations have an enormous level of incidents and alerts they need to investigate. They need automation to help them focus on what is worth investigating. Smaller organizations don’t have as many people as bigger organizations to investigate every alert, so they will benefit from automation as well. Automation can help small organizations and enterprises as it helps security teams perform their job more effectively and quicker.
How do SOAR tools help alleviate or reduce alert fatigue for SOCs?
Kovacevic: They provide the ability to focus on specific incidents. With SOAR automation, organizations don’t have to wait for a SOC analyst to detect an incident before performing some initial steps. Automation can start the incident workflow, such as investigating the IP address involved, instead of needing the SOC analyst to do that and potentially needing to reach out to the network department or turn to external tools themselves. By the time the SOC analyst begins investigating the alert, some type of incident enrichment has already occurred. This provides the analyst with more information immediately, reduces the steps they need to take and allows them to respond faster. Automation saves time, over and over again.
The book dives into how SOAR improves metrics, such as MTTD — MTTA, or mean time to acknowledge, in the book — and MTTR. Why are they good metrics to measure SOCs by?
Kovacevic: These are the two most important measurements for SOCs. They give the organization actual numbers they can review to see how long it took the SOC to acknowledge and respond to a true positive alert. For example, with ransomware, we need to respond fast to prevent it spreading too far into the organization’s system. We want a low MTTD to understand how soon the security team can begin remediation efforts. And MTTR provides a look into how long it took to resolve an incident and move on to the next one.
Click to learn more aboutSecurity Orchestration,
Automation, and Response
for Security Analysts.
From the time the SOC acknowledged it was a true positive, how long did it take? Was it two hours or five hours or even two days? We can analyze how serious the incident was. Maybe it took several days to tackle because it was something really serious or sophisticated. Maybe it was hard to find all the causes of the incident. If the incident took a couple hours, it could tell us that the incident isn’t as serious and perhaps common.
While MTTD and MTTR metrics are important, it’s also necessary for SOC analysts to provide a report afterward. We want to know if there’s anything to automate in the future to bring down those two metrics even more.
How does SOAR help the SOC with reducing those MTTD and MTTR metrics?
Kovacevic: SOAR helps MTTD with incident enrichment and helps MTTR because SOAR provides a space where SOC analysts can get a lot of initial information. This provides them the space to investigate the incident more quickly. In Microsoft Sentinel’s SOAR, analysts can quickly see whether there have been similar incidents before and how those previous investigation processes went. With this information, the analyst can replicate similar incident response steps and try to respond to this new event faster. Through SOAR playbooks, automation can handle some of the beginning steps too, such as blocking certain IP addresses, isolating infected machines, etc.
Does any aspect of SOAR struggle with helping SOCs manage MTTA and MTTR?
Kovacevic: This is a tricky one to answer because it’s more about how organizations feel and use automation. Some may be willing to adopt hyperautomation and automate as much as possible. Other organizations may be more hesitant, and this is where SOAR tools could struggle for them.
Some organizations are afraid to automate because they don’t want AI to perform certain tasks or don’t want to rely on AI to do those tasks. I say, why not use AI and machine learning capabilities? They will help SOC analysts perform investigations faster. I expect AI and machine learning to play a major role in SOAR for the future.
Is there ever a worry that SOCs could become too reliant on automation?
Kovacevic: Like with any tool or feature, too much use could become a problem depending how it’s done. The goal of tools like SOAR is to help analysts solve things faster. But security analysts should be aware that bad actors pay attention to how SOCs handle incident response and adapt. For example, you could create a permission that allows automation to close certain incidents, but someone could take advantage of the SOC using only automation to handle them. I’ve seen people post about this exact worry on sites like Stack Overflow and try to figure out possible solutions.
It’s important for analysts using automation to understand what it is they are automating and to understand the consequences. Additionally, it’s not a set-it-and-forget-it type of procedure. Analysts need to periodically check in on automation features and ensure they still perform the job they were designed for. Automation helps, but it needs to be done responsibly.
Does combining SIEM and SOAR help SOCs, especially in regard to MTTA and MTTR?
Kovacevic: Absolutely, yes. I think modern SOCs struggle a lot without SIEM and SOAR products. There are so many incidents and events happening on a regular basis that it’s difficult for humans to keep up. Plus, every machine and tool used creates some signal that needs to be collected and analyzed. The amount of data keeps increasing, and it’s a struggle to review everything without some sort of automation.
With automation tools in place, SOC analysts can perform better incident analysis and know where to focus the bulk of their investigation for an alert. Together, SIEM and SOAR improve how SOCs investigate an event and how quickly they respond to it. I don’t see that one can work without the other, and it’s something we’re seeing the industry acknowledge. SIEM vendors are looking for ways to combine SOAR with their products. Microsoft does this with Sentinel. Another veteran SIEM vendor, Splunk, acquired Phantom in 2018 and integrated the SOAR vendor into its offering. Google did the same for its Chronicle offering when it acquired Siemplify in 2022. All the players are searching to integrate SOAR into their current tools.
