The SOAR Paradox

Introduction

SOAR stands for ‘Security Orchestration Automation and Response’. This is something that normally sits on top of your SIEM (Security Information and Event Management) and acts as an automating layer.

SOARs are great tools and can be very beneficial to security stacks if they are used correctly. In this article, I’ll walk through the common architectural traps that stop organisations getting value from their automation investment.

Why Buy a SOAR?

SOARs are expensive. Depending on your workflow needs, they can cost on average somewhere between £25,000 and £80,000.

SIEMs adopt SOAR capabilities for three main reasons:

• Alert Fatigue: When detection logic fails to suppress noise, SOAR bridges the gap by providing automated resolution for routine cases, directly combating alert fatigue.
• Response Speed: Automation provides a level of speed that human analysts simply cannot match. By triggering automatic remediation the moment an incident occurs, a SOAR ensures that threats are contained in real-time.
• Cost Savings: The initial investment in SOAR is high, but the long term savings are substantial. Correct implementation drastically reduces the time spent on manual investigations, allowing organisations to avoid the high costs of continuous hiring by making their existing analysts significantly more productive.

SOAR Implementation

When you implement a SOAR, you can see the value almost straight away. You can take a threat detection rule, layer automation over the top of it and begin to do some really cool stuff.

For example, you create a really good playbook that looks for C2 callbacks from assets. In this playbook I will be using a threat detection rule (trigger) that identifies repeated, or known malicious outbound connections.

When this playbook is triggered, it gathers information from a range of sources. From there, sub-playbooks run: for example, blocking the IP address on the firewall if it has more than 3 reports on VirusTotal and the domain is less than 30 days old. Another checks the CMDB to determine whether the affected asset is a guest laptop or a production Linux server.

This is a hugely complex playbook, but it works incredibly well to automate response actions.

The Problem

When a SOAR is deployed over a SIEM without a unified data layer, the efficiency gains are largely illusory, because the underlying foundation is fragmented. As your automation library grows, so does the labour required to keep it alive. That’s the SOAR paradox: the more automation you build, the less efficient your operation becomes.

This playbook is great in an isolated environment, but in modern day estates, this does not scale. The SOAR will be looking for a specific trigger, and then looking to extract values from that trigger, using those values to determine the playbook’s next steps.

If the schemas that hold these values are different, then the automation playbook will error out. Meaning you cannot efficiently use the playbook you have just written to detect the exact same behaviour from a different application. This causes you to write multiple playbooks and use up your workflows.

Stand Alone Actions

The fundamental flaw in traditional playbook design is that the trigger, the action, and the outcome are tightly coupled as one stand-alone instance. Because every vendor uses a unique schema, the remediation actions have to match the specific schema of the trigger. That makes the core of the playbook impossible to reuse efficiently. In this model, the only parts you can reliably reuse are the final outcomes, like a Slack notification: the actual logic of the playbook can’t be carried across from one application to another.

Multiple playbooks mean:

• High Costs: Because you can’t efficiently create playbooks, you have to pay for more allocation from the provider.
• Doubled Development: You’re building the same logic twice just to suit different vendors.
• Increased Maintenance: Every environment change requires a change across all related workflows.
• Sub-playbooks: Keeping disparate playbooks in sync is very hard to do.
• Cognitive Load: Analysts have to learn two different workflows for a single outcome.
• Monitoring Fatigue: More moving parts means more points of failure to watch.

This duplication creates an efficiency gap that grows wider with every new tool you add to your stack. Eventually, the cost of maintaining your automation outweighs the time it saves.

Derwent Labs Solution

Before ingestion, a translation needs to take place that normalises logs to a standard schema.

This way, when you want to reference the src_ipaddress for any application, you just call it. It doesn’t matter what the application is or what it is used for: if there is an IP address in the log, it will now always be referred to as src_ipaddress.

This changes things for a SOAR: your playbooks only need to know one schema. You can write a playbook once and deploy it anywhere, regardless of the triggering application.

You stay within your playbook limits because you aren’t nesting playbooks or creating duplicates to do a similar task. If there is a bug, you fix it once and it deploys across your entire playbook estate.

Every action for each new application that is onboarded doesn’t need to be manually translated each time. The framework is already written. We are manipulating the data at ingestion time to make it work for us, not us working for the data.

Final Thoughts

Automation relies on data that is predictable. It just makes everything else easier. If I know that the schema of all my networking logs are going to be the same, then I know that the automation I write off the back of that has a much lower chance of breaking.

Unified schemas have a lot of benefits, and I will be the first to shout about them. Stack the problems of not having them on top of each other, as you do with complex automation workflows, and it snowballs quickly.

We can cut the number of playbooks you are maintaining, save engineering hours, and reduce workflow spend, while building the foundation for proper data sanitisation at the same time. Get in touch if you want to see it on your own data: unifying your schemas will improve your automation.