Schrödinger’s SOAR: Feature Or Abstraction?
“Security orchestration, automation, and response” (SOAR) is not a term that Forrester has used in the past, but its prevalence in the market is such that I’ve decided it’s better to use a slightly broken acronym that’s adopted by the market than to continue to leverage the different and more concise “security automation and orchestration” (SAO) acronym that we’ve been using. To celebrate, I’ve decided to write a blog that shines a light on one of the interesting nuances of this space.
Is It A Feature Or An Abstraction?
SOAR capabilities may be thought of as both, and it’s important to understand the strategies for both so that you acquire the right capabilities for your view of security operations. To tell this story, I like to start off by visualizing the iconic scene of Luke Skywalker looking out at the binary sunset on Tatooine and introduce the idea that there’s really two centers of gravity within a security operations center (SOC): the ticketing system and the security information and event management (SIEM) system. I argue that all data eventually makes its way into one of these (sometimes both), which is a baseline I use for determining if something is a feature or a stand-alone product. Keep in mind that many features start with someone trying to build a product to solve a problem that ends up being absorbed into the feature set of another solution.
SOAR As A Feature
There is a software design pattern called the “factory pattern” in which a single producer is responsible for creating and queueing workloads for consumers to perform. If we understand SIEM as being the central source of alerting within an SOC, we can apply this pattern to contextualize it as the producer of workloads, with the antecedent of this workload generation being an alert. In short, each SIEM alert is responsible for the creation of work in the SOC. How does this alert get turned into a workload, and how is it tracked? The answer is the SOAR responsible for taking the antecedent and constructing a workload that may even end up in the ticketing system for tracking. Because workload creation is a requirement of an efficient SOC, and the antecedent of this workload creation comes from the SIEM, it’s natural to put the two together and understand SOAR as a feature of a SIEM. Splunk’s acquisition of Phantom attests to this, as does the number of security analytics platform vendors that have embedded SOAR functionality in their SIEMs.
SOAR As An Abstraction
Because SOAR uses playbooks to enrich and bring shape to these primordial workloads that start off as little more than an alert, we also need to consider if SOAR is really the consumer in this factory pattern. In this sense, SOAR is an abstraction in that it allows you to implement SOC processes as playbooks within your SOAR that are independent of the underlying technology stack. Imagine having a hot-swappable infrastructure that allowed you to replace security technologies without interfering with or having to change the day-to-day processes of your security operations team. SOAR as an abstraction offers this outcome.
Why Should You Care?
SOAR is both a feature and an abstraction. Done right, this has the potential to be the biggest touchpoint between people and technology within your SOC . . . and you need to factor in how you envision SOC operations, whether SIEM-centric or process-centric, to acquire the right technology for your organization.