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 will explore the common architectural traps that prevent organisations from realising the full potential of their automation investment.
Why Buy a SOAR?
SOARs are expensive. Depending on your workflow needs, they can cost on average, in the range of £25,000 — £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 will run — for example, blocking the IP address on the firewall if the IP address had more than 3 reports on VirusTotal and the domain was less than 30 days old. Another would be checking 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, mainly due to the fact that the underlying foundation is fragmented. As your automation library grows, so does the labour required to keep it alive. This leads us to the SOAR paradox — a state where the volume of automation inversely correlates with operational efficiency.
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 outcomes are tightly coupled, stand-alone instances. Because every vendor uses a unique schema, the remediation actions must match the specific schema of the trigger. This makes the core of the playbook impossible to reuse efficiently. In this model, the only replicable components are the final outcomes — like a Slack notification — meaning the complex intelligence of the playbook cannot be directly layered 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, all you need to do is 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 is incredible for a SOAR — your playbooks only need to know one schema. You now have the ability to write once and deploy anywhere, regardless of the triggering application.
You write one playbook to handle malicious outbound connections. It works for AWS. It works for Azure. It works for your on-prem firewalls. If the company buys a new tool tomorrow, you don’t rewrite your playbooks — you just map the new tool to your schema.
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 am going to write off the back of that has a dramatically reduced chance of breaking.
Unified schemas have so many benefits, and I will be the first to shout about them. When you stack the problems of not having them on top of each other — like with complex automation workflows — it just snowballs out of hand.
We know that we will be able to reduce the amount of playbooks you are using. We know that we will be able to save you engineering hours. We can save you money on these workflows and build the foundation of your data sanitisation at the same time. Come and see for yourself — we guarantee we will be able to improve your automation through unification of schemas.