I first came up with the SOAPA concept in late 2016. Here’s the blog I wrote in November of that year describing the architecture and its rationale.
As a review, SOAPA is a bottom-up architecture featuring a:
- 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 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 it in.
- 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 like 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 like 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.
So, 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 does SOAR compare with SOAPA? 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” itself 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.
