The single most important feature of a Security Orchestration Automation and Response (SOAR) tool is its ability to integrate with other tools and systems. For example, SIEMs, case managers and threat intelligence feeds. The data collected from these external systems builds context. The SOAR tool then uses this context to determine the threat-level and remediation actions required for the alert. In this post, we describe the challenges presented by the pervasive app-based integration model used by the majority of SOAR tools. We also explore how the Tines security automation platform‘s direct integration model tackles these challenges.
App-based integration in SOAR tools
Almost without exception, current SOAR tools rely on an app-based integration model. In this model, the SOAR platform provides pre-built integrations, usually called “apps”, “plugins”, “applets”, “modules”, or “integrations” to interact with the target tool. For example, if you need to perform an Elasticsearch query, you will leverage an Elasticsearch app. If you need to block an IP address on a Juniper firewall you’ll use a Juniper app.
SOAR Tools crayon-problem
App-based integration is problematic for several reasons, including reliance on vendors to keep apps up-to-date. However, the most significant issue is what we call “the crayon problem”. When you buy a box of crayons, you’re restricted to using the colors that come in the box. If you need a color that’s not in the box - too bad. Similarly, if you want to connect your workflows to a specific tool and your legacy SOAR platform doesn’t have a corresponding app - too bad.
This problem is compounded when we consider how quickly the quantity of security tools being used by enterprises is increasing. Cisco recently reported that 41% of organizations are using technologies and services from as many as 50 different vendors. The below image from Momentum Cyber attempts to depict the current state of the cyber security vendor landscape. We’re going to need more crayons!
Cybersecurity tools landscape
Furthermore, if you’re part of a high-demand security team, you’ve likely built many of your own tools. You may also need to automate interaction with bespoke tools created by other teams in your organization. The likelihood of SOAR tools having a dedicated app to support you in these situations is minimal.
SOAR platforms that leverage app-based integration typically try to overcome the crayon problem by providing an SDK that allows you to build your own custom apps. This requires significant software development skills, however, and so a software developer (or the vendor’s professional services team) needs to be engaged.
Tines direct integration
Unlike other SOAR tools, Tines does not rely on pre-built apps to integrate with external systems. Instead, the HTTP Request Action (one of the seven Actions available in Tines) provides direct integration with the target tool. This means consistent integration with any tool, regardless of the vendor, regardless of whether it’s open or closed-source, and regardless of whether it’s commercial off-the-shelf, or custom-built.
*Please note we recently updated our terminology. Our "agents" are now known as "Actions," but some visuals might not reflect this.*