Why Is Automation Failing to SOAR?
SOAR
By: Oliver Rochford, Security Evangelist, Securonix
Six years ago, in November 2015, Paul Proctor and I released the original paper introducing the SOAR acronym to the world. What started out as a description for a loose architecture has become a buzzword and a short-lived standalone market that is already devolving into what it was always meant to be — a capability integrated into every security operations technology, whether EDR, XDR, UEBA, or SIEM.
The market definition has evolved since its original conception, with amongst other changes an increased focus on automation, so it was surprising to me when I began speaking to more and more SOAR adopters and hearing that they were not actually automating that much.
Many were automating only small tasks — those primarily relating to incident response and investigation, for example collecting supporting forensic digital evidence from a system that’s triggered an alert or querying a threat intelligence service like VirusTotal for enrichment. Not that this doesn’t add any value. Even minute efficiency savings add up over time. But if that is all that SOAR has to offer, is it really worth investing in yet another technology, especially one that requires the overhead involved in the development and maintenance of content such as playbooks?
The other thing that intrigues me is why so few organizations are automating the containment and blocking of threats. With the skills shortage, the high cost of running 24×7 operations, and machine-speed attacks like ransomware being able to enact the final attack stages in seconds to minutes, why aren’t we automating more?
The Poll
I first wanted to get some more recent and up-to-date data on how organizations are automating, so, I ran an informal poll on LinkedIn* to see if enough of my peers would be kind enough to share what they are doing with automation. 164 security professionals responded:
Figure 1: LinkedIn Poll on Automating Incident Response
Another way of looking at this data is in terms of maturity.
Figure 2: LinkedIn Poll on Automating Incident Response Broken Down by Maturity
Only 16% of respondents stated that their organization is not automating any aspect of incident response, so 84% of the surveyed organizations are automating at least some aspects.
Less than half, only 41%, said that they are automating the blocking of threats in any form, with 32% stating that they blocked selectively.
A related data point I found is from the fantastic SOC Survey that SANS conducts every year. A “lack of automation and orchestration” was the second greatest challenge to “full utilization of their SOC capabilities”, cited by 23 of the 127 participants. The authors also identified automation as the second highest “solution most desperately needed”.
So, what’s going on here? We have a desperate need for automation, so why are users automating so little, even after investing in a solution designed for it?
Automation shouldn’t be driven by manual processes
SOAR solutions provide a few playbooks that are ready to go, but more generally provide a toolbox of automation actions to compose your own. While that’s really powerful and provides a high degree of flexibility, it also means that your security organization is now responsible for developing a growing library of playbooks that need to be maintained and updated or retired.
That may work fine if you only need a few playbooks, but beyond a certain point it becomes a dedicated task. You are managing signatures in your intrusion detection protection system (IDPS) and other detection technologies such as web application firewalls (WAF), correlation rules in your SIEM and now also playbooks in your SOAR.
Who knew that a time saving tool could be so much work?
But joke aside, to automate effectively requires a considerable amount of manual effort. Maintaining dozens of playbooks becomes a job in itself. If you automate the right jobs, that time investment can yield a return — a few actions do most of the heavy day to day lifting, with diminishing returns beyond those. These actions are used again and again, but you need to create many different playbooks that reuse them to cover a variety of scenarios and threats.
We really need the automation to be more, well, automatic, or what Anton Chuvakin at Chronicle describes as “Autonomic Security Operations”. That means embedding dynamic and intelligent automation into the core security operations processes, to create organic and ergonomic workflows and not bolt another roundabout solution on top.
Knowing when to act is fundamentally a detection problem
Automating response is not difficult — we have had that capability for decades, from anti-spam to intrusion prevention systems. Knowing when to automate has been the issue.
When all is said and done, automating the near real-time blocking of attacks, for example by disabling user accounts and blocking device access to other assets, requires a high degree of reliability in correctly detecting threat activity. If the sensitivity for false positives is too high, legitimate activity will be disrupted. If it is too low, too many attacks will still get through, making the automation ineffective.
Reliable detection of malicious behavior, especially in the age of living-off-the-land attacks and cybercrime-as-a-service enabled criminals, entails much more than visibility into only one or two attack vectors. If you want to make containment and blocking autonomous, you need visibility across several layers and channels to be able to analyze behavior and to model threats. You need more than detection — you need analytics.
Automating for autonomous actions requires deep knowledge
SOAR solutions provide a few playbooks that are ready to go, but really offer a large toolbox of different building blocks — 3rd party integrations, alert parsers, event triggers — to compose your own. While knowing when to initiate automation requires reliable detection, knowing what to do about a threat and how to do it — essentially codifying a threat’s tactics, techniques and procedures (TTPs) and how it behaves — requires deep expertise and knowledge.
As threat actors frequently evolve and adapt as well, this knowledge and expertise has to continuously and often urgently be recodified.
Automation can’t live in a silo
Even if you have enough time, money, and expertise to develop and maintain dozens or even hundreds of playbooks, your SOAR solution is now another separate pane of glass with its own set of connectors, collectors, and threat-oriented content. It’s like another half-SIEM with all of the management overhead. We are creating a silo within a workflow that suffers from context-switching. More importantly though, automation must be intimately tied to analytics.
A good analogy is that we are architecting two brain halves, one specialized on automation, and one on analytics, but with only a weak corpus callosum to connect the two halves and deliver messages from one half of the brain to the other. The connection between the two halves needs to be much stronger, and with multiple paths. Instead, we have lobotomized security operations.
Automation is an outcome of the sum being greater than the parts
What is required instead is a much more symbiotic approach, where automation is a natural part and extension of the security operations tooling. We need SOAR and SIEM to be organically integrated and to share the same underlying data.
We can call it SIEMDR, XSIEM, SIEMX or even SIEMXDR, but what end users already need and will increasingly seek out, will be a much tighter fusion between security analytics and automation.
How machine learning can identify nation-state attacks.
Securonix 2024. All Rights Reserved Legal Center | Privacy Policy
