Security Operations Automation — Making it real

Performing Security Operations automation is somewhat fascinating. Whether you want to automate use-cases end-to-end or supercharge your SOC processes and tooling capabilities, concrete applications of Security Operations automation might leave you mind-blown and provide you great return on investment at the same time.

Introduction

In this blog post, we are going to explore notions valid for at least two types of security operations automation:

• The automation of repetitive tasks, commonly referred to as ‘toil-tasks’ which is part of a larger subject known as Robotic Process Automation;
• The notion of interconnecting independent systems together in order to provide a successful, streamlined output of multiple automated actions, a personal favorite of mine, also known as Orchestration.

Recipe for feasibility

Here are four things you are likely to need:

APIs

Not teaching you anything, today’s applications and systems make most of their data & features available through programming interfaces, known as APIs. Not having API-friendly applications in your system will make things more difficult for you to externally reach for data or trigger actions. Make sure the environment your SOC needs to interact with is made of API-friendly tools.

Webhooks

Webhooks are not mandatory BUT they are a key to success for synchronous automation. In short, a webhook helps receive events performed on an application to an external endpoint almost in real-time.

Not having webhooks will induce performing a ‘did a new event that has value to me occurred’ asynchronous call check, usually triggered by a scheduler. Kind of ‘meh’, but hey, nothing can stop us!

Tools

Not having the right tools will likely make you build everything from scratch with python scripts here and there, which is exactly how I started. The issue here is that the operational success you are looking for will be overshadowed and translated into a technical problem: architecture, scaling, building integrations from scratch, finally fixing that small code portion that was holding you back, etc.

The open-source community has done the job and outstanding tools are now available, such as TheHive’s project and Shuffle’s orchestration platform making that part easier. It’s not just ideal to learn, it is also enterprise-ready and ready to go!

Skills

Ever seen that magical vendor promising a full no-code platform making automation available to all analysts? This is a dream that has not happened yet. It’s a trap! Making machines talk to each other, requires understanding their language, especially when we get to more advanced use-cases. Good programming notions and technical understanding are mandatory.

Avoiding common pitfalls

I made a fair share of mistakes in my early stages of practicing different ways of automation, as early as 2019.

Conditions, be preventive

You want your automations to trigger based on really specific sets of conditions. Avoid performing any kinds of automation on ‘else’ statements at all costs. You are also not safe from a change of an incoming feed’s behavior following a product’s update. Please do implement input validation principles.

Can you imagine the disaster of all those 80 events per minute going through your response action playbook?

As I always say:

When it’s on, it’s on! There is no going back!

Make everything go through the same process

Can’t thank the friend who suggested me that enough (@Guillaume Buffier). When designing automations or orchestration, there’s an entry point to respect and you have to stick to it. This will allow the same conditions to be checked every single time. Moreover, it makes it easier to maintain. Never take a shortcut!

Falling into the technical issue trap

Kind of mentioned it earlier, always assume technical issues keep your eyes off your target: achieving operational success and serving the business.

You will sometimes hit blocking points, that you may end up fixing weeks later and be overconfident that it allows you to run that playbook in production since it was the only thing holding you back: NO!

Make a checklist and always come back to the ‘Why’s‘ of your initiative. Don’t be overconfident and make sure to take time to lift your head up from the track.

Automating actions that.. analysts (or you) do not want to be automated

Some stuff provide pleasure or autonomy to analysts, and getting rid of these may negatively impact the resulting classification of your alerts, their user experience and even the room for imagination at the cost of a slightly quicker triage or analysis process of incidents.

Remember: the purpose of the analyst role is to provide the highest level of analysis quality in the shortest amount of time leading to the most adequate response.

Final words (…for now!?)

There are plenty of security operation automations use-cases that you can explore. Here is a non-exhaustive list :

• Enrichment,
• Enumeration,
• Automated SIEM searches,
• Response actions: notifications, reminders, escalation, containment/recovery actions…,
• ITSM/On-call platform integration in your Incident Management System,
• Threat intelligence ‘management’,
• Fully managed end-to-end alert classification & response actions.

And there is even room for automating processes such as Purple Team assessments or active defense!

Those will be covered in later blog posts, dear tech heroes taking that path, keep in touch!