SIEM detection gaps are a routing problem, not a data problem

At a glance

What this is: This blog argues that SIEM detection gaps come from how telemetry is routed and prepared, not from a shortage of data, and cites a large enterprise sample where potential ATT&CK coverage far exceeded realised coverage.

Why it matters: For security and identity teams, the implication is that improving detection quality depends on pipeline design, source prioritisation, and enrichment, not simply buying more ingestion capacity.

By the numbers:

• The organizations in the sample were already ingesting enough telemetry to potentially cover 90% of MITRE ATT&CK techniques.
• Their actual coverage was 22%.
• The same study found 10% of deployed rules were broken and would never fire under any circumstances.

Context

SIEM coverage often fails because telemetry is treated as the product, when the real control plane is how data is routed, normalized, enriched, and made usable by detections. A high ingest count can still leave teams blind if the content layer cannot read, prioritise, or operationalise the right events.

This matters to IAM, PAM, and NHI programmes because identity-rich telemetry is only useful when service accounts, cloud activity, and authentication events are preserved in forms that detection logic can actually consume. The same governance issue shows up across human and non-human identity estates: visibility without usable structure produces false confidence.

The article’s central point is that many enterprises already have enough raw telemetry to support broad ATT&CK coverage, but their pipeline design and content engineering stop that data from becoming actionable detections. That is a typical failure pattern in large SIEM environments, not an edge case.

Key questions

Q: What breaks when SIEM teams treat coverage as a volume problem?

A: They often end up paying for more telemetry while still missing detections, because the bottleneck is parsing, normalization, routing, and enrichment. In practice, that means important events may exist in the environment but never become usable content for rules, models, or hunts. The result is apparent visibility without operational coverage.

Q: Why do high-volume logs often create more risk than value in SIEM programmes?

A: High-volume sources are not inherently bad, but they become risky when they push teams to disable useful telemetry or overload expensive analytics tiers. The problem is usually not the source itself. It is that teams lack routing logic that separates low-value noise from the events that actually support detection and investigation.

Q: How do security teams know if SIEM coverage is actually working?

A: They verify the path from source to rule, not just the rule itself. That means confirming the event IDs, fields, parsing, and schema consistency needed for a detection are present in live telemetry and regularly tested after filtering or onboarding changes. If the data is missing, coverage is not real.

Q: How should IAM and SOC teams use identity telemetry more effectively in detection engineering?

A: They should enrich authentication, service-account, and cloud identity events before those records reach the analytics layer. That allows detections to work with ownership, entitlement, and risk context instead of raw usernames and IPs. When identity data is structured early, it becomes a stronger control signal for both insider and external threat detection.

Technical breakdown

Why raw telemetry does not become detections by itself

Telemetry is only evidence until a detection engine can parse, normalize, and correlate it. Raw logs arrive with inconsistent field names, missing context, duplicate events, and source-specific quirks that make rule writing slow and brittle. That is why coverage can look large on paper while actual detections remain thin in practice. The operational problem is not simply collecting more events. It is converting heterogeneous machine-readable records into content that analytics, correlation, and behavioural models can reliably consume.

Practical implication: design the pipeline to preserve detection usability, not just ingestion completeness.

How routing changes the economics of SIEM volume

Routing separates expensive analytics ingestion from lower-cost storage or replay paths. That matters because some sources are high-volume but low-signal, while others are modest in volume and dense with detection value. A routing layer lets teams keep rare but important records searchable without forcing every event into the SIEM’s most expensive tier. This is especially relevant where cloud control plane logs, endpoint process events, and identity telemetry have very different signal density. The control question becomes which fields and event classes need live analytics versus which can be retained for hunt and replay.

Practical implication: use attribute-level routing to protect high-value detections while lowering the cost of low-value telemetry.

Why enrichment is a security control, not just a data transform

Enrichment turns isolated records into security context. An authentication event that only contains a username and source IP is hard to use in behaviour models, but the same event becomes more actionable when it is linked to department, asset class, entitlement profile, threat intelligence, and identity risk. That is why enrichment belongs in the pipeline, not after the fact in an analyst workflow. If identity context is missing at ingestion time, detections either become noisy or never get written. This is where IAM, NHI governance, and SIEM operations intersect most directly.

Practical implication: enrich identity and asset context before the event reaches detection logic.

NHI Mgmt Group analysis

Coverage debt is the hidden control failure in many SIEM programmes: teams count ingested volume, but they do not govern whether that volume can actually support the detections they rely on. The result is a false sense of visibility that survives renewal discussions but fails under intrusion pressure. For identity-heavy environments, the gap is especially dangerous because authentication, service account, and cloud activity often become the first signals of compromise. The practitioner conclusion is simple: measure the coverage output of the pipeline, not just the size of the pipe.

Routing is now a first-class security decision, not a storage optimisation problem: when teams treat filtering as a cost exercise, they often push valuable telemetry out of the analytics tier and into irrecoverable blind spots. That is a governance failure because the decision changes what the SOC can see, not just what it pays. The right model is to preserve searchability for low-signal data while reserving live analytics for records that detection content actually uses. Practitioners should align routing policy with use cases, not with procurement defaults.

Identity context is the real multiplier in detection engineering: the article shows why identity-rich logs become more useful when they are enriched before analytics rather than after an alert fires. That is directly relevant to IAM, PAM, and NHI governance because access events, service accounts, and cloud identities only become actionable when they are linked to ownership, entitlements, and risk. The named concept here is coverage-to-context drift, where organisations keep collecting data but lose the context required to detect misuse. Practitioners should close that drift at ingestion time.

Broken rules are a governance signal, not just an engineering defect: if 10% of deployed rules would never fire, the problem is not only technical debt but also control assurance debt. A detection programme cannot claim meaningful coverage when part of its rule base is dead on arrival. This is where continuous validation matters more than annual coverage reviews. Practitioners should treat rule health, routing fidelity, and enrichment quality as operational controls with owners and metrics.

The market is implicitly rewarding the wrong abstraction: per-GB pricing encourages organisations to buy volume before they understand signal, which leads to architecture choices that detection teams did not author. That misalignment will keep producing brittle SIEM estates until buyers separate cost control from security efficacy. The practitioner conclusion is to push for pipeline governance that preserves detection value while moving commodity telemetry out of the premium analytics path.

What this signals

Coverage-to-context drift is the failure mode this article exposes: organisations keep collecting logs, but the pipeline strips away the context needed to make those logs operational. That produces a SIEM estate that looks healthy in procurement terms while remaining weak in investigative terms. The reader implication is to govern context preservation as carefully as ingest volume.

Routing policy should now be treated as a detection-control decision, not an infrastructure convenience. If a source or field cannot be tied to a real analytic use case, it belongs in a lower-cost path, but the reverse is also true: telemetry that supports identity abuse, cloud misuse, or lateral movement must stay visible to the right detections. The programme question is whether your pipeline preserves the events that matter most to the SOC.

For identity programmes, the practical lesson is that service accounts, cloud control plane activity, and authentication logs become decisive only when they carry usable enrichment. Without ownership and context, those records are just storage cost. With them, they become the evidence base for detecting misuse, privilege abuse, and suspicious automation.

For practitioners

• Define detection-driven routing policies Map every major source to the detections, models, and hunts that actually consume it, then route only the necessary fields into the analytics tier. Keep the rest searchable in lower-cost storage so you do not trade coverage for savings.
• Preserve high-signal identity telemetry Keep process creation with command line, authentication, cloud control plane, and service-account activity available for analytics rather than excluding them on cost grounds. These sources often carry the earliest evidence of abuse and should be protected from blanket suppression.
• Enrich events before they reach detection logic Inject identity, asset, and threat context at the pipeline layer so analysts and models receive records that are already usable for correlation. This is especially important for IAM, NHI, and cloud events that look low-value until context is attached.
• Audit broken and never-firing rules Review the rule estate for content that cannot fire, has no current source mapping, or depends on fields no longer present. Tie rule health checks to coverage reporting so dead content does not inflate perceived maturity.
• Validate reduction by source, not only in aggregate Measure how much each source is reduced, what was routed, and what remained in the analytics path. Aggregate savings can hide the fact that one high-value log source was over-filtered while another carried all of the reduction.

Key takeaways

• The central SIEM problem in this article is not how much data exists, but how much of it is converted into usable detection content.
• The study cited by Gurucul found a large telemetry base that could potentially cover most ATT&CK techniques, yet actual coverage remained far lower and a slice of rules were non-functional.
• Detection teams need to govern routing, normalization, and enrichment as operational controls, because that is where coverage is won or lost.

Key terms

• Detection Coverage Analysis: The process of mapping which attacker techniques are well covered, thinly covered, or completely uncovered by current detections. In practice, it turns detection engineering into a measurable input for hunting, letting teams rank what to investigate next instead of guessing.
• Telemetry routing: The process of directing logs and events to different destinations based on value, urgency, and investigative need. In mature SOC designs, routing is a security control because it determines which events remain searchable in the SIEM and which are archived more cheaply.
• Normalization: Normalization is the process of mapping different log formats to a common set of fields and values. It allows security teams to write detections once and apply them consistently across sources, reducing blind spots caused by vendor-specific schemas or field naming differences.
• Enrichment: Enrichment adds contextual data to raw logs, such as asset ownership, identity attributes, geography, or threat intelligence. It reduces analyst effort by turning isolated events into more complete investigation records and helps automation make better decisions from the same underlying telemetry.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect identity governance to operational security decisions across modern programmes.