Detection engineering is moving from rules to contextual findings

At a glance

What this is: This is an analysis of how detection engineering is moving from brittle, rule-heavy SIEM logic toward layered signal aggregation and contextual findings.

Why it matters: It matters because SOC teams are spending too much time suppressing noise, and the real control question is which telemetry should be escalated into a trusted finding.

Context

Detection engineering is the process of turning logs, behavioral signals, and threat logic into actionable alerts. The article argues that traditional SIEM patterns are buckling because environments are larger, more dynamic, and harder to model with static rules alone, especially when identity context now spans human users, service accounts, and machine activity across SaaS and cloud.

The governance gap is not simply alert volume. It is the lack of a reliable way to separate noisy anomalies from meaningful findings without forcing analysts to hand-tune every rule. Where identity and access signals are part of the data mix, the quality of detection now depends on whether the platform can distinguish normal from suspicious use of users, accounts, and sessions at scale.

Key questions

Q: What breaks when SIEM detections rely on static rules alone?

A: Static rules break when the environment changes faster than the rule set can be rewritten. The result is noise, brittle coverage, and constant tuning debt, which pushes teams to disable useful detections or drown analysts in false positives. The practical failure is not only missed threats, but also loss of trust in the detection queue.

Q: Why do contextual findings reduce SOC noise more effectively than more rules?

A: Contextual findings reduce noise because they evaluate signals together with user, system, and historical context before escalation. That means a weak anomaly does not automatically become an alert, and a suspicious pattern can still survive if the surrounding evidence supports it. The control value is better precision, not simply fewer detections.

Q: How should security teams measure whether detection rules are actually working?

A: They should measure whether the rules fire against live samples, replayed telemetry, and known behavioural sequences. A rule that has only been written and deployed is not validated. Proof comes from repeatable matches against the events it was designed to catch, not from confidence in the description.

Q: What should SOC leaders do when alert volume forces them to disable detections?

A: They should treat disabling detections as a governance failure, not a tuning preference. The next step is to separate raw signal generation from final escalation, preserve low-fidelity telemetry for hunting, and add contextual enrichment so the queue reflects evidence quality rather than noise tolerance. That protects coverage without asking analysts to absorb everything.

Technical breakdown

Why rule-based SIEM detections become brittle

Rule-based detection works when the event pattern is stable and the environment changes slowly. In modern SOCs, that assumption breaks quickly because cloud, SaaS, IdPs, and remote work produce constantly shifting baselines. A rule that once matched a clear malicious sequence can become noisy when business processes, network paths, or user behaviour change. That forces analysts to keep rewriting correlations, suppressing benign activity, or disabling detections altogether, which reduces coverage and weakens confidence in the queue.

Practical implication: detection engineering should be treated as a governed lifecycle, not a one-time rule authoring exercise.

How signal aggregation changes detection fidelity

The article’s key architectural shift is from single alerts to signals that are then aggregated into detections and findings. A signal is a lower-confidence indicator, such as an anomaly in ASN, frequency, location, or action pattern. When multiple signals occur in the same session or time window, the system can weigh them together instead of treating each as an isolated alert. That reduces the chance that one benign outlier drives an analyst investigation while still preserving the suspicious pattern for later enrichment.

Practical implication: teams should judge detection quality by how well the platform correlates weak signals into a defensible investigation path.

Why contextual enrichment matters for identity-aware findings

Contextual enrichment is what separates an interesting anomaly from an actionable finding. The article shows that the same signal can mean different things depending on user history, peer behaviour, system configuration, and related alerts. That is especially important for identity-linked activity, because a login from a new ASN, an unusual file action, or an unexpected access pattern may be normal for one user, risky for another, and irrelevant for a third. Context therefore becomes the control layer that prevents false positives from dominating SOC workflows.

Practical implication: detection logic should incorporate user, account, and session context before an alert is promoted to analyst review.

Threat narrative

Attacker objective: The objective is to perform suspicious activity without triggering effective analyst attention until the behaviour has blended into noisy operational telemetry.

1. Entry begins with suspicious or unusual activity appearing in telemetry, such as an unfamiliar ASN or a sensitive file action inside a user session.
2. Credential or account context then determines whether the behaviour is benign or suspicious, because the same identity can operate from multiple legitimate environments.
3. Escalation occurs when several weak indicators align within the same session and are promoted into a higher-confidence detection.
4. Impact is the SOC’s ability to focus on true positives while preserving lower-confidence signals for threat hunting and forensic review.

Breaches seen in the wild

• Twilio 0ktapus breach 2022: SMS phishing of employees exposed 209 Twilio customers and 1,900 Signal users, part of the 0ktapus campaign against 130+ firms.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Context is becoming the real detection control: static rule matching is no longer enough when the same activity can be benign in one identity context and suspicious in another. The article shows that signal quality now depends on whether the SOC can enrich telemetry with user, account, and system context before escalation. That is a detection governance problem, not just a tooling problem. Practitioners should treat contextual enrichment as part of the control stack, not as an analyst convenience.

Detection engineering is moving from alert writing to evidence curation: the useful unit is no longer the individual rule, but the chain of signals that survives contextual review. That changes the operating model for SOC teams because engineering effort shifts away from suppressing false positives and toward defining what evidence should count as a finding. In identity-heavy environments, this directly affects how access, user behaviour, and session anomalies are handled. Practitioners should design for evidence aggregation rather than standalone alert volume.

Noise tolerance is now a design choice, not an operational accident: if a platform cannot absorb low-fidelity anomalies and resolve them later, teams end up disabling detections or over-tuning them. The article’s model suggests that modern SOCs need a layer that can separate weak but useful signals from operational chatter without losing visibility. That is especially relevant where human and non-human identities both generate telemetry. Practitioners should demand detection architectures that can carry noisy identity-adjacent signals forward safely.

Machine and human identity context are converging in SOC logic: the article’s references to baselines by user type, account type, and system context show that detection models increasingly rely on identity-aware segmentation. That matters because service accounts, admins, and ordinary users do not share the same behavioural expectations. Security teams should stop assuming one detection baseline fits all identity classes and instead build findings logic around role, peer group, and usage context.

Contextual findings are the new governance surface for SIEM: the control question is not how many detections exist, but whether the right activity becomes a trusted finding at the right time. That shifts accountability toward the integrity of enrichment, correlation, and historical baselining. The article points to a future where the SOC is judged by its ability to convert telemetry into defensible conclusions. Practitioners should focus on finding quality, not alert count.

What this signals

Detection quality is shifting upstream: SOC teams can no longer rely on the analyst queue to sort out bad alerts after the fact. The control point is now the enrichment and correlation layer, where user, account, and system context determines whether a signal becomes a finding or remains background noise.

Identity-aware baselines will matter more than generic anomaly thresholds: a detection model that treats admins, ordinary users, and machine accounts the same will keep producing ambiguous results. Teams should expect future SOC design to segment baselines by identity class and behaviour, because that is where the difference between signal and noise is increasingly decided.

For practitioners

• Audit detections for tuning debt Inventory which SIEM rules, baselines, and correlations require constant manual adjustment, then classify which ones are generating noise, which ones are silently disabled, and which ones still provide unique coverage.
• Introduce context before escalation Require user, account, peer group, system, and session context to be evaluated before lower-confidence anomalies are promoted to the analyst queue.
• Separate noisy signals from true findings Keep weak indicators available for hunting and forensic review, but prevent them from overwhelming the primary triage queue unless multiple signals converge.
• Tune by identity class and behaviour Use different baselines for admins, ordinary users, and machine or service accounts so detections reflect how each identity class actually behaves.
• Measure the reduction in false-positive drag Track how often detections are disabled, suppressed, or manually rewritten, then use that trend to decide where contextual enrichment should replace static correlation.

Key takeaways

• Static SIEM logic is struggling because modern environments change faster than handcrafted rules can be maintained.
• The article’s model reduces noise by aggregating weak signals and adding context before analysts ever see the finding.
• For practitioners, the key shift is from tuning every alert to governing which evidence deserves escalation.

Key terms

• Detection Engineering: The discipline of designing, testing, and maintaining detection logic so it remains useful against real attacker behaviour. It covers telemetry selection, rule quality, false-positive management, and the operational workflow needed to keep alerts actionable.
• Contextualised finding: A contextualised finding is a security issue enriched with reachability, ownership, and business or runtime context. That context turns a raw detection into something a practitioner can rank, assign, and remediate without guessing whether the issue is real or exploitable.
• Signal aggregation: Signal aggregation combines multiple weak indicators into a stronger finding by correlating them over time, session scope, or shared context. It is useful when no single alert is decisive, but the pattern becomes meaningful when the pieces are evaluated together.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, machine identity security, and secrets management, through the industry's only accredited NHI security programme. It helps security and identity practitioners translate governance intent into operational controls across hybrid environments.