Blog

Rethinking SOAR: Why Automation Needs To Be an Innate Characteristic, Not a Bolted-on Afterthought

SOAR

Automation in security operations and incident response has experienced a renaissance in recent years. This is driven by an escalation in the volume and severity of threat activity, a shortage in cyber security expertise and experts, and the growing adoption of automation by threat actors themselves.

Threat actor median dwell times have fallen¹, giving security teams less time than ever before to proactively detect and contain an active threat, with some ransomware attacks unfolding in less than two days from compromise to data exfiltration and encryption². Adversaries are also increasingly leveraging Evil-SOAR tools to automate attacks, including repurposing legitimate tools, for example, automation frameworks like Puppeteer³. Attacks themselves, in their final stages, can unfold at machine speed when exfiltrating data or encrypting files. This gives human defenders only minutes, perhaps even seconds to react. Manual processes cannot achieve the necessary response speed to rapidly respond to such attacks. And that’s without even factoring in the acute ongoing shortage and high cost of skilled security practitioners.

Add to that the fact that we are only at the beginning of the digital transformation into every aspect of business and society. It is quickly becoming apparent that we can’t solve our twenty-first-century problems with twentieth-century technology.

Reclaiming the O and redefining the A in SOAR

Traditionally in security, automation has been a follow-on action from detection. For example by triggering a response based on a specific alert or event, such as blocking an IP address on a firewall after detecting a service reconnaissance scan. This renders automation as a one-directional and linear process. There are several shortcomings in this approach.

Most detection technologies only have a limited, local view of a single event in isolation, and so coupling automated response to limited visibility and a simplistic understanding of an environment means a high false-positive rate.
Playbooks are used to try and fully encode automation tasks, requiring a high level of prior knowledge and incurring high creation and ongoing maintenance costs. The number of different attack behaviors and compound attack combinators is huge. Most organizations do not have processes mature enough to be fully encoded in an automation playbook.
Having separate solutions for detection and automation means that you are often duplicating and maintaining the same data sources and connectors, in addition to having to keep track and map the relationships between detection and response content.

Most important though, is that automation shouldn’t really be the final, dead-end destination of a digital forensics and incident response (DFIR) process. True orchestration really means optimizing and controlling a workflow, with automation just one of many tasks involved, and security operations just one of multiple stakeholders. We are mistaking automation based on playbooks for orchestration. Requiring a dedicated and customized playbook for each and every conceivable scenario is Automation with a capital A. Lots of effort for marginal gains.

This might have been fine in the pre-cloud world. After all, most security capabilities were sold as dedicated point solutions, so security teams were forced to chain these decoupled technologies together to build a multifunction architecture.

Some vendors have acquired or developed a SOAR product, but sadly none have really gone far enough and taken the last inevitable step – to integrate SOAR capabilities natively into their XDR or SIEM.

These previous SOAR approaches were inefficient though; they either deliver playbooks and bolted-on automation, or they attempt to bolt on another pane of glass. They require duplication of many of the data collectors and third-party connectors, and pose yet another set of logic and content to be configured, but neither fully replaces SIEM or XDR. Both just add complexity.

Yet analytics and automation suffer from being separated. This bifurcation of automation and analytics is at the root of many cybersecurity problems. It’s as though we are detaching the head from the body. What we need instead is automation, with a small a. We need more of it, with less effort.

Fully Integrated Autonomic Security Operations

Our final destination is what Anton Chuvakin at Google calls “Autonomic Security Operations“.

Autonomic* security operations are agile, adaptive, and highly automated.

In our thinking, this requires a seamless blending of human cognition combined with orchestrated autonomous processes, primarily based on feedback loops, to automate typical DFIR processes such as alert investigation and context enrichment. Autonomous processes continuously run in the background, much like unconscious physiological processes such as breathing or walking.

This paradigm change will fundamentally change how we conduct threat detection, threat hunting, incident response, and threat containment. Imagine you took two steps, stopped, breathed, and then had to wait for some external stimulus like a passerby to begin walking again. We would get nowhere fast and constantly be out of breath. That’s where we are now.

But nature has provided us with a far more efficient approach — we decide to walk in a direction, and off we go, breathing throughout, with no effort or thought needed. SOAR capabilities should work like a powered, robotic exoskeleton that enhances the strength, endurance, and speed of the wearer. Another example is continuously variable transmission (CVT). Unlike traditional transmissions that require gears and can only change in fixed steps, CVT supports a continuous range of gear ratios and lets an engine operate at the same revolutions per minute (RPM) regardless of the speed. Many electric vehicles go even further, with a single-speed transmission that is managed by a smart drive selector.

DFIR workflow orchestration will be similar — with automation organically resolving actions, but augmenting and keeping a human in the loop where needed, during the entire lifecycle of security operations.

We need to automate wherever possible and feasible, and we need to automate common tasks and activities out of the box, without having to develop complex playbooks for even the simplest of activities. What we are after is automatability. And for that, we need to break down the barrier between Seeing and Doing, between Detection and Response.

And while we know we’re not going to get there overnight as it will require innovations and advances in a variety of related and interdependent fields and technologies, evolution works in increments so that even small improvements can yield surprising returns on investment.

Just like the first complex life was formed out of the symbiotic relationship between two single-celled organisms after one ingested the other, the first step to making orchestration and automation an organic component of security operations is to eliminate the separation between SIEM and SOAR. Not as a bolted-on capability, but as an innate ability. This allows us to orchestrate DFIR processes where it makes the most sense — the place where we are already detecting, correlating, and analyzing. All of the context and high-quality detections that SOAR requires to be effective are in the SIEM. This also allows us to bake automation and automatability into all of our workflows, resulting in a more organic, ergonomic, and efficient experience, while building the foundation for fully autonomous and autonomic security operations in the future.

Find out more about how a fully integrated SOAR works.

[1] https://cisomag.eccouncil.org/median-dwell-time-fireeye-mandiant/
[2] https://www.bleepingcomputer.com/news/security/fin12-hits-healthcare-with-quick-and-focused-ransomware-attacks/
[3] https://securityboulevard.com/2021/02/what-is-puppeteer-why-developers-and-fraudsters-love-it/
*Deriving From Autonomy – involuntary or unconscious; relating to the autonomic nervous system.