Market Guide for Security Orchestration, Automation and Response Solutions

Market Guide for Security Orchestration, Automation and Response Solutions

Published 27 June 2019 – ID G00389446 – 26 min read

SOAR solutions are gaining visibility and real-world use driven by early adoption to improve security operations centers. Security and risk management leaders should start to evaluate how these solutions can support and optimize their broader security operations capabilities.


Key Findings

  • The SOAR technology market aims to converge security orchestration and automation (SOA), security incident response (SIR) and threat intelligence platform (TIP) capabilities into single solutions.
  • Early adopters of SOAR technologies have been organizations and managed security service providers with mature security operations centers (SOCs) that understood the benefits of incorporating SOAR capabilities into their operations. However, use cases implemented by early adopters have not evolved over the last 12 months and are stuck in a rut, limiting the long-term potential for SOAR in security operations.
  • SOAR solutions are not “plug-and-play.” Even though solutions have a library of out-of-the-box use cases and integrations, buyers are reporting multiweek professional services engagements to implement their initial use cases, as every organization’s processes and technologies deployed are different.
  • Orchestration and automation are starting to be localized in point security technologies, usually in the form of predefined, automated workflows. This is not the same as a full-featured SOAR solution.


Security and risk management leaders overseeing security operations should:
  • Prepare for their SOAR implementations by having a starting set of defined processes and workflows that can be implemented. Out-of-the-box plays and integrations are a starting point but can rarely be implemented without some customizations.
  • Plan for the implementation and the ongoing operation and administration of SOAR tools by using a mix of professional services and internal resources.
  • Put a contingency plan in place in the event the SOAR tool is acquired by another vendor. Acquisitions are occurring with some frequency as the market evolves. Buyers should be prepared.

Strategic Planning Assumption

By year-end 2022, 30% of organizations with a security team larger than five people will leverage SOAR tools in their security operations, up from less than 5% today.

Market Definition

This document was revised on 3 July 2019. The document you are viewing is the corrected version. For more information, see the Corrections page on
Gartner defines security orchestration, automation and response (SOAR) as technologies that enable organizations to take inputs from a variety of sources (mostly from security information and event management [SIEM] systems) and apply workflows aligned to processes and procedures. These can be orchestrated via integrations with other technologies and automated to achieve a desired outcome and greater visibility. Additional capabilities include case and incident management features; the ability to manage threat intelligence, dashboards and reporting; and analytics that can be applied across various functions. SOAR tools significantly enhance security operations activities like threat detection and response by providing machine-powered assistance to human analysts to improve the efficiency and consistency of people and processes.
Most SOAR tools are still strongest in their original “home offerings,” which are security incident and response platforms (SIRPs), security orchestration and automation (SOA), and threat intelligence platforms (TIPs). Currently, the most common use case for SOAR by an organization is to define incident analysis and response procedures in a digital workflow format — such as plays in a security operations playbook. Additionally, these tools facilitate the use and operationalization of threat intelligence in security operations, which enhances the ability to predict, prevent, detect and respond to the prevailing threat landscape that a company faces.

Market Description

To understand the evolving SOAR market, it is necessary to define the specific terms used — namely, orchestration and automation — in the context of security operations:
  • Aggregation: The ability to aggregate/ingest data across sources. This may take the form of alerts, signals or other inputs from other technologies such as an alert from a SIEM tool or an email sent to a group mailbox. Other data that is ingested may include user information from an identity and access management (IAM) tool or threat intelligence from multiple sources.
  • Enrichment: Whether after incident identification or during data collection and processing, SOAR solutions can help integrate external threat intelligence, perform internal contextual look-ups or run processes to gather further data according to defined actions.
  • Orchestration: The complexity of combining resources involves coordination of workflows with manual and automated steps, involving many components and affecting information systems and often humans as well.
  • Automation: This concept involves the capability of software and systems to execute functions on their own, typically to affect other information systems and applications.
  • Response: Manual or automated response provides canned resolution to programmatically defined activities. This includes activities from a basic level — ticket creation in an IT service desk application — to more advanced activities like applying some form of response via another security control, like blocking an IP address by changing a firewall rule. This functionality is the most impactful, but also applies to the most complex use cases.
Buyers are expressing demand for SOAR for several reasons:
  • Staff shortages: Due to staff shortages in security operations, clients describe a growing need to automate repeatable tasks, streamline workflows and orchestrate security tasks resulting in operational scale. For instance, if you have a team, SOAR can give them more reach — but this is not a tool to get instead of a team. Also, organizations need the ability to demonstrate to management the organization’s ability to reduce the impact of inevitable incidents.
  • Continued evolution of threats and increases in volume: As organizations consider threats that destroy data and can result in disclosure of intellectual property and monetary extortion, they require rapid, consistent, continuous and more frequent responses with fewer manual steps.
  • Improving alert triage quality and speed: Security monitoring systems (such as SIEMs) are known to cost a significant amount to run and generate a high number of alerts, including many found to be “false positives” or simply not relevant after additional investigation. Security and risk management leaders then treat alert triage in a very manual way, which is subject to mistakes by the analysts. This leaves real incidents ignored. SOAR helps improve the signal-to-noise ratio by automating the repeatable, mundane aspects of incident investigation. This creates a positive situation where analysts can spend more time investigating and responding to an event instead of spending most of their time collecting all the data required to perform the investigation.
  • Need for a centralized view of threat intelligence: A large number of security controls on the market today benefit from threat intelligence. SOAR tools allow for the centralized collection, aggregation, deduplication, enrichment of existing data with threat intelligence and, importantly, conversion of intelligence into action.
  • Reducing time to respond, contain and remediate: Organizations are dealing with increasingly aggressive threats, such as ransomware, where rapid response of only minutes at best is required in order to stand a chance of containing the threat that is spread laterally in your environment. This scenario forces organizations to reduce the time they take to respond to those incidents, typically by delegating more tasks to machines. Reducing the response time, including incident containment and remediation, is one of the most effective ways to control the impact of security incidents. Like a brush fire, the sooner you can get to it, the smaller it is, and therefore the easier it is to put out.
  • Reducing unnecessary, routine work for the analysts: SOC analysts are often working with multiple tools. They are looking at a stream of row and column SIEM console alerts, threat intelligence (TI) service portals for information about the entities involved, and endpoint detection and response (EDR) for context on what is happening on the affected endpoint. They may even be using workflow tools to control the triage and investigation processes.
SOAR supports multiple activities for security operations decision making such as, but not limited to, the following:
  • Prioritizing security operations activities: Use of a SOAR solution requires organizations to consider questions about their processes. Which are most critical? Which ones consume the most staff time and resources? Which ones would benefit from automation? Where do we have gaps in our documented procedures? The preparation and planning for SOAR, and its ongoing use, help organizations prioritize and manage where orchestration and automation should be applied and where it can help improve response. This response can then lead to improvements in security operations and showing a demonstrable impact on business operations (e.g., faster time to detect and respond to threats that could impact business operations and optimization of security operations staff and budget).
  • Formalizing triage and incident response: Security operations teams must be consistent in their responses to incident and threats. They must also follow best practices, provide an audit trail and be measurable against business objectives.
  • Automating response: Speed is of the essence in today’s threat landscape. Attacks are increasing in speed (e.g., ransomware is now being automated to spread with worm functionality), but security operations are not automated. Having the ability to automate response action offers SOC teams the ability to quickly isolate/contain security incidents. Some responses can be fully automated, but at this time many SOAR users still inject a human to make the final decision. However, even this reduces the mean time to respond for the organization compared to being fully dependent on “human power.”

Market Direction

In 2015, Gartner described SOAR (which was then considered “security operations, analytics and reporting”) as resources that utilized machine-readable and stateful security data to provide reporting, analysis and management capabilities to support operational security teams. In 2017, as this market matures, Gartner observes three previously distinct technologies: security orchestration and automation (SOA), security incident response platforms (SIRPs), and threat intelligence platforms (TIPs), as depicted in Figure 1.

Figure 1. SOAR Types

SOAR Types
This convergence is still valid in 2019, with vendors increasingly adding features from areas of SOAR other than the area from which they first started. The acquisitions that happened in the last two years, however, may expand the use of such solutions to a broader scope. For example, after the acquisition of Phantom by Splunk, SOAR may become embedded into its SIEM and also used for IT operations use cases such as infrastructure monitoring, application performance monitoring and troubleshooting. SOAR selection in 2019 and beyond is being driven by use cases such as:
  • SOC optimization
  • Threat monitoring and response
  • Threat investigation and response
  • Threat intelligence management
Several major acquisitions have occurred in the last several years, as shown in Table 1.

Table 1: SOAR Acquisitions

Enlarge Table
FireEye (Helix) acquired Invotas
IBM acquired Resilient Systems
ServiceNow acquired Brightpoint Security
Microsoft acquired Hexadite
Rapid7 acquired Komand
Splunk acquired Phantom Cyber
Palo Alto Networks acquired Demisto
Source: Gartner (June 2019)
The Future of SOAR
Numerous acquisitions have been occurring consistently for three years. Vendors are looking to build a “security platform” to add SOAR to, either natively or via acquisition, suggesting that more acquisitions are a real possibility. This scenario requires buyers’ attention to create a contingency plan in case their SOAR tool is acquired by another vendor. At the same time, SOAR products must be vendor-agnostic to maintain value due to integration. The reality will more likely be that for some time independent solutions will continue to do a better job with their singular focus on roadmap execution and better treatment of being “vendor neutral” with available integrations.
SOAR can be the central hub for an organization to achieve several goals: monitoring the event from SIEM or other security controls; orchestrating different security products to construct the context; helping prioritize multiple concurrent items and incidents; and then driving response.
It’s still early days for SOAR (see “Innovation Insight for Security Orchestration, Automation and Response” and “Preparing Your Security Operations for Orchestration and Automation Tools”). However, the promise of improving the efficiencies and consistencies of SOC activities, as well as being able to offer more customized processes to managed security service (MSS) customers, is compelling. Some managed security service providers (MSSPs) have adopted SOAR technologies in earnest and have embedded them at the core of their delivery platforms. Based on conversations with SOAR technology vendors and MSSPs, we expect most MSSPs to adopt and embed SOAR capabilities over the next three years.
Other vendors are exploring the ability to work with not just traditional technologies but also cloud security and even nonsecurity use cases. For instance, during the creation of a new workload in the cloud without proper authorization, the playbook would notify operations and security and isolate (or delete) the workload until it is properly approved. Gartner recognizes the potential of using the orchestration and automation capabilities outside of security use cases, but this is not a really among the reasons that Gartner clients are implementing SOAR.
Use cases will continue to determine the capabilities that are important for each organization. For example, in the case of incident response, case management is highly valued by Gartner clients, but there are organizations that consider themselves ticket-driven companies. In that case, the organization is not willing to give up its ticket system, making case management irrelevant for that specific enterprise.
SOAR solutions with a broader scope of use cases will require role-based access control (RBAC) capabilities to allow segregation of duties as well as views of information.

Market Analysis

The SOAR market is still an emerging market, as examined in “Emerging Technology Analysis: SOAR Solutions,” and it is forecast to grow up to $550 million in the five-year (2018-2023) time frame (see “Forecast Analysis: SOAR, Worldwide”). Gartner clients are still lagging in their incident response (IR) capabilities and are asking for other solutions that would help them to improve their IR. Many organizations implement SOAR tools with use cases primarily focused on making their SOC analysts more efficient such that they can process more incidents while having more time to apply human analysis and drive response actions much quicker. Historically, they were not aware of the existence of these types of solutions. There are now more clients aware of SOAR solutions, which is fueling further adoption. This awareness is broadening; even SOAR vendors claim to have less work evangelizing about the technology and more conversations about their capabilities and differentiators. However, improving detection and response activities is just one of several opportunities for the use of SOAR tools to support security operations activities.
Since SOAR is often used as an umbrella term that covers security operations, security incident response and threat intelligence, many vendors are driving their existing solutions in the fight for market leadership.
Clients should recall that the selection of the right product will depend on the use cases.
For example, some vendors can ingest security events from a SIEM and apply enrichment to promote better triage capabilities, which include threat intelligence correlation but lag in case management. In such cases, an integration with an external case management system would be imperative to fulfill the incident response needs.
For the security operations use case — often the main purpose of a SOAR solution (see Figure 2) — an organization must have mature processes to be successful (see “Make Sure Your Organization Is Mature Enough for SOAR”). Security and risk management leaders should have an SOC with well-established processes and verify the level of API integration that would be possible with their current security toolset.
Figure 2 reflects the use of the continuous adaptive risk and trust assessment (CARTA) strategy for continuous monitoring and visibility, which includes a continuous set of activities that can be performed by an SOC team by using SOAR technology. CARTA’s value is that it is continuous, and one element helps and inform other elements, allowing for continuous improvement in your organization’s ability to improve both security posture and digital resilience.

Figure 2. SOAR Overview

SOAR Overview
Another aspect of the SOAR market is the pricing models that exist. The most common models are based on number of analysts (named), number of events and three tiers (each tier will determine which capabilities are available). For more information, see “Negotiate a Favorable Contract for Security Event Monitoring Technologies by Analyzing Licensing Models.”
The most common models are based on:
  • The number of (named) analysts using the tool
  • The number of events coming to the SOAR
  • The number of playbooks or actions the SOAR will perform
  • A tiered approach with higher tiers unlocking additional functionality and value
Gartner clients have systematically expressed frustration with pricing models that are hard to predict. It is very hard on 1 January to know how many events will hit the SOAR, or how many actions/playbooks the SOAR will do for the whole year.

Representative Vendors

The vendors listed in this Market Guide do not imply an exhaustive list. This section is intended to provide more understanding of the market and its offerings.

Market Introduction

A list of vendors is provided below. It is not, nor is it intended to be, a list of all vendors or offerings on the market or a competitive analysis of the vendors’ features and functions (see Note 1). This is also not a definitive list of each provider’s services.

Table 2: Representative Vendors in the Security Orchestration, Automation and Response Market

Enlarge Table
Product, Service or Solution Name
Ayehu NG Platform
D3 Security
Demisto Enterprise
EclecticIQ Platform
Security Operations
IR Flow
Source: Gartner (June 2019)

Vendor Profiles


Founded in 2017 in Turkey, ATAR helps manage SOC activities by offering three main capabilities: playbooks and automation, incident management, and SOC analytics. ATAR provides comprehensive automation and tight SIEM integrations. ATAR also has capabilities to monitor key performance indicators (KPIs) via customizable dashboards.


Founded in 2007, the Ayehu NG platform is a web-based IT automation and orchestration solution for security and IT operations. Its key features are playbook scheduling, enabling selective alerts to support remote control of incidents, audit trail generation, rollback of changes to workflows and role-based access to workflows in order to maintain access segregation for both teams (IT and security). Also, Ayehu NG uses machine learning to suggest playbooks and creation of rules. In addition, Ayehu NG bridges the gap between IT and security operations (network operations center [NOC] and SOC), streamlining automated workflow processes and tasks, and resolving IT and security alerts and incidents to improve SLAs.


Founded in 2015 as a spinoff of Elbit Systems, Cyberbit delivers SOAR through its SOC 3D platform. SOC 3D is based on three major capabilities: orchestration, automation and big data investigation, and includes a playbook builder for playbook creation and editing. Cyberbit also offers Cyberbit Range for training and simulation, SCADAShield and SCADAShield Mobile for OT visibility and detection of threats, and Cyberbit Endpoint Detection and Response (EDR) for endpoint detection and response. These products can optionally integrate with the SOAR platform for IT/OT detection and response.


Founded in 2011, CyberSponse is one of the few cybersecurity companies that is bootstrapped, with no outside investor or investment firm. Their current CyOps SOAR tool focuses mainly on incident response orchestration and automation, vulnerability management, fraud automation, and case management. Included within its playbook automation are some TIP features. CyOps has more than 275 out-of-the-box connectors and 200 out-of-the-box playbooks utilizing all major vendors and technologies.

D3 Security

Founded in 2002 to support incident/case management for security and privacy, D3 Security emerged in 2004 with a focus on incident response. D3 Security is self-funded by its founders with no outside investment. Today, D3 Security offers a SOAR tool designed to respond to adversarial intent with automated kill chain playbooks based on the MITRE ATT&CK framework or other tactics, techniques and procedures (TTP) resources. The tool has powerful RBAC and chain-of-custody features, TIP capabilities, and more than 200 connectors to date. The tool is sold as a modular platform with specific modules sold separately. For each module, pricing is based on the number of users (e.g., SOC analysts, not the number of employees in the organization).


Founded in 2015, Demisto raised $69 million and was acquired by Palo Alto Networks in February 2019 for $560 million — emphatic proof of the perceived value of these tools. Demisto’s focus has been to optimize the efficiency of security operations by offering a single platform for SOC analysts to manage incidents, automate and standardize incident response processes, and collaborate on incident investigations. Demisto makes use of machine learning (ML) to support functions such as incident triage or to offer SOC analysts some suggestions for next steps. Demisto offers a War Room for analysts to collaborate on investigating incidents, with action being autodocumented for post-incident reporting. Demisto offers robust incident/case management and playbook automation features, and more than 300 product integrations out-of-the-box. Pricing is based on the number of users (e.g., SOC analysts, not the number of employees in the organization).


As a technology company since 2013, DFLabs is a SOAR provider focusing on incident response and threat intelligence that can be used on the SOC, computer security incident response team (CSIRT) and MSSP. The SOAR solution promotes the security incident life cycle using R3 Rapid Response Runbooks (referred to as playbooks by other vendors) that execute workflows and data enrichment, notification, containment, and custom actions. DFLabs uses machine learning in two situations: for recommendation of actions based on steps for similar or related threats and for triage to prefilter security events. DFLabs’ incident management support enables the documentation of physical and logical evidence and audit logs, document policies, procedures, and best practices in the knowledge base.


Founded in 2014, EclecticIQ is a provider of technology and services for the aggregation, analysis and sharing of threat intelligence and its operationalization through downstream integrations. A key feature of EclecticIQ is the ability to enable analysts to leverage intelligence-led techniques for threat hunting, incident response, threat and threat actor enumeration, and tracking. Another capability, called Fusion Center, eases selection of upstream intelligence sources by offering single and fused bundles of intelligence at fixed prices. Clients can select from a wide range of commercial and open-source threat intelligence feeds that are fused according to the themes most relevant to the customer.

IBM Resilient

IBM Resilient, founded in 2010 as Co3 Systems and acquired by IBM in 2016, provides workflow, case management, and orchestration and automation capabilities for security and privacy teams at hundreds of customers. The three features that Resilient focuses on are case management, orchestration and automation, and human- and machine-based intelligence. The solution is delivered via software for on-premises deployments or via SaaS model; it is also available as an MSSP offering for managed service providers and forms part of IBM’s X-Force Threat Management Service offering. Resilient also leverages the IBM X-Force Exchange where IBM, technology partner and user-created apps can be shared.


Founded in 2000, Rapid7 acquired Komand — a SOAR vendor — in July 2017 and is now offering a SOAR called InsightConnect. InsightConnect’s security orchestration and automation helps security analysts optimize SOC operations through a library of more than 270 plug-ins and a visual workflow builder that requires little to no code. The automation capabilities in Rapid7’s vulnerability management (InsightVM) and cloud SIEM solutions with embedded UEBA solutions (InsightIDR) mean that customers can automate processes for automation-assisted patching and threat containment. InsightConnect is only available as a cloud-based solution, and is part of Insight, Rapid7’s broader security management platform.


Founded in 2014, Resolve’s orchestration and automation platform aims to bridge security and IT processes with prebuilt connectors for both security and IT infrastructure systems. The Resolve platform focuses mainly on incident response and case management but has expanded preventive measure capabilities such as secure provisioning, patch management and audit trails. The platform provides playbooks on NISTSP 800-61 Revision 2 (the Computer Security Incident Handling Guide | CSRC). Also, its case management capability stores all artifacts and actions that relate to the incident and provides a contextual recommendation for each step to accelerate response.


Security Operations is the product from ServiceNow that provides a security orchestration and automation solution that is used by hundreds of customers. Security Operations is delivered from the Now Platform as SaaS and provides workflow, case management, orchestration and automation, and threat intelligence management. Additional capabilities also address vulnerability management and security operations metrics, reporting and dashboards, and configuration compliance, as well as governance risk and compliance. Three service packages (Standard [security incident response or vulnerability response], Professional and Enterprise) are available with Enterprise being required to get the fullest set of SOAR capabilities, including orchestration.


Founded in 2015 in Tel Aviv, Israel, Siemplify is used mainly for SOC activities with an easy-to-use user interface. Siemplify provides context-driven investigation capabilities that visually correlate incidents and group alerts to help the analyst reduce time to respond. Along with case management, it helps control the flow of incidents across the SOC analysts. Also, Siemplify uses machine learning capabilities to prioritize and suggest which analyst would be best for a specific incident. Multitenancy capabilities are also promoted for managed service users. Siemplify also provides dashboards and reporting for tracking and SOC metrics, and recently added crisis management and analyst collaboration modules as part of version 5.0.


Phantom Cyber, founded in 2014, was acquired by Splunk in 2018. The Splunk Phantom solution provides orchestration and automation capabilities along with case management functionality. Splunk Phantom is deployed on-premises as software. Additional functionality includes its central view, called Phantom Mission Control, as well as its recommendation capability, called Mission Guidance. Logical data separation is available to provide multitenancy capabilities for managed services users. The licensing model is based on events per day (EPD). An event is only considered a notable event if it was acted upon. In other words, not everything ingested into the Phantom solution is actioned; thus, not all the events will be charged for. Once an event is actioned, the customer has unlimited actions within that specific event. They can do whatever they need to, for example, run playbooks multiple times.


Founded in 2014, Swimlane focuses on the orchestration and automation of existing security controls interacting with over 850 APIs for an organization’s existing technology stack and can let an organization reuse existing scripts. A key capability is for clients to develop playbooks that visually represent complicated security operations workflows using a drag-and-drop-type of paradigm where analytics and automation can be brought to bear on operations. This allows for security teams to achieve better accuracy, consistency and time efficiency for analysts.


Syncurity was founded in 2014. The Syncurity IR Flow solution focuses on orchestration, automation, dashboards and reporting, with alert triage, incident management and collaboration capabilities. The solution is positioned as end-to-end case management. Validated incidents that can be programmatically defined are handled through automation to allow for focusing on unvalidated events requiring analyst involvement. Dynamic risk scoring is a feature, and an analyst workbench is provided for investigation and cross-analyst collaboration. The solution is delivered as software, and support is provided as on-premises or private cloud deployment for enterprises and managed security service providers, including multitenancy and granular role-based access control (RBAC) features.


Founded in 2011, ThreatConnect has an architecture delivering both threat intelligence platform (TIP) and security orchestration and automation (SOA) features from the same product. ThreatConnect’s large ecosystem of integrations (built internally and by third parties) allows for the application of intelligence from both internal and external sources to security processes and workflows. In recent years, ThreatConnect has expanded on its TIP heritage to also deliver further orchestration and automation capabilities that aid in a wide range of SOAR use cases.


Founded in 2013, ThreatQuotient delivers the ThreatQ platform that relies on threat intelligence and contextual information to drive a score-driven triage process to help prioritize actions across a variety of security operations use cases. Also, ThreatQ delivers a user interface that supports investigation to: improve the understanding of threats, promote collaboration across different teams and enable the execution of playbooks to perform data enrichment and other response actions. Also, the offering uses a learning system that captures other systems feedback to collaborate with other incident triage, taking into consideration results of previous events using a self-tuning capability that makes the system more and more customer-specific over time.

Market Recommendations

Security and risk management leaders should consider SOAR tools in their security operations to meet the following goal: improve security operations efficiency and efficacy.
SOAR tools offer a way to orchestrate and automate response. A common use case would be consuming events from a SIEM to enrich the context of an alert. The events most amenable to automation are the ones with the lowest risk of being false positive. For example, with a user credential lockout, SOAR can be used to execute a playbook to validate if this event is based on human error (e.g., user forgot the password) or verify if this event might be a brute-force attack. For both options, the analyst would have to execute a series of steps that would force the account to change the password, which could be automated through consistent workflow execution. This is beneficial for many reasons, including:
  • Performing the task faster equals better time to resolution. The longer an issue is left unaddressed, the worse it can become, leaving the organization in a potentially risky situation for longer periods of time. Ransomware, for example, is a threat that can get exponentially worse with time.
  • Staff shortages are a critical issue for many organizations. The ability to handle processes more efficiently means that security analysts can spend less time with each incident and will thus be able to handle and respond to more incidents, allowing response to more incidents despite fewer resources being available.
SOAR Tool Advice
In terms of product selection, security and risk management leaders should favor SOAR solutions that:
  • Deliver the use cases needed to complement their set of security products to manage their SOC. For instance, some clients prefer to use the company ticket system instead of a dedicated case management solution; but, instead, they value the threat investigation capabilities more. Buying a SOAR solution today must be driven by the use case: SOC optimization, threat monitoring and response, threat investigation and hunting, and threat intelligence management.
  • Offer the capability to easily code an organization’s existing playbooks that the tool can then automate, either via an intuitive UI and/or via a simple script.
  • Optimize the collaboration of analysts in the SOC, for example, with a chat or IM framework that makes analysts’ communication more efficient, or with the ability to work together on complex cases.
  • Have a pricing cost that is aligned with the needs of the organization and that is predictable. Avoid pricing structures based on the volume of data managed by the tool or based on the number of playbooks run per month, as these metrics carry an automatic penalty for more frequent use of the solution.
  • Offer flexibility in the deployment and hosting of the solution — either in the cloud, on-premises or a hybrid of these — to accommodate organizations’ security policies and privacy considerations, or organizations’ cloud-first initiatives.

Note 1Representative Vendor Selection

Gartner is tracking 28 vendors in the SOAR market. The vendor list below, capped at 18, includes only sample representative vendors that appear most frequently in analyst interactions with Gartner clients.

Note 2Gartner’s Initial Market Coverage

This Market Guide provides Gartner’s initial coverage of the market and focuses on the market definition, rationale for the market and market dynamics.

Threat Modelling – A practical method

Threat Modelling – A practical method

Threat modelling is an exercise to generate use cases/content aligned to key business risks or concerns around specific assets. Questions are no different than probing for cyber operations optimisation.

Asset Modelling

Capture asset value align to Traffic Light Protocol and allow for heighten response for red and yellow assets.

ArcSight Asset Modeling - YouTube 2020-01-23 13-36-07

Zoom Meeting ID: 552-878-997 2020-01-24 12-15-18


Security architecture anti-patterns


At the NCSC, our technical experts provide consultancy to help SMEs and larger organisations build secure networks and systems.

This security paper describes some common patterns we often see in system designs that you should avoid. We’ll unpick the thinking behind them, explain why the patterns are bad, and most importantly, propose better alternatives.

This paper is aimed at network designers, technical architects and security architects with responsibility for designing systems within large organisations. Technical staff within smaller organisations may also find the content useful.

 Download this security paper (PDF)


A few quick points on terminology before we start.


The term ‘anti-pattern‘ is now used to refer to any repeated (but ineffective) solution to a common problem, it is credited to Andrew Koenig who coined it in response to the seminal book ‘Design Patterns: Elements of Reusable Object-Oriented Software’.


Computer systems rarely exist in isolation. That is, they connect to networks and other systems. You might trust some of these other networks and systems more than others, and the owners of those might not trust yours at all. We use the terms:

  • less trusted (or low side) to refer to the system in which we have less confidence in its integrity
  • more trusted (or high side) to refer to the system in which we have more confidence in its integrity

Information technology vs operational technology

When thinking about trust and integrity, we consider administration of information technology to have broadly similar requirements to the operation of operational technology. Our examples below focus on the more typical information technology examples, but we think many of the concepts can be used in operational technology environments too.

Anti-pattern 1: ‘Browse-up’ for administration

When administration of a system is performed from a device which is less trusted than the system being administered. ​

Unfortunately it is all too common to see ‘browse-up’ approaches to administering systems, which proves that common practice isn’t always good practice. In such scenarios, an end user device used by an administrator can be one of the easiest paths into the target system, even if access is via a ‘bastion host‘ or ‘jump box’.

In computer systems where integrity is important (whether in digital services which handle personal data or payments, through to industrial control systems), if you don’t have confidence in devices that have been used to administer or operate a system, you can’t have confidence in the integrity of that system.

There’s a common misconception that a bastion host or jump box is a good way of injecting trust into the situation, to somehow get confidence in the actions an administrator is taking from a device you don’t trust. Unfortunately, that’s not possible.

Bastion hosts are useful for helping monitor and analyse the actions that administrators are performing, and they can help you avoid exposing more than one protocol outside of your system for administration purposes. But they won’t help you be confident that the user on the device is the person you intended to allow access to. Behind the scenes, the credentials used to authenticate to the jump box could have been compromised (a reasonable assumption, given the device is less trusted). Even if administrators are authenticating their sessions with two factors, there is still the potential for malware to perform session hijacking on remote desktop or shell connections in the same way that online banking sessions are hijacked. Having gained access, the attacker can perform additional actions on behalf of the administrator. The system is under their control.

How to identify this anti-pattern

Here are three ways you can identify browse-up administration:

  1. By looking for administration activities performed via a remote desktop (or remote shell) from a device which is part of a less trusted system.
  2. By looking for outsourcing or remote support connections where a third party uses a remote desktop or shell to reach into a network. If you’ve got confidence in the integrity of the device used by the third party, then this isn’t a browse-up problem, but if you have less confidence in their system than in yours, then it is.
  3. Finally, any device which browses the web or reads external email is untrusted. So if you find an administrator using a remote desktop or shell to perform administration from the same processing context that they browse the web (or read their external email) from, then that’s browsing-up too.

A better approach: ‘browse-down’

You should always use devices that you have confidence in the integrity of for administration of production systems. Those devices need to be kept hygienic (that is, they should not natively browse the web or open external email, as those are dangerous things for an administration device to do).

If, for convenience, you want to do those things from the same device, then we recommend that you ‘browse-down’ to do so. In a ‘browse-down’ model, the riskier activities are performed in a separate processing context. The strength of separation can be tailored to your needs, but the goal is to ensure that if an activity in the less trusted environment led to a compromise, then the attacker would not have any administrative access to the more trusted environment.

There are many ways in which you can build a browse-down approach. You could use a virtual machine on the administrative device to perform any activities on less trusted systems. Or you could browse-down to a remote machine over a remote desktop or shell protocol. The idea is that if the dirty (less trusted) environment gets compromised, then it’s not ‘underneath’ the clean environment in the processing stack, and the malware operator would have their work cut out to get access to your clean environment.

Further reading

Anti-pattern 2: Management bypass

When layered defences in a network data plane can be short-cut via the management plane.​

It’s good practice to separate management communications from the normal data or user communications on a network. In some system architectures, this would be known as separating the data plane from the management plane. However, whilst it is common to separate these types of communications with network controls, it is a common mistake to only apply the defence-in-depth concept to the data plane. If the management plane offers an easier route to the ‘crown jewels’ of a computer system than the data plane, then this a management bypass.

How to identify this anti-pattern

Look for any management interfaces from components within different layers of a system, all connected to a single switch used for management, without the corresponding layers.

A better approach: layered defences in management planes

The solution is simple; build similar layered defences into management planes to those you have in data planes. Good practices include:

  • manage from a higher trusted device, browsing down to lower trust layers
  • separate bastion hosts to manage systems in each trust boundary
  • different credentials for different layers to help prevent lateral movement
  • restrict how systems on the data plane communicate with management plane infrastructure and vice-versa

Further reading

Anti-pattern 3: Back-to-back firewalls

When the same controls are implemented by two firewalls in series, sometimes from different manufacturers.

There seems to be a widely believed myth that the security benefit of ‘doubling up’ on firewalls to implement the same set of controls is a worthwhile thing to do. Some also believe that it is preferable for the two firewalls to come from different manufacturers, their thinking being that a vulnerability in one is unlikely to be present in the other. In our experience this almost always adds additional cost, complexity, and maintenance overheads for little or no benefit.

Let’s explore why we see little benefit in back-to-back firewalls in almost all cases. Take the example of an OSI layer 3/4 firewall. It has a simple job to do; control which network communications can pass through the device, and which ones can’t. Putting two layer 3/4 firewalls in series is analogous to draining boiled potatoes with two colanders rather than one – it just creates more washing up.

But what if there was a vulnerability that can be exploited in a single firewall? Well, yes, that’s possible. There are vulnerabilities in most things after all. But firewalls don’t tend to have vulnerabilities that can be exploited to yield code execution from processing the header of a TCP/IP packet. They tend to have vulnerabilities in their management interfaces, so you shouldn’t expose their management interfaces to untrusted networks .

Even if there were vulnerabilities discovered in the data plane interfaces of a firewall, applying patches swiftly after their release would mean that any attack would need to exploit a zero-day vulnerability, rather than a well-known vulnerability. Furthermore, defence-in-depth design would mean that it should take more than a firewall breach to compromise sensitive data or the integrity of a critical system, and needing two zero-days to be exploited puts the attacker’s capability level well beyond the threat model for most systems.

Having two firewalls would also double your admin overhead, and if you require two different vendors then you need to retain expertise in both, which adds still more cost and complexity. Plus, you have more infrastructure to maintain, and most of us find it hard enough to keep up with patching one set of network infrastructure.

However, there is one exception where we’ve found two firewalls to be useful; for supporting a contractual interface between two different parties. We cover this exception at the end of this section.

How to identify this anti-pattern

Look for two firewalls in series in a network architecture diagram.

A better approach: do it once, and do it well

One well-maintained, well-configured firewall or network appliance is better than two poorly maintained ones. We also recommend the following good practices:

  • avoid exposing the management interfaces of network appliances to untrusted networks, and properly manage the credentials used with them
  • have a simple policy configuration to reduce the chance of mistakes being introduced
  • use configuration management tools to ensure you know what the configuration should be, so you can tell when it isn’t correct (a tell-tale sign of compromise or internal change procedures not being followed)

The one exception

There is one example of using two firewalls back-to-back that makes more sense; to act as a contract enforcement point between two entities that are connecting to each other. If both parties agree on which subnets in their respective networks can communicate using which protocols, then both can ensure this is enforced by applying the agreed controls on a firewall they each manage.

Further reading

Anti-pattern 4: Building an ‘on-prem’ solution in the cloud

When you build – in the public cloud – the solution you would have built in your own data centres.

Organisations taking their first step into the public cloud often make the mistake of building the same thing they would have built within their own premises, but on top of Infrastructure-as-a-Service foundations in the public cloud. The problem with this approach is that you will retain most of the same issues you had within your on-prem infrastructure. In particular, you retain significant maintenance overheads for patching operating systems and software packages, and you probably don’t benefit from the auto-scaling features that you were hoping you’d gain in the cloud.

How to identify this anti-pattern

Look for:

  • database engines, file stores, load balancers and security appliances installed on compute instances
  • separate development (and test, reference, production etc.) environments left running 24/7
  • virtual appliances used without considering whether cloud-native controls would be suitable

A better approach: use higher order functions

Unless you’re quicker at testing and deploying operating system patches than your public cloud provider is, you are probably better off letting them focus on doing that. Compare their track record of patching operating systems against your own, and judge for yourself.

Similarly, when it comes to patching database engines (or other storage services), their higher abstraction Platform-as-a-Service offerings are likely to be maintained to a level that many large enterprises will be envious of. Using higher level services like these means:

  • unnecessary infrastructure management overhead is reduced
  • you can focus on the things that are unique to your organisation
  • your system is easier to keep patched to address known security issues

Further reading

Anti-pattern 5: Uncontrolled and unobserved third party access

When a third party has unfettered remote access for administrative or operational purposes, without any constraints or monitoring in place.

Many organisations outsource support for some or all of their systems to a third party. This isn’t necessarily a bad thing, unless done without understanding and managing the risks involved. If you outsource administration or operational functions, you’re dependent on another organisation to keep your system secure. The staff, the processes and the technology of the third party all need to be considered.

Leaving the staff and processes to one side for the moment, if a third party is administering your system, they will require access, often remotely. It’s common to allow third parties to have access through a bastion host, either over the internet from whitelisted locations, or over a private network. However, there are often not enough controls in place to limit the operations that can be performed via the bastion host. If this is the case, and a bastion host (or the device used by the third party) is compromised, then an attacker could gain significant access to connected systems.

Let’s take an example. Suppose you have purchased some niche technology that comes with a specialist support contract where the vendor needs remote access to support the device. In this case, the support organisation only needs access to the component they are supporting, and not to any other parts of your system. If you provided a bastion host that gave access to an internal network (and relied on their processes to only access the component they supported, rather than technically enforcing that process), then a breach of the supplier’s system (or of your bastion) host would be much more damaging than it could have been.

By locking these accesses down and efficiently auditing the connection, the risk of third party compromise can be greatly reduced.

How to identify this anti-pattern

It’s often possible to identify these relationships with third parties by looking for ‘umbilical cords’ out of network diagrams.

A better approach: a good contract, constrained access and a thorough audit trail

A good approach includes the following:

  1. Choose third parties carefully with a sensible contract that sets out the controls relating to the people, processes and technology you need to have confidence in.
  2. Constrained access following the principle of least privilege; only allow remote and authenticated users to have logical access to the systems they need to reach.
  3. Ensure you have the audit trail you need to support incident response and support effective protective monitoring. When it comes to incident response, will you be able to confidently know which commands were executed by which user from the third-party supplier?

We also recommend the following good practices when designing a remote access solution for third parties:

  • ask your supplier how they prevent attackers moving laterally between their other clients and your systems
  • ensure that remote support staff use multi-factor authentication and ensure they do not share credentials – this will help you account for individual actions in event of a breach
  • provide separate isolated third party access systems for different third parties
  • consider using a just-in-time administration approach, only enabling remote administrative access in relation to a support ticket that is being actively worked on

Further reading

Anti-pattern 6: The un-patchable system

When a system cannot be patched due to it needing to remain operational 24/7.

Some systems need to run 24/7. A lack of foresight could mean a system can’t have security patches applied without scheduling a large window of downtime. Depending on the technologies and the complexity, it may require a window of hours (or days) to apply a patch, which could be unpalatable length of operational downtime. As time goes by, the option to defer applying security patches could mean you’re left with huge number to apply during a maintenance window. Applying so many patches has now become too much of a risk, so you’re trapped in a vicious circle with a system that’s virtually un-patchable.

How to identify this anti-pattern

Look for a lack of redundancy within system architectures. Systems which require all components to be operational at all times do not lend themselves to phased upgrades, where the system could remain operational whilst undergoing maintenance.

The lack of a representative development or reference system (or ability to quickly create one) can signify a related problem. If the system owners have no confidence that the development or reference system is similar to the production system, then this can contribute to a fear of affecting stability by patching.

A better approach: design for ‘easy’ maintenance, little and often

One of the NCSC’s design principles is to design for easy maintenance. In some systems, this could mean ensuring you can patch a system in phases, without needing to disrupt operations. Whist this would likely require higher infrastructure cost, some of the overall lifetime costs could be lower when factoring in:

  • fewer, shorter outages
  • reduced risk of compromise (which could incur a costly incident response)

Further reading


Network diagram

Security Architecture Anti-patterns

Six design patterns to avoid when designing computer systems.
  • PDF
  • 541 KB
  • 14

Using Mitre ATT&CK for Cyber Threat Intelligence Training

Using Mitre ATT&CK for Cyber Threat Intelligence Training

Module 1: Introducing training and understanding ATT&CK
Module 2 with Exercise 2: Mapping to ATT&CK from finished reporting

Exercise 2: Mapping from finished reporting

Cybereason Cobalt Kitty Report: we walk through this exercise in the video and slides.

FireEye APT39 Report: we do not walk through this exercise in the video and slides, but if you would like more practice mapping finished reporting to ATT&CK, we recommend you do this exercise on your own.

Module 3 with Exercise 3: Mapping to ATT&CK from raw data

Exercise 3: Working with raw data

Ticket 473822: we walk through this exercise in the video and slides

Ticket 4473845: we walk through this exercise in the video and slides

Module 4 with Exercise 4: Storing and analyzing ATT&CK-mapped intel

Exercise 4: Comparing layers in ATT&CK Navigator

  • Comparing Layers in Navigator
    Provides detailed instructions for using Navigator to compare techniques used by APT39 and Cobalt Kitty (OceanLotus). You may find it useful to print this document (in color if possible) to have it as a reference as you work through the exercise on your screen.
  • APT39 and Cobalt Kitty techniques
    A list of the techniques used by APT39 and Cobalt Kitty (OceanLotus) extracted from the reports in Exercise 2. If you are already familiar with Navigator, you could use these techniques to try to create and compare layers yourself.
Module 5 with Exercise 5: Making ATT&CK-mapped data actionable with defensive recommendations

Exercise 5: Making defensive recommendations

Guided Exercise: we walk through this exercise in the video and slides.

Guides you though steps for making defensive recommendations from ATT&CK techniques with specific questions and assumptions provided for each step.Unguided Exercise: we do not walk through this exercise in the video and slides, but if you would like more practice making defensive recommendations directly related to your own organization, we recommend you do this exercise on your own.

Provides steps for making defensive recommendations from ATT&CK techniques.


NICE Cybersecurity Workforce Framework

NICE Cybersecurity Workforce Framework

The National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework (NICE Framework), published by the National Institute of Standards and Technology (NIST) in NIST Special Publication 800-181, is a nationally focused resource that establishes a taxonomy and common lexicon to describe cybersecurity work, and workers, regardless of where, or for whom, the work is performed.

Why am I learning Kotlin

Why am I learning Kotlin


I started my career teaching my self GW-BASIC, then moved to a bit of C++ and ASM, soon realized other than getting a job in Computer games programming, it was very difficult to find jobs using C++ and ASM in my small town, thought about Java and by that time, I moved into infrastructure and away from development. Writing boring business logic really didn’t interest me.. But, now that full stack development means you can pretty much develop apps all on your own and deploy them globally, I am once again interested in getting back and working on some projects. The likes of Snapchat and Instagram are incredible motivation to learn.  Such basic apps that sold for millions of dollars.

But were do you start, there are so many different frameworks and languages you get lost in google search within 30mins.

Lets start with few criteria;

  1. Must be well funded
  2. Must be opensource
  3. Must be popular on GIT
  4. Must be multi-platform and execute on iOS, Android, Windows, OSX, Linux, IoT and other with single source.
  5. Must be able to build front end, backend, APIs, micro services and integrate easily with backend solutions like firebase.
  6. Support for Strongly typed, OOB, refresh, PWA, Tree Shaking, Code Splitting, Progressive Hydration and Layered Routing.
  7. Support for UI frameworks, Bootstrap, module NPM style.