Detection engineering's next decade is graph queries, not rule trees

A typical mid-market SOC maintains 800–2,000 detection rules. The largest enterprises run 8,000–15,000. Every quarter, the detection engineering team adds a few dozen rules for new TTPs, deprecates a few that produce too many false positives, and tunes another hundred or so. The maintenance cost is enormous, the coverage is incomplete, and the rules largely do not compose with each other.

This is the architecture detection engineering has had for twenty years, and it is the architecture we are arguing should be replaced over the next decade. Not "augmented" — replaced — for a specific class of detections that rule engines have always handled badly and that graph queries handle naturally.

This is Setu's argument, made independently of any specific report or commentator. We're going to be specific about what gets replaced, what doesn't, and what the migration looks like.

What rule engines are good at

Atomic, signature-style detections on individual events. "Process X spawned by parent Y with command line containing Z." "Authentication from impossible-travel geography pair within N minutes." "DNS query to known-bad domain." For these, rule engines are exactly the right primitive. The detection logic fits in a few lines, the false positive rate is tractable, and the rule is easy to write, easy to read, easy to test.

We are not arguing that rule engines die. We are arguing that they shrink to their natural scope.

What rule engines are bad at

Detections that depend on the relationship between many events distributed across time and across the identity-permission-asset graph. The canonical example: "An identity that has been dormant for at least 90 days reactivates, then within 24 hours assumes a role granting access to a system tagged crown-jewel."

You can write this as a rule. You will write it as several rules — one to detect dormancy reactivation, one to detect role assumption, one to detect crown-jewel access — and then you will write a correlation rule on top to chain them. The correlation rule will need to maintain state across days. State across days in a rule engine is a lookup table, refreshed periodically, with all the consistency problems lookup tables have.

Then a different detection engineer, six months later, writes a rule for "an identity reactivates from dormancy and within 24 hours initiates a high-volume data download." Same first leg as the first rule, different second leg. The two rules don't share state. The second engineer reimplements dormancy reactivation, with slightly different parameters, in a lookup that is independently maintained.

A year in, you have eight rules that all contain "identity dormancy reactivation" as a leg, each implemented slightly differently, each depending on a separately-maintained lookup. When the dormancy threshold needs to change from 90 days to 60 days based on a tenant-specific tuning, eight rules need to change. They will not all change. The detection coverage drifts.

This is the failure mode of rule engines on graph-shaped detections, and it is the failure mode that justifies a different architecture.

What graph queries do natively

The same detection, expressed against an identity graph with temporally-tracked nodes and edges:

The dormancy detection is a property of the identity node (last_seen_before_present). The role assumption is an edge. The crown-jewel tag is a property of the asset. The temporal join is a constraint on the path. Every primitive used here is reusable across other detections, because the graph is the shared substrate.

When the dormancy threshold changes from 90 days to 60 days, you change one number in one place. Every detection that uses dormancy as a leg picks up the change automatically.

This is not a hypothetical query language. It's Cypher. Production graph databases have supported queries of this shape since 2010. Why hasn't this become the dominant detection-engineering pattern?

Why the migration hasn't happened yet

Three reasons, none of them about the math.

1. The graph didn't exist. SOCs had logs, not graphs. To run a graph query, you first need a graph. Building the graph from raw security telemetry is an entity-resolution and edge-construction problem of significant complexity, and until recently no vendor offered it as a turnkey input to detection engineering. The detection engineers' choice was: write the rule against the event stream you already have, or wait six quarters for the data engineering team to build a graph that may or may not work.

2. The query language was unfamiliar. Cypher and similar graph query languages are foreign to SOC analysts trained on SPL, KQL, and SQL-flavored detection DSLs. The rule engine ecosystem (Splunk ES, Sentinel Analytics Rules, Panther, Elastic Detections) has invested heavily in the ergonomics of writing rules in their native DSL. Graph queries do not have that ecosystem yet.

3. Vendors selling rules don't sell graphs. The detection-engineering tool vendors are largely the SIEM vendors. Their commercial incentive is to make rules easier to write, not to migrate their customers off rules. The argument we are making in this post is structurally hostile to the SIEM business model, which is one reason it tends not to come from SIEM vendors.

We think these reasons explain why the migration hasn't happened yet. We don't think they explain why it won't happen.

What does happen, in our roadmap of the next decade

The migration is gradual, not overnight. Here's the order we expect:

Stage 1 (today): Most detections live in rule engines. A few graph-shaped detections are simulated through correlation rules with poorly-maintained lookups. Detection engineers complain about state management.

Stage 2 (1–3 years): The rule engine and the graph query engine coexist. New graph-shaped detections are written natively as graph queries; existing event-shape detections stay in the rule engine. The two engines share a normalized event source. Some SOCs run both side by side; many run a graph query engine for investigation only, not for detection.

Stage 3 (3–7 years): The graph becomes the primary detection substrate for identity-, asset-, and access-shaped detections. Rule engines retain ownership of atomic event detections and high-throughput streaming detections where graph state is overkill. Detection content marketplaces (Sigma, Detection.fyi, Splunk ES Content Update) start publishing graph queries alongside rules.

Stage 4 (7+ years): Graph queries are the default; rules are the exception. Detection engineers write in graph query languages by default and consider event-engine rules a specialized tool for streaming or low-state cases. The major SIEM vendors have rebuilt their analytics layers to be graph-query-native or have lost meaningful market share to vendors who did.

This is not science fiction. It is the same migration that happened in observability when distributed tracing replaced log-based debugging for any problem that crossed a service boundary. Logs didn't disappear; they shrank to their natural scope. The same will happen with rule-based detection.

Where the current generation of graph-detection vendors are weak

To be honest about the state of play: most vendors offering "graph-based detection" today, including ourselves at certain points in our history, have oversold the maturity of the substrate. Three specific weaknesses are common:

Entity resolution is harder than vendors admit. Building a single coherent identity graph from disparate telemetry sources — Active Directory, Okta, Azure AD, Google Workspace, Snowflake, AWS IAM, Kubernetes RBAC, the dozen SaaS tools each enterprise uses — requires resolving the same human identity across heterogeneous identifier spaces (emails, UPNs, SAML name IDs, Kerberos principals, OAuth subject claims). Every vendor has bugs here. Honest vendors expose the entity-resolution confidence as a first-class property of the graph node so analysts can see when the resolver was uncertain.

Temporal correctness in graphs is a research problem. A graph query that asks "what assets did identity X have access to on date Y" requires the graph to know its own history. Most graph databases retain only current state. Building temporal correctness on top of a current-state graph is non-trivial and many products get it wrong. (Setu's approach is the temporally-unbounded entity registry described in Family XII of our patent portfolio — entity rows persist with monotonic first_seen/last_seen semantics decoupled from event TTL. Other vendors will do this differently. Watch how each handles the question "what did the graph look like on March 15.")

Query latency is real. Graph queries that traverse multiple hops on million-node enterprise graphs can be slow. Without thoughtful indexing and query planning, "show me all paths from any low-privilege identity to any crown-jewel asset" can take minutes or fail altogether. This is engineering, not research, but it is engineering vendors must do honestly. We use a combination of precomputed multi-source diffusion signatures (refreshed nightly) and on-demand per-source recomputation (sub-second) for any node under active investigation. There are other approaches; ask any vendor for the p95 latency on a 4-hop traversal across a million-node graph and watch the answer get vague.

Where graph queries earn their keep, today

Even with the maturity caveats above, there is a class of detection that graph queries already do dramatically better than rule engines, and that any SOC running graph-capable analytics should be running:

1. Permission-path enumeration as a continuous detection. "Show me all paths of length ≤ 4 from any internet-facing identity to any crown-jewel asset." Run continuously; alert on new paths.

2. Dormant-account reactivation correlated with privilege change. "Show me identities that have been dormant for ≥ 60 days, reactivated within the last 24 hours, and within that window assumed a role with elevated permissions." This is the rule-engine pain point above; in a graph it's one query.

3. Service-account permission sprawl. "Show me service accounts whose role memberships span more than one production environment, weighted by frequency-of-use across those environments." Surfaces the structural risk Snowflake and similar breaches exploited.

4. Lateral movement candidate identification post-alert. When an alert fires on identity X, immediately surface the top 5 paths from X to any crown-jewel asset, with weighted exposure score per path. Converts a 30-minute SOC investigation into a 30-second containment decision.

These four patterns are what justify graph-based detection as a product today, not in five years. The rule-engine architecture cannot match them. The migration starts with these and expands from there.

What we are not arguing

Three things this post is explicitly not claiming:

• We are not claiming the rule engine dies. Atomic event detections will live in rule engines forever, and that's correct.
• We are not claiming Setu's graph engine is the only one capable of doing this. Several vendors are building toward the same architectural endpoint. The argument is about the substrate being right, not about who has the best implementation today.
• We are not claiming graph-based detection requires AI or machine learning. The four patterns above use deterministic graph queries with no learned models. ML adds value on top — learning edge weights, learning attention, learning temporal patterns — but the foundation is just well-engineered graph query infrastructure.

Closing

Detection engineering is at the same inflection observability was at fifteen years ago. The dominant primitive (logs / rules) is ill-suited to a class of problems that has become operationally important (distributed traces / graph-shaped attacks). A new primitive (tracing / graph queries) handles those problems naturally but requires the substrate to be built first. The vendors selling the dominant primitive have an incentive to delay the transition, and the new primitive's ecosystem is immature.

Tracing won that argument over a decade, and the SIEM-rule-engine pattern will lose this one over the next decade, for the same reasons. The teams that move first are not the ones who write the most rules. They are the ones who build the substrate that lets the rule count fall over time, replaced by queries that compose, share state, and tune in one place. That migration is the work of the next decade in detection engineering, and it is worth starting on now.