Automation in Cyber Security: are we ready?

November 11, 2025

After nearly fifteen years of evolving SOCs (Security Operations Centers) and integrating them with multiple tools, as we discussed in a previous post, we’ve faced a number of challenges that we’ve long been trying to solve, chief among them, automation. However, thanks to today’s technological advancements, we’re now closer than ever to implementing automation that can minimize errors or failures in detection and monitoring.

Most lessons learned after an incident response raise questions like: Why wasn’t it detected? Why didn’t anyone see the alert? What was used to monitor that device? Why wasn’t it up to date? How long had that password been in place? Didn’t anyone think to check that IP?

The volume of alerts and false positives is unmanageable, and an overload of irrelevant alerts can overwhelm analysts.

Though the answers vary, they often follow a common logic, typically along the lines of: the number of alerts and false positives is unmanageable, Tier 1 analysts didn’t diligently verify the origin of the connection, that network segment wasn’t being monitored, or simply, no one realized it was part of an attack.

The false positive dilemma

This is precisely the problem that automation aims to address. The idea is for analytics processes and defined workflows to make decisions and take action, notifying the right people and recording everything automatically. However, these systems haven’t always been reliable or effective, so many SOCs still rely on traditional analysis.

That’s changing, thanks to new technologies and system integrations that make it possible to carry out real-time analytics on large volumes of data. Some specialized companies already offer to connect systems to clouds that enrich alerts and enhance detection through advanced analytical systems.

The worlds of Cyber Security and open source have always been closely linked. Today, these communities are coming together once again, particularly around workflow-based automation systems such as n8n.

This opens up a range of possibilities, and the questions raised in lessons-learned meetings may begin to change. One of the main current priorities is to detect alerts or events hidden among false positives, or to enrich alerts with threat intelligence in real time, so that the analyst receives not just an alert, but also relevant data about that IP’s behavior or security profile.

Automation doesn’t replace the analyst, it empowers them.

A few examples

Let’s start with an internal case: an EDR on a file server reports access to the shadow copy directory (Windows backups). This alert is critical because it often means an attacker is removing recovery options before launching a ransomware attack. But it could also just mean the admin is verifying backups.

In a traditional SOC, an analyst would need to spot that alert among dozens of others occurring at the same time. Once found, they’d have to extract the alert data and investigate further to determine if the behavior is legitimate checking, for instance, if the IP belongs to the IT team, or if maintenance was scheduled on that server. With that data, they’d then decide how to respond.

—This could take minutes, or even hours, giving an attacker time to execute the ransomware before the validation is complete.

What used to take hours, systems can now do in seconds.

In an automated process, systems are interconnected, and alerts are automatically enriched with contextual information. So, once the alert is triggered, no matter how many other events are happening, it’s analyzed according to the pre-configured levels, and every piece of alert data is used as a search input in databases or planning systems. Within seconds, the system can determine if the activity was scheduled, and automatically trigger a response, such as blocking access or logging the change in a report.

Now let’s look at an external example: a failed login attempt to admin access on a web service. This alert could result from a user mistake, or it could be part of a brute-force attack targeting an admin account. To determine the root cause, you need to analyze the context.

Here’s the process that should be followed when such an alert is triggered in the SIEM:

Review multiple event sources:
1. Authentication success and failure logs for the service to check frequency.
2. Network authentication logs to see if the user is connecting from the same IP.
3. Firewall and service connection logs to check if the IP has performed any other actions on exposed services.
If the IP is external, the next step is to enrich the associated information:
1. Check the IP reputation across public or private engines.
2. Validate the IP’s geolocation.
3. Look up records of previous actions taken by that IP on the network.
For the user with the failed login:
1. Review login activity for that day to see if the IP matches.
2. Count the number of failed login attempts.
3. Check the last credential change for that account.

With all this information, the next step is to take mitigation actions or report the case as a false positive and close it.

In a traditional SOC, the analyst would need to perform all these steps manually by accessing consoles, gathering logs and reports, and correlating data, something that could take several minutes and depends heavily on the analyst’s skill and available time. And this would only be the first step in assessing the potential risk or threat of the alert.

This whole process can be automated, even incorporating a standardized response based on the analysis. reducing the process to just a few seconds. Actions could include blocking the external IP, forcing a password change for the user, notifying the relevant teams, and generating the case. All within two or three minutes.

The real challenge isn’t automation, it’s doing it effectively and with confidence. That requires preparation, experience, and end-to-end validation.

Sounds easy, but...

As with many things in technology, it looks simple on paper. But implementing it requires preparing the network, the team, and the processes so that automation works in a synchronized and validated way.

This isn’t something that can be rolled out overnight, nor is it meant to replace analysts. Instead, automation should focus on known, repeatable cases, freeing analysts to become investigators of new threat scenarios and anomaly patterns.