Security Orchestration, Automation and Response (SOAR) solutions came on the market around six years ago. The two main objectives of these tools were to orchestrate 3^rd party tools for filtering false positive alerts out of the network, and to automatically block attacks. SOAR came on the scene with bold statements to fill in some of the gaps that existed in Security Information and Event Management (SIEM) platforms, which have been making security analysts miserable for twenty years now.

How SIEM is swallowing up SOAR

As SIEM technologies have advanced in the past few years, SOAR is becoming less and less relevant. Gartner, which originally coined the term SOAR, published an unflinching report this month “Market Guide for Security Orchestration, Automation and Response Solutions”, basically warning of the impending demise of SOAR as an independent category.

SIEM companies are either developing their own SOAR capabilities or, more often, buying their way in by acquiring SOAR solutions (a long list of such acquisitions is included in the report). Gartner even recommends that companies who buy a SOAR solution from an independent vendor create “a contingency plan for vendor acquisition of their SOAR tools” basically hinting that soon there will no longer be any independent SOAR vendors in the market.

What SOAR is for

SOAR has two stated goals: Automating triage and automating response. Response remains elusive, though advances are being made by both SOAR and SIEM developers.  However, the main use case for companies seeking out SOAR is still automating triage and filtering out the high volumes of false alerts. In their report, Gartner states that the most common use case cited by Gartner clients who have or are planning to implement a SOAR is “automating the triage of suspected phishing emails reported by end users.” The report goes on to explain that this is a “classic example of a process that follows a repeatable process, dozens to hundreds of times per day, with the goal of determining whether the email (or its content) is malicious and requires a response. It is a process ripe for the application of automation.”

If we’re really being honest with ourselves, SOAR hasn’t truly delivered on the promise of automated response and, as a result, most of us are using it mainly to automate triage.

The SOAR inequality

SOARs are primarily used by larger organizations with sizeable SOC teams. According to Gartner, SOAR technologies offer a utility-like functionality that needs to be programmed by the operators and integrated with 3^rd party systems. “Thus, they are not ready, and may be too complicated to be consumed by less mature organizations looking to take advantage of automation.”

And here we come to the paradox – small and medium-sized organizations with a security team of one to a handful of analysts, who need triage automation the most because they don’t have the capacity to deal with a deluge of alerts, are the ones not using SOAR tools, because they require complex API integrations and code programming, a challenge in smaller teams.

This elitist reality, in which SOAR automation is in the grasp of only large organizations with big budgets and big SOC teams, needs to be challenged.