My last post, entitled “What is SOAR and why is it important”, illustrated why SOAR is needed in the industry alongside faster maturation. If you didn’t catch that one, I’d suggest reading it first for context. 

With that post as the backdrop, I will now focus on how we can solve the two main issues with traditional SIEM and SOC: response time and expertise, both of which SOAR promises to solve. 

Selecting the Right SOAR Technology

Before we begin, let’s discuss some definitions. These can help you make a better evaluation when approaching SOAR vendors. 

SOAR vendors offer technology integrations. In fact, the O in SOAR refers to the ability of technology to communicate with other technology within the same an environment, allowing you to put the A and R in SOAR. That’s why SOAR vendors often tout how many “integrations they have, or how many different end devices they can communicate. If not that, then they’ll talk about their vendor support, or how many device manufacturers they support, as well as the support they offer for various models and versions under that. 

Integrations are different from the actions. For example, with SOAR technology you can integrate with Palo Alto firewalls. But then the technology may only be able to perform 1, 3, 5, 10 or some small number of actions within that device. A vendor may brag 900 actions, but that could be over 450 devices. Or they might offer 90 devices supported, but that means only 10 actions can be performed. This means that, in reality, even with a high number of integrations, only a couple of actions can be taken for each device. 


Be sure to evaluate the architecture used to perform SOAR. Some SOAR vendors require you to deploy an entire infrastructure that may already run parallel to other infrastructures such as your SIEM. My advice would be to limit architecture where you can. Utilize SOAR capabilities within existing infrastructure, such as your SIEM if it is available. What you gain in orchestration integrations you may lose in repetitive infrastructure and costs for management and maintenance. Neither option is wrong. You should simply make an evaluation in the context of what you need and what you already have.

If you decide to use a service provider for SOAR capabilities, be sure to also evaluate communication and security. Things like tunnels and VPNs, the use of encrypted scripts, and authentication to systems all need to be evaluated as part of the architecture.

Integrations and Orchestration

When doing your evaluation, get a list of all the devices in your environment that you would want to potentially build automation and response with. Then evaluate which vendors support the devices that you already have in your environment. Next, get a list of all the actions they support on those devices and determine if those are the types of responses that you want to take through automation. 

In the mean time, make sure to look out for the next installment of this piece, which will cover automation.



Kevin Prince, Founder and CEO, StratoZen


Security 2020 author Kevin Prince is the founder and CEO of StratoZen, providing managed threat detection, response, and compliance solutions to organizations around the globe. With years of cybersecurity experience under his belt, Kevin is also the former CTO of Compushare (now Finastra) and Perimeter eSecurity (now BAE Systems). Before founding StratoZen, Kevin also founded Red Cliff Solutions, a financial services MSSP and served as a former trainer to FDIC, NCUA and FFIEC auditors.