SOAPA vs. SOAR: How these security terms differ

I came up with the security operations and analytics platform architecture (SOAPA) concept in late 2016. In November of that year, I wrote about how SIEM systems were becoming part of SOAPA.

As a review, SOAPA is a bottom-up architecture featuring:

• Common distributed data service. SOAPA creates a common data pipeline for high volumes of batch and streaming data. In this way, SOAPA can accommodate massive amounts of security data for all types of analytics – from real-time threat detection to long-term retrospective investigations spanning months’ or even years’ worth of security data. 
• Software services and integration layer. This layer serves as a bridge between security data and analytics engines that consume the data. In simple terms, the software services and integration layer delivers security data to analytics engines when they want it and in the format they want.
• Analytics layer. Security data is scrutinized by a variety of security tools that monitor endpoint processes, network behavior, threat intelligence patterns, or all these areas at once. The SOAPA analytics layer is designed for efficient monitoring and analysis of all security data to help SOC teams accelerate threat detection, pinpoint problems, and prioritize actions.
• Security operations platform layer. When security analytics discover a problem, it can then hand off remediation tasks to the security operations platform layer. The top layer of the SOAPA stack is programmable and can be instrumented to take automated actions, such as gathering data for an investigation, blocking a network connection, or opening a trouble ticket in a case management system. Security remediation operations can also be orchestrated to take actions across multiple security controls, such as firewalls, network proxies, web or DNS gateways, etc. Finally, the security operations layer acts as a workbench for SOC analysts for complex operations that require manual intervention. 

SOAPA represents the whole security operations enchilada, as it collects, processes, analyzes, and acts upon security data. Thus, SOAPA provides a common architectural glue that today’s army of disparate security point tools can plug into. SOAPA acts a force multiplier, enabling technology collaboration for threat prevention, detection, and response.

What is SOAR?

SOAR stands for security orchestration, automation, and response. Vendors in this space include D3, DFLabs, Demisto (now part of Palo Alto Networks), Invotas (now part of FireEye), Komand (now part of Rapid7), Phantom (now part of Splunk), Resilient (now part of IBM), ServiceNow, Siemplify, and Swimlane. As the term states, SOAR tools are designed to help organizations automate security operations processes – many of which are completely or partially manual today.

How SOAPA is different from SOAR

SOAR is a product category, while SOAPA is an architecture made up of many product categories. SOAPA is designed to facilitate efficient and effective data collection, processing, sharing, and analysis. When security analytics tools (and analysts themselves) reach an “aha moment,” SOAR tools (aka the security operations platform layer within SOAPA) can take over as a security operations workbench to enable further investigations, delegate tasks, automate remediation actions, orchestrate amongst diverse security controls, etc.

Simply stated, SOAR is a layer within the SOAPA architecture.

While I’m on this topic, I have one last thought. There is a consensus among the infosec pros I speak with that the term “SOAR” is a misnomer. Why? As security guru Bruce Schneier would say, “Security is a process, not a product.” Similarly, the SOAR term focuses on the technology directions of security operations processes rather than the processes themselves. To me, that’s like characterizing home construction operations through a lens of hammers and nails – it just doesn’t capture the big picture.