Cybersecurity Automation: What to Automate First

Ask a security team what they’d like to automate and you usually get one of two answers: “everything”, or “nothing, we don’t trust it”. Both are wrong, and I think the real answer is simpler than it looks. Automate the boring stuff that’s easy to undo.

Nobody can read 47,000 alerts

There’s a scenario I use in the first week of my course. It’s Saturday morning at a regional bank and the junior analyst on the weekend shift opens the queue: 47,000 alerts since midnight. Somewhere in there are three real incidents: a compromised supplier account, a phishing campaign against the finance team, and a cloud storage bucket that has been leaking customer data since the night before.

A good analyst can properly look at maybe 200 alerts in a shift. So in the story the phishing gets caught mid-morning, the supplier account around lunch, and the leak? An outside researcher reports it on Monday. 58 hours later.

Nobody did a bad job there, it’s just maths. And attackers are quick. In a typical account takeover they can go from the first odd login to pulling files in a few minutes, while checking one suspicious address by hand takes a few minutes on its own.

The boring stuff is exactly what you should automate

The tasks worth automating have three things in common. They happen dozens or hundreds of times a day, they follow clear rules, and if the script gets it wrong you can fix it in a minute.

For most teams the first candidate is enrichment, looking up an IP address or a domain in threat intelligence sources. An analyst spends minutes on each one. A short Python script does it in seconds and doesn’t get bored at 3 AM.

After that I’d look at log parsing (turning messy log lines into something structured and throwing away the obvious noise) and at correlation, so that a failed login, a new mailbox forwarding rule and a big download show up as one story and not as three separate alerts in three different tools. Opening tickets and attaching evidence is boring too, which is exactly why a machine should do it.

Anything you can’t undo stays with a human

Before I moved into IT I worked as an air traffic controller, and one thing that job teaches you is respect for actions you can’t take back. Security response is similar. Blocking a known bad IP address is fine – you can unblock it a minute later. Taking a production database offline is a very different decision.

So before automating any response, I ask my colleagues four questions. How sure are we that this is actually malicious? How serious is it? How important is the system? And can we undo it?

The honest answer usually lands somewhere in the middle. Disabling an account or isolating a laptop is too disruptive to happen completely on its own, but too urgent to wait while someone does all the legwork by hand. Here the script does the preparation, gathers the evidence and proposes the action, and a person approves it with one click. You keep the speed and someone is still accountable.

The really big calls like shutting down production, getting legal involved, saying anything in public stay with people. Full stop.

How automation goes wrong

A badly tuned playbook can take a business down faster than the attacker would. One example I like to use: a rule that automatically isolates every computer that talks to a suspicious domain. Sounds sensible. Then a developer’s test domain ends up on the blocklist by mistake, and suddenly the whole dev team is offline, because the rule never checked whether those were known test machines.

The other mistakes are less dramatic but more common. Scripts that fail silently, so you think you’re covered and you’re not. Passwords pasted straight into the code, which is fine right up until someone shares the file.

And (this is the big one) workflows that nobody owns. Automation rarely dies because a tool breaks. It dies because the person who wrote it moved on, and nobody noticed that it slowly stopped matching the systems around it.