Why We Automate

[bparmely]

“The most dangerous phrase in the language is: We’ve always done it this way.” — Admiral Grace Hopper

You've heard of automation or, at the very least, it has impacted your life — with or without your knowledge. As a security professional, perhaps you even currently write scripts in your language of choice, or have licensed a product that enables automation (i.e., Cortex XSOAR)? Thanks to integrated software solutions such as Application Programming Interfaces (APIs), retrieving and passing information between applications is now easier than ever, and it has propelled businesses forward only to leave competitors behind. However, is automation always the right path for a security operations center? Surprisingly, the question still lingers for many security professionals — why automate?

The 3 Ws of Automation

Why Automate?

Time for a riddle: I can crawl, I can fly, I have hands but no legs or wings either. What am I? The answer is: Time. I'd like to challenge you, as a security professional, to walk through your average work day. Do you find yourself pressing the same buttons in a GUI, or typing the same email responses to end users, or updating the same spreadsheets? If you answered Yes to any of these questions, you would be a prime beneficiary for automation. Here are some of the reasons why automation is growing in popularity:

• Save time by automating easily repeatable and mundane tasks, so you can focus on more important tasks
• Reduce alert fatigue by detecting and responding to threats faster, and separating the true threats from known false positives
• Improve decision making by producing easily repeatable playbooks and tasks, so you can focus on building new use cases
• Start eliminating manual overhead for mundane tasks, which can lead to less room for analyst error

What to Automate?

Let's take a look at some of these examples that correspond with the questions above:

• When you click on a button in a GUI, is the submitted information being used by another process within the same application, or is it passed to a separate application?
• Are you required to follow up with an end user via email; only for this information to be updated in a separate ticket/issue tracking application?
• Does the spreadsheet contain information that is manually updated from another source, such as a threat intelligence feed? What about multiple threat intelligence feeds that are frequently updated at different times?

Is there a correlation between the actions above? You bet. All of these actions are great candidates for automation. However, the question is: should these actions be automated? This is a question that varies between individuals and businesses. Start with a use case definition (UCD) of an incident response process, such as the UCD template provided by Palo Alto Networks, to really understand what an analyst's actions will be from incident creation to incident closure.

Still not sure what should be automated? Here is a general starting point: "Automate the persistent tasks first, then the mundane". Focus on the tasks that are easily repeatable, and then tackle the boring tasks later.

When to Automate?

It might make sense to automate sending a generic email with dynamic data to an end user as part of an incident, but what if data collection is required from the end user, which is then imported into a ticketing application? An end user could be on leave, traveling, or out of office. If a service level agreement (SLA) calls for the incident to be closed within 4 hours, automation will not be able to fix missing user input -- unless we program a proper timed response. 

Mean Time to Detect (MTTD) and Mean Time to Response (MTTR) metrics can be easily disrupted when a script or automation hangs — even worse when no one has knowledge of it hanging. Similar to the what in automation, the when is equally as important and should be determined at the business level. All incident types are not created equally.

To SOAR or Not To SOAR?

Now that we have some ideas of What, Why, and When to automate -- the big question is: How?

And what exactly is SOAR, anyways? This Cortex article — What is SOAR? — provides a good summary, but in short:

Security orchestration, automation and response (SOAR) technology helps coordinate, execute and automate tasks between various people and tools all within a single platform. This allows organizations to not only quickly respond to cybersecurity attacks but also observe, understand and prevent future incidents, thus improving their overall security posture.

What are some alternatives to using a SOAR application? 

Scripts, Custom Content, and In-House Applications

When first starting to look for automation use cases, simple scripts written in a user-friendly language such as Python can be an effective tool in your SOC arsenal. Many online services, such as VirusTotal and Hybrid Analysis, provide free APIs with software development kits (SDKs) supported in multiple languages. Most security products, such as Palo Alto Networks Next Generation Firewalls (NGFWs), also provide an API interface to be able to block malicious indicators or dynamically create firewall rules through the use of automation.

By going down this avenue, there are multiple factors to consider:

• What team(s) will support the application/scripts?
• Are there enough staff members that are fluent in the scripting language?
• Is version control in place if the author(s) leave(s)?
• Is the solution scalable enough to add new use cases seamlessly?
• Are you able to deduplicate incidents and reduce alert fatigue amongst analysts?
• Is training provided for novice analysts to run scripts or use the application UI?

Security and Information Event Management (SIEM) Applications

It's important to differentiate between a SIEM and a SOAR platform, as this question is often brought up when exploring products. Both platforms aggregate event data from various sources. The difference is the action taken in both platforms. When a configured alert fires in a SIEM platform, it's up to the analyst to determine the next path in an investigation. This normally includes pivoting between threat intelligence feeds and other third-party sources to correlate the event data in the SIEM. With a SOAR platform, the investigation path workflows are either fully or semi-automated; beginning incident triage and applying remediation processes – keeping the whole workflow inside a single application. In short, a SOAR platform starts where the capabilities of a SIEM end.

Is your company ready for a SOAR product? You guessed it: it depends. You should be able to confidently answer Yes to the questions below:

• Are incident response processes well defined?
• Has your team set KPIs and goals with clear metrics (MTTR, MTTD, SLA, etc.)?
• Is your team experiencing alert fatigue?
• Is your team consistently performing easily repeatable tasks?
• Has your team mapped incident response processes using diagrams and flowcharts?

Why I Love XSOAR

As a prior security engineer and security analyst, I understand the typical pain points of a SOC environment, as well as the frustrations of a SOC analyst. These are some of the challenges I faced working in a SOC, even with a development background:

• Not being able to deduplicate alerts efficiently, which led to updating and closing identical tickets between multiple applications
• Manual correlation between event data and enrichment data; pivoting between multiple applications
• Lack of coordination between stakeholders in the organization as part of the incident
• Poor communication and missing information during shift turnover meetings
• Most Tier 1 analysis was spent gathering information from threat intelligence sources, which disrupted MTTR metrics

It's truly a breath of fresh air to be able to assist Palo Alto Networks customers with Cortex XSOAR, which solves many of these problems including, but not limited to:

• Pre-processing rules can be put into place to tune out the noisy alerts, so analysts can focus on the bigger threats
• Mirroring integrations allow customers to mirror incidents/tickets/cases from other third-party services, so you can keep your workflow in one application
• The War Room provides a journalistic ChatOps experience like no other, with a dedicated per-incident room that allows for analyst collaboration and command execution to find the incident data that you need
• Using the task-based graphical Playbook workflows with drag-and-drop features will provide a fully-customizable experience for analysts, and provides enough extendable capabilities from novice analysts to threat hunting teams.
• The Marketplace includes over 800+ integrations that support a wide variety of third-party products -- ensuring that you get the most out of your licensed tools

In Summary

Whether you are utilizing command line scripts, or using a full-fledged SOAR platform, automation can produce the results that your business needs to eliminate the mundane and focus on the important tasks. Automation is not; however, a simple band-aid. It’s important to understand the capabilities and limitations of automation in your environment, how you manage to utilize it, and how well you can define your current processes.

“Automation applied to an inefficient operation will magnify the inefficiency.” — Bill Gates