1 Introduction

As the number and sophistication of cyberattacks have continued to increase over the years, some vendors realized that the traditional approaches and tools of cybersecurity likewise have failed to keep up. Twenty-five years ago, a single firewall may have been enough to protect sensitive resources within the corporate network, but this is no longer the case. Many security conscious organizations can find themselves administering over 50 different and disjointed security tools.

Just a decade ago, Security Information and Event Management (SIEM) products were hailed as the ultimate solution for managing security operations. In many organizations, they still form the foundation of modern Security Operations Centers. However, visibility of potential security events alone does not help analysts to assess each discovered threat, nor does it reduce the amount of time spent on repetitive manual tasks that constitute an incident response process.

First generation SIEMs did provide value, but many early SIEM users report that the volume of false positives caused problems in trying to sift out what was worthy of attention and follow-up and what was not. Second generation SIEMs usually incorporate Machine Learning (ML) detection models as a means to reduce false positives and provide more actionable intelligence to analysts and admins.

Parallel to these newer SIEM solutions, a class of incident response platforms has emerged focusing on creating more streamlined and automated workflows for dealing with security incidents.
Security Orchestration, Automation and Response (SOAR) products are the latest iteration of this evolution. Driven by the growing demand to implement centralized, automated control over incident analysis and response workflows across disparate security solutions, vendors are expanding their existing security intelligence, security orchestration or incident response platforms to combine the key capabilities across all three of these market segments. Complementing or directly integrating with SIEMs, SOAR platforms aim to become the foundation of contemporary Security Operations Centers (SOCs).

Modern cybersecurity architectures must include tools and services that cover everything from the network layer to the application layer and all the devices in between. Network layer security tools include firewalls, VPNs, routers/switches, Software Defined Networking (SDN) control planes, Intrusion Detection and Prevention Systems (IDS/IPS), email gateways, web gateways, Network Detection & Response (NDR) solutions, and Distributed Deception Platforms (DDPs). Associated cloud resources should have Cloud Access Security Brokers (CASBs) for both network and application layer controls, and Cloud Workload Protection Platforms (CWPPs) to secure loads in IaaS and PaaS.

Endpoints need Endpoint Protection (EPP) suites and Endpoint Detection & Response (EDR). EPP should contain a multiplicity of security functions: advanced anti-malware agents that can proactively discover and prevent malware from executing, utilizing ML-enhanced behavioral and memory analysis, exploit prevention, and other measures. EPP should also perform application control, integrate with or provide endpoint firewall protection, URL filtering, critical system file monitoring, asset inventory and patch management, and vulnerability management. EDR solutions have deeper monitoring and analysis functions that look for signs of attacks on endpoints that may have gone unnoticed by EPP. EDR should have automatic analysis and remediation capabilities. All kinds of endpoints should be considered, not just desktops and laptops, but also servers, virtual servers, containers, mobile phones, and IoT devices.

Application security starts with secure coding practices. Nevertheless, additional security mechanisms are needed and when deployed can help protect apps from attacks. Defenses at the application layer may include protocol gateways, reverse proxies, API gateways, and Web Application Firewalls (WAFs). CASB and CWPP solutions are useful for cloud hosted applications.
Databases, Big Data systems, data lakes, and data analytics tools must also be considered. Databases have built-in security constructs that must be employed to control access and protect against sabotage. SQL database security is well established but can be harmonized with enterprise security policies using SQL proxies and API security gateways. Big Data tools and related storage units require a mix of application, network, and cloud security tools for proper coverage.

Last but certainly not least is identity. We have heard for years that “Identity is the new perimeter”. This means that Identity and Access Management (IAM) systems play a critical role in the overall security architecture. Traditional security perimeters have become more porous over the years to allow higher level traffic to communicate directly with business or mission-critical applications. Digital identity is what allows for better protection of all resources along the path from “outside” to “inside”, by enforcing strong authentication and granular authorization. Thus, IAM concepts, systems, and controls must pervade all digital environments.

SOAR systems can be fed by all these kinds of security solutions, although mostly indirectly through the aforementioned SIEMs. Most SOARs can take in telemetry via APIs or in CEF and syslog format for those that also function as SIEMs. SOAR systems generally have OOTB connectors (software configurations and code in the form of packaged API calls) to facilitate data collection from upstream sources. In some cases, analysts need access to full packet captures, so NetFlow and PCAP are supported by a few vendors. In those cases, vendors have appliances that can connect on SPAN/TAP ports on network devices to achieve full packet capture.

The orchestration aspect of SOAR involves not only the collection of telemetry from these different sources, but also initiating a workflow, opening cases and tickets where appropriate, and correlation and enrichment of event information. Many large organizations, especially the type looking for SOAR systems, have IT Service Management (ITSM) Suites that dispatch and track activities in the form of tickets. SOAR solutions have case management capabilities by design, but they must also interoperate with existing ITSM solutions. For example, a ransomware attack will generate alerts from one or more endpoints and possibly network monitoring and data storage monitoring systems. SOAR’s job is to distinguish between related and unrelated events across all connected systems, assemble it coherently, enrich the event information by acquiring additional intelligence about observed entities (files, URLs, IP addresses, user accounts, etc.), create and/or coordinate tickets with ITSMs, with the goal of assisting human analysts and/or taking pre-programmed responses in playbooks.

Enrichment of event data can be facilitated by SOAR systems by the automatic collection of additional forensic evidence on-site, such as outputs of EPP scans, obtaining non-standard log files, memory dumps, etc. Some vendor solutions can kick off somewhat automated threat hunts (looking for IOCs across multiple nodes in an environment) and add the results to preliminary investigation. SOAR solutions should also be able to generate queries to threat intelligence sources based on suspicious items and patterns observed from upstream telemetry. Some vendors have extensive threat intelligence capabilities which are utilized by their SOAR solutions. External threat intelligence sources may and ideally should be used to supplement internal threat intel sources. Examples of threat intelligence content include IOCs (files, hashes, IPs, URLs, and so forth), compromised credential intelligence, device intelligence (often from Mobile Network Operators [MNOs]), and domain/file/IP/URL reputation information. Ideally SOAR solutions will accomplish all the foregoing actions automatically prior to or while alerting a human analyst.

When an analyst is alerted and assigned a case, all pertinent information related to the event should be constructed and presented by the SOAR platform to the analysts for their investigation. The SOAR platform should package information coherently, with descriptions and recommendations for actions.

Most SOAR vendors adhere to the paradigm of a playbook. Playbooks typically address common security scenarios and can be triggered either by manual analyst action or automatically if allowed by policy and supported by the vendor. Examples of security events that may trigger playbooks are phishing, malware, ransomware, failed login attempts, excessive or abnormal use of privileged credentials, prohibited communication attempts, attempts to access unauthorized resources, file copying or moving, attempts to transfer data using unauthorized webmail providers, attempts to transfer data to blocked IPs or URLs, unusual process launches, unusual application to network port activities, unusual network communication patterns, and so on.

The end goal of SOAR is being able to automate incident responses among the various security systems. To this end, SOAR platforms often support dozens to hundreds of playbook scenarios and offer hundreds to thousands of possible incident response actions.

Cybersecurity and IAM vendors have increasingly been exposing functions of their products and services via APIs, such as reporting, querying, workflow integration, and critical commands. The following are examples of functions by system type that many SOAR products allow the invocation of programmatically:

Email gateways

• Quarantine/delete email identified as having malicious content or content in violation of policy

EPP/EDR

• Terminate processes
• Delete files
• Get device info
• Isolate nodes
• Pull forensic data
• Hunt for Indicators of Compromise (IOCs)
• Lookup domain, file, or IP address reputation
• Start EPP scans on remote nodes
• Reboot a device
• Rollback a device configuration to last known good state

Firewalls, IDS/IPS, routers, switches, NDR, and VPNs

• Block traffic by port
• Block traffic by IP address / range
• Isolate nodes

IAM

• Get user info
• Suspend/delete user
• Force step-up authentication event

IaaS

• Enable/disable users
• Add/remove tags (such as in EC2)
• Start/stop instances

ITSM

• Get ticket info
• Create/update tickets
• Reassign tickets
• Close tickets

SIEM

• Execute queries

Web gateways and proxies

• Block traffic by IP address or URL

The preceding is a list of abstracted high-level actions. The actual syntax and parameters passed over APIs differs between products, which is one of the many challenges SOAR platform vendors face in building their solutions. SOAR solutions that have connectors for large numbers of security products have invested significant effort in developing them. Consequently, the more security connectors a SOAR platform can offer, the more likely that product can fit in a customer’s environment and deliver real value for security analysts. However, having a large number of connectors is not a primary determinant in tools choice; what matters most is finding the SOAR solution that has the specific connectors your organization needs.

1.1 Market Segment

The SOAR market, while still far from reaching full maturity, already has a reasonably well-established terminology and core set of capabilities. The term “SOAR” itself is already embraced by many vendors.

Some vendors in the market started out with a mission to address what they saw as missing functionality in the broader cybersecurity market. These startups may have gone through several rounds of funding and grown a sizable customer base. Furthermore, some of the bigger specialty startups in the SOAR market have been acquired by large cybersecurity stack vendors who were desirous to add these types of capabilities to their already extensive suites of products and services. In other cases, SOAR has been an outgrowth to complementary product offerings (most commonly SIEM) at some of the mid-tier vendors in the market.

Customers in the SOAR market tend to be somewhat larger SMBs, enterprises, and government agencies. Organizations that have established IT security departments, especially those with SOCs, are the most likely to see a need for SOAR. SMBs and some enterprises that are either outsourcing IT functions or adding security capabilities but not adding staff are turning to MSSP options that have SOAR.

The SOAR market is valid globally, but the greatest uptake has been in North America, followed by Europe. We expect to see more organizations across the world adding SOAR to their cybersecurity portfolios in the years ahead. SOAR as an outsourced function provided by MSSPs is also likely to grow in popularity.

One of the reasons that SOAR may be slower to be adopted outside of North America is the paucity of support for cybersecurity vendors outside the US. Most of the connectors built for SOAR products are for prominent American vendors. The vast majority of SOAR vendors do not have support for products of the large cybersecurity vendors that are headquartered in EU and APAC.