Beyond static SIEM rules and SOAR playbooks

A model built for a calmer world

The classic SOC stack rests on two ideas. A SIEM collects logs and runs detection rules over them; each rule that matches raises an alert. A SOAR platform then runs playbooks: predefined sequences of enrichment and response steps triggered by alert types. Analysts sit between the two, reading alerts and deciding what to do.

That model assumes a manageable number of data sources, rules that stay correct once written, and situations that repeat closely enough for a fixed script to handle them. None of those assumptions holds well today. Environments change weekly, cloud and SaaS sources multiply, and attackers deliberately behave like administrators.

Problem one: the alert flood

A rule-centric SIEM evaluates each rule on its own. One suspicious sequence on one server can trip a dozen rules, and every match becomes its own alert with its own severity. Routine operations such as backups, software deployment and administrative scripts look a lot like attacker tradecraft and trigger the same rules.

The result is familiar to every analyst: a queue where the same activity appears many times, where most alerts turn out to be legitimate, and where the few that matter are hard to find. Teams respond by raising thresholds or muting rules, which reduces noise and creates blind spots at the same time.

The deeper issue is the unit of work. An alert describes a single observation. An attack is a story across hosts, accounts and time. As long as the alert is the unit, analysts spend their time reassembling stories by hand.

Problem two: brittle playbooks

Playbooks are valuable because they make response repeatable. They are also code, and code that touches many external systems. An API version changes, a field is renamed in an enrichment source, a team reorganises who owns a firewall, and the playbook either fails loudly or, worse, keeps running and does the wrong thing quietly.

Each playbook also encodes one path through one situation. Real incidents branch: the same alert type can mean a misconfigured backup job on one host and an intrusion on another. Covering the branches means more playbooks, and maintaining hundreds of them becomes a job in itself. Many organisations end up with a small set of trusted playbooks and a long tail that nobody dares to run.

Problem three: rule drift and silent blindness

Detection rules are written against specific log fields and formats. When a source is upgraded, a parser changes, or a field is renamed or moved, a rule does not necessarily fail. It keeps running, matches nothing, and reports nothing. From the console it looks like a quiet week.

The same happens when a log source stops sending data, sends it late, or starts sending only part of it. Without a continuous check that each rule still sees the data it was built for, coverage erodes without anyone deciding to remove it. Detection engineering teams know this problem well; few have the time to audit every rule against every source every week.

Problem four: knowledge that walks out of the door

Experienced analysts carry a map of the environment in their heads: which service account always runs that odd script at night, which server legitimately talks to an unusual country, which alert from which rule is always noise. That knowledge is what makes triage fast. It is rarely written down in a form a system can use.

Turnover is high and talent is scarce. ISC2 estimates the global cybersecurity workforce gap at 4.8 million people, and 90% of respondents report skills shortages in their organisations ^[1]. Every departure resets part of the SOC’s learning curve, and every new hire spends months rebuilding it.

Keep the SIEM, change the operating model

None of this means discarding the SIEM or EDR. They remain the best places to collect telemetry and run detections. What changes is what happens next. Instead of feeding a queue that people work through alert by alert, the alert stream feeds a system that reads every alert, ties it to the entity it concerns, builds the story, verifies conclusions against the raw logs and keeps what it learns.

Response changes too. Rather than a script that runs whenever a condition matches, the system prepares a proposal with its evidence, its expected effect and a way to undo it, and a person approves it. Detection content improves the same way: proposed rule changes are tested against your own history and reviewed before anything goes live.

This is the direction ApexAI takes: it works on top of the SIEM and EDR you already run, starting with read-only access, and turns them into a learning operation instead of a growing pile of rules and playbooks. The Why ApexAI page explains the wider context.

Questions