The three things I did by hand on every alert
Building a SOC lab where everything between the rule match and the analyst is automated, because the manual version does not scale and I was tired of it.
Building a SOC lab where everything between the rule match and the analyst is automated, because the manual version does not scale and I was tired of it.
Most of my day as a SOC analyst is judgment. Some of it is not. For a while the not-judgment part went like this, on every alert worth looking at: pull reputation data on the indicator, open a case, ping the channel. Three steps, a few minutes each, dozens of times a shift. None of it required me. All of it sat between the alert firing and me actually deciding anything.
I built the SOC automation lab to delete those three steps. The goal was narrow on purpose. I did not want a system that decides anything. I wanted a system that does the rote work so that by the time I look at a case, the enrichment is already attached and I can spend my attention on the part a machine should not touch.
Telemetry from Windows and Linux endpoints reaches the Wazuh manager through agents. When a rule match clears the severity threshold, a small Python integration posts the alert to a Shuffle webhook. Shuffle pulls VirusTotal and OTX reputation on the indicator, opens a TheHive case with the verdict attached, sets the case severity from the score, and drops a message in the analyst channel.
Everything after the rule match is hands-off. The few seconds it used to take me are now spent by the machine before I ever see the case. When I open TheHive, the reputation is already there.
The interesting question was not how to wire the tools together. It was where to draw the line. Automate too low a severity and you flood TheHive with noise cases and train yourself to ignore them. Automate too high and the automation only fires for things you would have dropped everything for anyway, which defeats the point.
I settled on level 10 and above handing off to Shuffle. Everything below stays in the dashboard where I can sweep it in bulk. That number is not universal. It is right for the rule set and volume of this lab, and if I moved it to a noisier environment I would expect to re-tune it. The lesson I took away is that the threshold is a tuning knob you own, not a default you accept.
The Wazuh default ruleset is a good floor. The cases I most wanted automated were not in it, so they went into local_rules.xml: processes launching from user-writable paths, Office spawning a scripting host, LSASS access with the masks credential tooling uses, new service creation, scheduled-task persistence, SSH and RDP brute force above the default threshold, and outbound connections to indicators from my own CTI watchlist.
That last one is the join I am happiest with. A separate pipeline generates the watchlist, and this lab consumes it, so a connection to a freshly-tracked indicator opens an enriched case automatically. Two projects that were useful alone got more useful wired together.
It is a single-node build, and I am honest about that in the project notes: the Wazuh indexer and TheHive's Cassandra both want real headroom under production load. As a place to prove the pattern and remove the busywork, it does exactly what I built it for. The version of me that opens the next case is grateful to the version that built this.