At Tines, we believe that one of the most important factors of a Security Orchestration Automation and Response [SOAR] solution is its ability to integrate with other software easily. It’s critical for the successful handling of security operations that every part of the system can communicate effectively, from threat detection to incident resolution.
Most integrations are designed to solve a particular problem and minimize your need for new tools as your organization scales. They’re intended to boost your system’s overall functionality, often by providing extra features you may need but cannot build within your software.
A truly effective SOAR platform is only as strong as its weakest link - that means if it’s not compatible with all the tools in your tech stack, or can’t perform a desired action in that tool, then it might not work at full capability when a cyberattack hits close to home.
But integrating technologies and systems isn’t easy. Trying to force a rigid, brittle solution into a complex problem presents a considerable challenge for Security and IT teams.
Traditional SOAR platforms typically rely on “app-based integration” models. Each ‘application’ is essentially a wrapper for the tool’s API and exposes a small subset of the features and actions available in that tool.
Unless your vendor of choice has already built the specific integration you require, these types of connections can take a lot of time and effort to develop and maintain. If you need to perform an EDR query, you’ll have to leverage the EDR application. If you need to block an IP address on a firewall, you’ll need to use the firewall’s module. When you want to build a unique integration, like connecting to an internal tool or a niche API, it often requires reinventing the wheel and asking your security engineering team to code an integration, or worse, asking the vendor themselves to build one, which can be very expensive, time-consuming and complicated.
Even if you’re successful, you may still run into problems down the line, as whenever your environment changes or your vendor’s API changes, your integrations will need updating. If you’re unable to keep up with these changes, prepare for your tools to become obsolete and your automation playbooks to break.
These integrations can also be:
Restrictive: You’re limited to the generic actions offered by your SOAR platform, which aren’t tailored for your processes.
Dependent: When a new feature or API endpoint is released, you’re reliant on your SOAR vendor to keep apps up to date and provide access to older versions.
Rigid: Homegrown tools and anything but the most common features of mainstream security products won’t have a functional integration available.
Inaccessible: When applications aren’t available, SOAR platforms provide a Software Development Kit, which requires an experienced developer or professional services to build.
Whenever a potential customer asks our sales team, ‘Does Tines integrate with X?’ we see it as an opportunity. More often than not, they want to understand whether Tines will fit all of the use cases they have. Basically, will it work, or will it suck?
When it comes to integrations, Tines is the antithesis of other SOAR platforms. Being API-centric, we often say we support infinite integrations but maybe a better way to slice it would be to say that Tines has zero integrations because they’re simply unnecessary.
‘Do we integrate with X?’ The simple answer is 'yes.' The comprehensive answer is 'yes, but you don’t actually need an integration because the HTTP Request Action allows Tines to talk to third-party tools.'
No one needs to waste time building complex wrappers; Tines can connect to any tool or web application with an HTTP API in minutes, supporting both REST API and non-RESTful API endpoints. ‘REST API’ is somewhat ironic since most tools today are constantly evolving; that’s the beauty of having an automation platform that can readily connect with any infrastructure and avoid tech bottlenecks. It also doesn’t matter if the tool is off-the-shelf or something you’ve custom-built. For example, you can go to Jira’s API docs, find a cURL command, and paste it directly into Tines. We are not building an integration here; we’re just connecting. Essentially, it’s a template. If there is a way to connect with a tool’s API, Tines will be able to do it.
Thanks to this level of flexibility, we don’t offer or aspire to add features like case management or chat because organizations shouldn’t have to compromise when it comes to functionality. When you try to do everything, you tend not to do anything very well most of the time. This is one of the main reasons we’re committed to doing one thing really well; best-of-breed automation that supports other best-of-breed software. You can write alerts in your SIEM, perform analysis in your CMS, notify relevant stakeholders via Slack or email, and do it all automatically via Tines without being highly technical or needing to rely on a developer.
The key for us is providing a powerful tool that’s adaptable so our customers can automate mission-critical workflows faster and in a better way.
Is there a downside to connecting directly to APIs? Looking up their documentation and filling in the blanks can be a little tedious at times. But, we have a solution! Tines offers 1000s of preconfigured Action templates for everyday interactions with a wide range of tools, e.g., Jira, Slack, Splunk, CrowdStrike, etc. Using these templates means you don’t need to leave your Tines Story to connect with these tools.
Suppose a template doesn’t yet exist for your tool of choice. In that case, you can paste cURL commands to the Storyboard, and you’ll get a Tines Action created immediately, like that Jira example we gave above. This feature is a recent addition and should make it much easier to use any documentation that features cURL and kickstart utilizing those API calls within Tines.
Ready to experience automation without having to build integrations? Get started with our free Community Edition.