Leadership Compass

Security Orchestration, Automation and Response (SOAR)

This report provides an overview of the SOAR market and provides you with a compass to help you to find the solution that best meets your needs. We examine the SOAR market segment, product/service functionality, relative market share, and innovative approaches to providing SOAR solutions.

John Tolbert

jt@kuppingercole.com

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.

1.2 Delivery models

SOAR solutions often require complex deployment models. In most cases, on-premise components must be implemented, including software agents for upstream security systems from which telemetry will be gathered, and appliances and/or virtual appliances that serve as collection, analysis, operational, and management nodes for the SOAR solution.

SOAR systems also generally provide support for various cloud hosted environments such as IaaS and PaaS, which requires agents or images to be installed or the use of customized APIs. Some support specific SaaS applications as well.

In addition to APIs and connectors for security tools, SOAR platforms have user interfaces for administrators and analysts. Some vendors offer this as a capability on the components installed on-premises and others offer it as a cloud-hosted service.

Few SOAR vendors offer managed services whereby they collect and examine telemetry from customers, and then either automatically or, on the customer’s behalf, execute incident response actions from playbooks. However, Managed Security Service Providers (MSSPs) license SOAR platforms from the major vendors and operate them for clients.

1.3 Required capabilities

Broadly speaking, there are three major concentrations of technical capabilities within SOAR solutions.

Security data collection, correlation and enrichment: a SOAR platform can collect historical and real-time security telemetry either on its own or ingest security events from a SIEM solution. If necessary, the data should be enriched with additional business context and forensic information, external threat intelligence, or other data sources according to established workflows.

Security Orchestration and Automation: a SOAR platform should implement comprehensive workflow management capabilities to ensure that tasks across multiple environments and security tools can be efficiently coordinated. Whenever possible, repetitive parts of these workflows should be automated to free the analyst’s time for more creative tasks. For manual steps, intelligent guidance and decision support capabilities are a major plus.

Incident Response and mitigation: for identified security incidents, a SOAR platform should be able to offer a range of predefined resolutions: ranging from simple actions like creating a ticket for manual processing or quarantining compromised nodes to more sophisticated playbooks that coordinate response processes across multiple systems and departments: from IT to GRC to legal and public relations. For IR operations, the availability of connectors and configurable APIs and specific collections of actions per system type are paramount concerns for those implementing SOAR.

Evaluation Criteria Key Features

  • Telemetry collection: the ability to collect potential security event information from a broad range of systems. Pre-configured connectors are ideal in most circumstances. The ability to accept feeds and formats and perform queries using CEF, CSV, OpenDXL, osquery, REST APIs, and syslog is optional and mainly seen in SOAR products which have arisen from SIEMs.
  • Correlation: once ingested, effective SOAR solutions must parse large volumes of data from different sources and assemble related bits of information into a package that can be evaluated by and acted upon by human and AI/ML processes. ML enhanced detection and selection algorithms are preferred and, in most cases, necessary to adequately handle the volumes of telemetry in large organizations. Some vendors package User Behavioral Analysis (UBA) with their SOAR platforms so they can add historical insights to current event data. This type of analysis generally relies upon different subsets of ML detection algorithms specific for UBA. The correlation process must often be supplemented with enrichment of acquired data.
  • Enrichment: Both known IOCs and suspicious items such as files, process launches, registry entries, IPs, URLs, etc. may percolate up from underlying security systems or be identified as IOCs or at least suspicious by an upstream SIEM or by the SOAR system itself. SOAR solutions can automate the collection of threat intelligence and querying of 3rd-party sources regarding these suspicious items associated with a case. The SOAR solution then packages the collected intelligence for analyst review.
  • Workflow orchestration, automation, and case management: SOARs are designed to facilitate rapid investigations and responses to possible security incidents. While telemetry collection, preliminary analysis, and information enrichment can happen prior to analyst involvement, SOARs must provide ergonomic interfaces for human analysts at the point where their input is needed. Generally speaking, SOARs should by design seek to eliminate repetitive and menial tasks that analysts have to do to increase the speed of processing and successful resolution of security incidents. Thus, SOARs must offer logical and flexible workflow automation capabilities in the context of case management. SOARs are expected to perform evidence collection and triage; and then be able to create and manage cases. SOARs must be able to interoperate with all the relevant tools within the customer’s security portfolio, allowing real-time forensic analysis, querying of remote systems, and execution of investigative actions. For this reason, SOARs generally must work with ITSM and ticketing applications and direct (often asynchronously) the interactions between the other components of the customer’s infrastructure. While SOARs ship with pre-defined workflows, they should be customizable to meet individual customer needs and extensible to enable customers to add new security tools to their environments as needed. Extensibility is the key to future-proofing SOAR implementations.
  • Incident response: the ability of a SOAR system to respond to incidents depends on the variety of connectors and quality of implementation of those connectors. The types of systems with which SOAR must interoperate include email/web gateways, EPP/EDR, firewalls/network security devices and services, IAM, IaaS instances, ITSM, and SIEM. Incident response capabilities should also extend to non-IT processes where possible. For example, SOAR playbooks can often provide guidance and the ability to automate communications about ongoing incidents if defined. Most vendor platforms come with some pre-defined playbooks for common situations. Playbooks should be customizable and support conditional logic for automated incident responses.

We are not covering solutions that only focus on a specific type of IT environment or a subset of security information (for example, firewall orchestration or network traffic monitoring). We expect full-featured SOAR products to be able to serve as comprehensive and extensible security analytics platforms for SOCs.

We understand that most existing SOAR offerings have evolved from previous-generation, more specialized SIEM, incident response or security automation solutions, and their core capabilities may vary substantially depending on their origin. In other cases, threat intelligence platforms have begun to metamorphose into SOARs. Regardless of their genesis, we expect reasonably mature solutions to have balanced capabilities across all core functional areas.

The criteria evaluated in this Leadership Compass reflect the varieties of use cases, experiences, business rules, and technical capabilities required by KuppingerCole clients today, and what we anticipate clients will need in the future. The products examined meet many of the requirements described above, although they sometimes take different approaches in solving the business problems.

When evaluating the products and services, besides looking at our standard criteria of

  • overall functionality and usability
  • internal product/service security
  • size of the company
  • number of tenants/customers and end-user consumers
  • number of developers
  • partner ecosystem
  • licensing mod

We have also looked at specific USPs (Unique Selling Propositions) and innovative features of products which distinguish them from other offerings available in the market. Features that are considered innovative are listed below.

  • Support for standards such as STIX, TAXII, and CyBox.
  • Contributions to the Open Cybersecurity Alliance (OCA), an industry association sponsored by OASIS for the promotion of interoperability between products in the SOAR space.
  • SOAR functionality across multi-cloud environments.
  • Well-documented APIs that allow customers to extend SOAR connectivity to other solutions.
  • Multi-Factor Authentication (MFA) and identity federation for customer admins and analysts.
  • Workflows and playbooks that address communications and PR aspects of major security incidents.
  • Large numbers of built-in connectors to facilitate deployment alongside a variety of other security tools.

Please note that we only listed a sample of features, and we consider other capabilities per solution as well when evaluating and rating the various SOAR solutions.

Continue reading...
Read the full report and get access to KuppingerCole Research for 4 weeks.
Start Your Free Trial
Already a subscriber? Click here to login.