Selecting Use Cases for Automation (Part 1)

This entry marks the beginning of a new blog series, designed to offer experience-based best practices for approaching SOC Automation.

“Begin at the beginning,” the King said, very gravely, “and go on till you come to the end: then stop.”
―Lewis Carroll, Alice in Wonderland

The Beginning

Getting started with security automation begins with having the right objectives and goals in place. One of the keys to success is identifying the right use cases, complete with a prioritized roadmap of implementation and measurement. This article starts you on the journey, providing guidance for developing those use cases.

Many organizations look to security automation and orchestration platforms to help with their ever increasing numbers of events and data that land on the consoles of our security analysts. The promised nirvana of removing the manual, repeated, and arduous tasks of validating (triage), assessing risk (escalation) and taking action (response) on events in a smarter, faster, and stronger manner is easily achievable. All with the core tenants of good operational discipline and delivering repeatable, predictable, and reliable responses.

But with everything, we have to able to start at the right place, making the right decisions. We’ve seen many security projects fail since they didn’t follow the core tenants of any good implementation which are:

• Smart People
• Smart Planning
• Open Communications
• Careful Risk Management
• Project Closure

Source: Five Factors That Lead to Successful Projects by Erin Palmer

First, I’m going to take a leap of faith and assume that you have the Smart People (your subject matter experts in security operations, your infrastructure and technology platform, and your business strategy drivers) already engaged. If not, start bringing them together. Nothing is going to work if you don’t have the right people involved from inception.

Use Case Development

Next, we are going to dive into the world of use case development. To get started with use cases, consider the type of automation you envisaged when you started your security automation and orchestration journey.

Yes, there are different basic automation approaches.

Enrichment

The first one that I like to explore is one that augmented automated security operations supports. This is where most people start. They look at all of those alerts being generated and realize that the team is, or should be, performing the same steps for pre-processing an alert before it hits the console. It could be as simple as moving from one technology to another (e.g. email being converted into a ticket).

Or they could dream of realizing the dream of automated enrichment by taking the data inside the triggering alert and enriching it (Yes, I’m challenging you to dream big!). All those steps of validating an IP address against multiple sources, searching your environment for signs of infiltration, and presenting all of that, all preprocessed and normalized to the security analyst upon his or her first look.

Threat Hunting

Another approach that we have seen is that the mechanism of supporting hunting. A threat intelligence or incident responder could investigate an incident and end up with hundreds of IPs, file hashes, and domains. Now they want to find the interesting ones  and remove the false positives. In the past, that required writing a script to look up against a source and then process the results manually (usually in a spreadsheet—“oh the humanity”).  Now imagine if the analyst could pass that to a tool that retrieves all that data, normalizes and then returns all the data (yes, I know Incident Responder types like to work with raw data).

Automated Assessment and Response

Yes, now the nirvana scenario—where thousands of alerts come in, are automatically processed, and the appropriate actions are taken.  Now, notice that I said “the appropriate actions are taken.” I didn’t say “automatically responds by blocking.” It’s time to shatter that dream. We are seeing that there’s still a need to have human intervention. In a mature security organization, we have seen our platform automatically responding to 99% of alerts, but there are always cases that will need a human brain’s ability to assess the abstract; that is, human decision making. You will never have a 100% automated response. That’s the same as saying that security technology will detect 100% of all attacks. Dream on!

There are other automation scenarios but for the moment, I want you to just consider the above strategies.

In part two of this article, we will explore how to build process around your selected use cases.

----------------------------------------------------
Thanks!
Paul Davis