A Pattern I Have Seen Everywhere
Across years of working in Security Operations Centres — different organisations, different people, different processes, different budgets — one technical gap has shown up consistently, in almost every environment I have worked in or observed.
Analysts investigating security alerts, and engineers fine-tuning detection rules, rarely look at the objective of the rule involved.
Not the raw code. Not the threshold logic. The objective — what the rule was actually built to detect, what specific threat or behaviour it was designed to surface, and what risk it was meant to cover.
This gap quietly degrades two of the most critical activities in any SOC: Investigation quality and detection accuracy. And in most organisations, nobody has formally addressed either one.
Gap 1 — Investigation Without Knowing the Purpose
When an alert fires, an analyst opens it, reviews the event data, checks a few fields, and makes a call. The detection rule that generated the alert — its intent, its thresholds, its allowlists, what it considers suspicious versus normal — is rarely read first.
The result is that the analyst is trying to solve a problem without knowing the actual reason behind it.
The same event can be a true positive or a completely benign activity depending entirely on what the rule was designed to detect. Without that context, the analyst is partially guessing — filling the gap with instinct rather than informed judgement.
Over time this leads to inconsistent verdicts, missed true positives, and excessive false positive rates — not because analysts lack skill, but because they are missing the most important piece of context before they even start.
Gap 2 — Fine-Tuning Without Knowing What Good Looks Like
The second gap is arguably more damaging because its effects are permanent.
When a detection rule generates noise, the natural response is to tune it — add an exclusion, raise a threshold, narrow a condition. The noise reduces. The alert count drops. The work feels done.
But if the engineer tuning the rule does not know its original objective, they are trying to make something perfect without knowing what perfect is supposed to look like.
An exclusion added to reduce noise might silently create a blind spot in exactly the scenario the rule was built to catch. A threshold raised for comfort might mean the rule now misses the very attack pattern it was designed to surface.
The rule drifts. The intent lives in someone's head or an old ticket nobody reads. The detection control that was once sharp becomes blunt — quietly, with no alarms going off.
The Fix — Objective-Anchored Detection
The principle is simple: The rule's objective is the single source of truth, from the day it is created through every tuning decision and false positive review it will ever go through.
For investigation: Before looking at alert data, read the rule's objective. Understand what threat it was built to surface and what conditions it considers suspicious versus expected. Then correlate the specific alert against that intent. This is the difference between informed triage and educated guessing.
For detection engineering: Define the objective before writing a single line of rule code. Make it precise — not "detect suspicious admin activity" but "detect non-allowlisted identities performing bulk deletion on sensitive storage buckets in production". Vague objectives produce vague rules and vague verdicts.
Once the objective is set, it does not change. Everything else is implementation.
For false positive reviews: Every FP must be evaluated against the objective. If the alert matches what the rule was designed to detect, it is not a false positive — it is a true positive on a low-risk event, and the response is context, not a rule change. If the alert does not match the objective, it is a genuine false positive — and the tuning must move the rule closer to its objective, never away from it.
Where We Are
We have already deployed AI-assisted alert investigation to address the investigation gap — giving AI rule context, intent, and objective alongside every alert before it make a verdict. The results have been a meaningful improvement in both consistency and confidence of triage decisions.
We have now started building the detection engineering side — an AI-assisted workflow where the rule objective is mandatory before any code or query is written, and every tuning or review decision is validated against that objective by AI. The AI does not replace engineer judgment, it enforces the discipline that engineers know they should apply but often cannot sustain consistently under volume.
Together these close a loop that most SOCs have left open: Rules built with clear objectives, alerts investigated in the context of those objectives, and tuning decisions that always pull the rule toward its intent rather than quietly away from it.
A Simple Test
Ask your analysts: Without opening the rule, can you tell me what specific threat this detection was built to surface?
If the answer is uncertain for most alerts — the gap exists in your SOC too.
The fix does not require new tools. It requires making the rule objective the first thing an analyst reads before investigating, and the first thing an engineer defines before building.
Everything else follows from that.
Views are my own. Written from personal experience across multiple security
operations environments.
Top comments (1)
I've seen this gap in many SOCs I've worked with, and I think the key to addressing it is not just documenting the objective of each rule, but also making that information easily accessible to analysts and engineers. One potential solution could be to integrate the rule objective into the alert itself, so that analysts have all the context they need right from the start. I'd love to hear more about how you're implementing objective-anchored detection in your own SOC - are you using any specific tools or platforms to support this approach?