A Practitioner's Guide: Automation within Security Operations

A brief history

Automation within security operations is not new, but what used to consist of clunky bash, batch and PowerShell scripts has evolved into modern day Security Orchestration Automation and Response (SOAR) platforms. The rise of Application Programming Interfaces (APIs) has enabled security operations to automate investigation and response actions. In 2015, we started seeing more and more marketing around SOAR, but it wasn't until roughly 2018 to 2019 that we started to see adoption across security organizations. Phantom and Demisto led the charge. Both platforms were absorbed into major security OEMs (Splunk and Palo Alto respectively). Today, Splunk's SOAR and Palo Alto's XSOAR are the leaders regarding market saturation. Now, a new marketing term has emerged in the security operations automation space: Hyperautomation. More on that later.

Why automation

The goal of any automation is to free up human resources. Security operations is no different. Analysts take the same actions over and over again each and every day. This becomes a monotonous process when dealing with hundreds of detections. Here are the biggest drivers for adopting SOAR/hyperautomation: 

• Efficiency: As mentioned above, instead of performing the same tasks repeatedly, automate those steps and present the results to your responder.
• Consistency: Using defined playbooks forces all responders to use the same process during investigations. This allows us to be uniform in the necessary data sources, metric adoption and note-taking for the incident response team.
• Speed: If responders don't have to open another tab to investigate an alert, time is saved, which allows response actions to be taken faster. We will not always be able to automate everything, but essential enrichment can take a significant amount of time and can generally be automated with ease.

Getting started with security operations automation

If you are already familiar with creating SOAR/hyperautomation playbooks, feel free to skip to the next section.  

How does one get started within security automation and SOAR? Like everything else, one bite at a time. Pick a single problem, break out the underlying pieces, and start finding a way to tackle them. Rereading that sentence makes my brain hurt. Let us use a common security example: Alert/Tipper for a malicious DNS request on a corporate machine.

The nice thing about this and many other automations is that we should, in theory, already have procedural runbooks from which to build automation. What are some things I always do when I, an incident responder, investigate an anomalous DNS request?

• Check threat intelligence for the domain in question
• Research the domain
  • Is it new?
  • Who registered it?
  • How was it registered?
• Gather context around the machine and user
• Investigate the originating process that initiated the request
• Make a malicious / non-malicious determination based on the investigation
• Take containment actions if deemed malicious

I can then create our automation with the following steps:

• Ingest alert (directly via API, SIEM search, or even webhooks in some cases)
• Extract the domain in question for investigation
  • Check VirusTotal
  • Check WhoIS
  • Check enterprise EDR or enterprise logging for similar requests
• Gather context around the user/machine
  • Check identity sources such as Active Directory
  • Check asset inventory sources such as CMDB
• Query EDR for the machine in question relating to the request's originating process data
  • Is this browser-related? If so, do I have access to browser history?
  • Are there any browser extensions installed that may have initiated the request?
• Make the determination. Given all this information, almost instantaneously the analyst has been given a very clear picture of what may be happening, allowing them to take containment action if needed
• Finally, take action
  • Block future DNS requests with this domain
  • Kill the process with EDR
  • Contain the machine using EDR

My last parting wisdom for building playbooks is to build modular or nested playbooks that can be used over and over, given one or two variables. As an example, using our scenario above: We don't want to place multiple subtasks in every single playbook that we create. We will always want to enrich users/machines, IP addresses, hashes, domains, etc. Thus, we create a single DNS enrichment playbook that requires a single input. Anytime that playbook is called, it will always run the VT checks, pull the WhoIS information, etc. Now, any time we need to pull domain information, we simply use that single playbook and nest it within the various future playbooks we create.

What is hyperautomation and how is it different than SOAR?

The term hyperautomation is generally credited to Gartner circa 2020: "Hyperautomation is the combination of multiple machine learning (ML), packaged software and automation tools to deliver work. Hyperautomation refers not only to the breadth of the pallet of tools, but also to all the steps of automation itself (discover, analyze, design, automate, measure, monitor and reassess). Understanding the range of automation mechanisms, how they relate to one another and how they can be combined and coordinated is a major focus for hyperautomation. This trend was kicked off with robotic process automation (RPA). However, RPA alone is not hyperautomation. Hyperautomation requires a combination of tools to help support replicating pieces of where the human is involved in a task." 

Well, that doesn't quite sound like the security operations version of hyperautomation…We must dig further. Within Torq's SOAR is Dead Manifesto, a leading hyperautomation player says "a scalable, cloud-native architecture enables hyperautomation to perform real-time API monitoring and updates, enabling integrations to stay connected even if your third-party API or data format changes, allowing for uninterrupted automation. All of which is tracked within immutable activity audit logs to ensure compliance regulations are met."

According to Torq, the key differentiation is that legacy SOAR is not cloud native. While this is true, traditional SOAR platforms started off as on-prem solutions. It is worth noting that today, many of those traditional SOAR platforms offer a cloud option.

Then, what else are we missing? From the same manifesto: "Hyperautomation analyzes, correlates and organizes unprocessed events from any security solution or third-party threat intelligence. By filtering out the noise and automatically identifying real threats, hyperautomation then creates contextually enriched security cases and intelligently orders them according to severity, priority and subject matter expertise. Cutting through the noise by ingesting disparate data and drilling down to only the events that matter most ensures security analysts can focus on the highest-risk events." 

This is where I see hyperautomation platforms distinguishing themselves. Instead of the classical SOAR automation, step-by-step instructions, hyperautomation takes some liberty with its built-in AI and LLM capabilities to automatically filter some of the standard alert fatigue for security teams. Additionally, Hyperautomation is leaning into its LLM expertise in assisting with incident triage, claiming to automate up to 95 percent of tier-1 tasks. One of my favorite aspects of hyperautomation is the implementation of chatbots that enable responders to understand the alerts they are responding to.

Hyperautomation: Notable OEMs

Torq claims it's the first security hyperautomation platform, also notorious for the "SOAR is Dead" mantra. Marketing aside, their low code, cloud-native platform is incredibly intuitive and supports enormous security customers like MSSPs, proving its scalability. Socrates, Torq's AI chatbot, is sure to capture a lot of SOC analyst hearts, I am sure, offering suggestions and handling cases by itself (when told to do so). Again, AI/ML is showing great promise in this area.

Tines was not originally developed specifically for security operations but has been gaining traction at a rapid pace within the security landscape. Adding Tines Cases, with their own AI-assisted workflows, and generative AI chat interface "Workbench," Tines is quickly being adopted by some of the largest security teams in the world. One cool sidenote, Tines has a community edition that anyone can sign up for, allowing folks to try out the technology. Throwback to the days when Phantom first came out and we were all allowed to have our own playgrounds.

Conclusion

Regardless of the OEM, whether it falls under SOAR or hyperautomation, we should expect the following in adopting a platform:

• Scalable automation and orchestration
• Intuitive case management
• Simple and exhaustive API integrations for security tools

It is imperative to understand each platform's out-of-the-box integrations and how they mesh with your current security ecosystem. Most platforms allow you to build your own integrations if the need arises, but now your team is responsible for the ongoing maintenance of that integration, which simply adds a dependency for every playbook that utilizes the underlying integration.  

We have not discussed case management much here, as it honestly deserves its own blog post. Many OEMs will be able to provide high-level metrics such as MTTR, MTTD, etc. In my personal experience, being able to export critical metadata from your automation platform is immensely useful, as the out-of-the-box metrics may not suit your enterprise needs.

Securing the future: Let our experts guide you

In today's threat landscape, we must have reliable security automation to equip the defenders facing these threats. If you are concerned about protecting against cyber threats or want to learn more about WWT's vision of security automation and the market around it, please contact GSASecOps@wwt.com. We are happy to assist in your cyber journey.