What breaks when detections are built only around data sources?

What a Source-Centric Detection Model Misses

When detections are built around data sources instead of attacker behaviour, the programme often optimises for inventory rather than coverage. Teams can say they monitor endpoints, identity logs, email, or cloud events, yet still fail to describe the actions an adversary must take to move from initial access to execution, credential access, or persistence. That gap matters because detection logic has to prove or disprove behaviour, not merely confirm that telemetry exists. NIST Cybersecurity Framework 2.0 is useful here because it emphasises outcomes and governance rather than treating tooling lists as the control objective.

Source-first design also hides an operational weakness: analysts may receive many alerts from a source without enough context to connect them into a credible intrusion sequence. In practice, many security teams discover this only after a real investigation shows that apparently broad telemetry was never assembled into behaviour-driven detections.

How Behaviour-Based Detections Change the Telemetry Question

A more reliable approach starts with the adversary action, then asks which telemetry can confirm or refute it. For example, a detection for credential access should be framed around the observable chain, such as suspicious authentication patterns, privilege use, token abuse, or unusual access to sensitive resources. The point is not to collect every available log source, but to make sure the sources together can support an analyst decision. If the telemetry cannot distinguish normal administrative activity from abuse, the detection may be noisy but still incomplete.

This is where source-centric programmes usually break down: they confuse availability of logs with evidential sufficiency. A useful detection must answer three questions at once: what happened, which entity did it, and whether the behaviour matches a known tactic or abuse path. If any of those answers is missing, the alert may be descriptive but not actionable.

Operationally, teams should map each detection to a behaviour, then validate whether the relevant logs cover initiation, escalation, and persistence signals. The same source can support multiple detections, but one source rarely covers the whole lifecycle by itself. Good telemetry design therefore links sources, correlations, and decision logic instead of treating them as separate checkboxes.

• Define the behaviour first, then confirm which telemetry can evidence it.
• Check whether the signals can be correlated across identity, endpoint, and cloud paths.
• Validate whether the data can distinguish misuse from routine admin activity.
• Treat source presence as a starting point, not proof of detection coverage.

Where this guidance breaks down is in environments where the relevant activity is genuinely unobservable or where the organisation lacks the authority to collect the signals needed for correlation.

When Source Lists Create a False Sense of Coverage

Tighter telemetry standards often increase engineering and review overhead, requiring organisations to balance broader collection against the cost of maintaining useful detections. That tradeoff becomes visible in edge cases such as shared accounts, heavily automated service traffic, or cloud-native workloads where many events are technically recorded but few are analytically distinct. In those settings, a source list can look comprehensive while still failing to answer basic investigative questions.

There is also a governance distinction that matters. Teams sometimes assume that because a platform emits a log, the control is working. That is a consensus mistake, not a settled best practice. Logging and detection are different capabilities: one provides raw material, the other transforms it into evidence. If the organisation only measures whether the source exists, it can miss whether the correlation logic actually detects the abuse paths it claims to cover.

For that reason, source-centric programmes tend to underperform most when the environment changes quickly. New identity paths, SaaS integrations, or automation layers can introduce activity that is logged but not interpreted correctly. The practical answer is to test detections against attacker behaviour and investigative questions, not against source inventories alone.

Practitioner Guidance

What to prioritise: Start by naming the behaviours that matter most to your environment, then verify that each one has enough telemetry to support a defensible analyst decision. If a detection cannot distinguish compromise from routine activity, treat it as incomplete even if the source is present.

What to verify: Confirm that your most important detections can be correlated across at least one initiating signal and one confirming signal. The useful test is whether an analyst can explain why the alert fired and what it means operationally, not whether a source name appears on a coverage matrix.

Common mistake: Do not equate breadth of logging with breadth of detection. A larger source list often increases reporting confidence faster than it improves security value, especially when the team has not validated which signals actually answer investigative questions.

Practitioner takeaway: Detection engineering should be judged by behavioural explainability and evidential sufficiency, because a telemetry catalogue without attacker logic is coverage theatre rather than operational defence.

Related resources from NHI Mgmt Group

• What breaks when detections are built around vendor coverage instead of attacker behaviour?
• What breaks when DLP policies are built only around data type and not workflow context?
• What breaks when phishing detections are built only around traditional email and network signals?
• What breaks when AI governance is built only around approved tools?