Notifications
Clear all
Topic starter
01/08/2026 10:43 pm
TL;DR: Legacy SIEMs become expensive by default when teams route every log source there without a classification framework, even though 70 to 90 percent of enterprise log volume is often low-value noise according to DataBahn. The real governance shift is to decide routing by detection latency, retention need, and query pattern, then treat enrichment as the mechanism that makes those decisions defensible.
NHIMG editorial — based on content published by DataBahn: pre-SIEM enrichment and telemetry routing for security data
By the numbers:
- routine firewall allow events, infrastructure health checks, and verbose application debug output collectively account for 70 to 90 percent of total log volume in a typical enterprise environment.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams decide what goes to the SIEM versus cold storage?
A: Use three criteria: how quickly the event must be observed, how long it must be retained, and how often analysts will query it.
Q: Why do identity and privilege events deserve different routing from routine logs?
A: Identity and privilege events often have low volume but high security consequence.
Q: What breaks when enrichment happens after ingestion instead of before it?
A: The SIEM has already charged you for the event before context can influence the decision.
Practitioner guidance
- Define a telemetry classification policy Create routing rules that score each log source against detection latency, retention requirement, and analyst query frequency before it reaches the SIEM.
- Promote identity and privilege events first Ensure failed logins, account lockouts, privilege changes, and PAM session starts reach indexed detection storage while bulk operational logs go elsewhere.
- Move enrichment ahead of ingestion Attach identity, asset, and threat context in the pipeline so the event can be routed to SIEM or cold storage with evidence already available.
What's in the full article
DataBahn's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step routing criteria for specific log families, including when to promote, archive, or drop them.
- Pipeline-level enrichment examples that show how context changes storage decisions before ingestion.
- Practical guidance on how to reduce SIEM volume without losing forensic fidelity or compliance retention.
- Implementation patterns for edge filtering, aggregation, and enrichment in production telemetry pipelines.
👉 Read DataBahn's analysis of pre-SIEM telemetry routing and enrichment →
Pre-SIEM enrichment: what it means for SIEM cost and detection?
Explore further
01/08/2026 10:52 pm
Routing telemetry by habit is a governance failure, not an engineering shortcut. The article shows that teams often default to the SIEM because no one has defined a triage framework for new log sources. That creates a classification problem that compounds over time and pushes low-value data into expensive detection infrastructure. For identity programmes, the same pattern appears when authentication and privilege events are mixed with routine operational logs. The practical conclusion is that routing policy must be explicit, reviewed, and tied to security value, not historical convenience.
A question worth separating out:
Q: Who is accountable for routing and retention decisions in a security pipeline?
A: Accountability should sit with the team that owns security data architecture, usually shared between security engineering, SOC leadership, and data platform teams. The decision cannot be left to source owners by default. Governance needs a documented policy for routing, retention, and review so the SIEM is used for detection, not habit.
👉 Read our full editorial: Pre-SIEM enrichment changes how security teams route telemetry
