Join our Newsletter — 33% off our NHI Course

Notifications
Clear all

SIEM ingestion costs and detection coverage: what teams should do


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 17031
Topic starter  

TL;DR: Cloud telemetry can push SIEM spending up quickly because many environments ingest far more operational noise than security value, and Axoflow argues that filtering before ingestion is the only structural way to reduce cost without breaking detections. The broader lesson is that sampling and post-ingest filtering solve the wrong problem when the SOC still needs complete visibility for rare but consequential events.

NHIMG editorial — based on content published by Axoflow: How to Cut SIEM Costs 30-85% Without Losing Detection Coverage

By the numbers:

Questions worth separating out

Q: What breaks when teams sample SIEM logs to cut costs?

A: Sampling breaks the basic premise of detection because security events are rare and cannot be treated like averages.

Q: Why do automation identities create disproportionate SIEM cost pressure?

A: Automation identities generate highly repetitive telemetry at machine speed, so they can dominate ingestion without adding much investigative value.

Q: How can security teams tell whether pre-ingestion filtering is working?

A: They should test two things at once: whether billable volume falls, and whether known-bad events still trigger the same detections.

Practitioner guidance

  • Classify log sources by security relevance Separate repetitive operational telemetry from events that can indicate credential abuse, privilege escalation, or suspicious access.
  • Validate routing with known-bad identity events Inject test events such as suspicious AssumeRole activity, unauthorized CreateAccessKey activity, and abnormal cross-account access into the pipeline.
  • Preserve raw telemetry outside the SIEM Keep full-fidelity logs in lower-cost storage before any permanent filtering decision is made.

What's in the full article

Axoflow's full post covers the operational detail this post intentionally leaves for the source:

  • Step-by-step pipeline design for routing CloudTrail, Kubernetes, Windows, and flow logs before SIEM ingestion
  • Worked examples of operational-versus-security log classification across high-volume sources
  • Practical validation steps for proving that known-bad identity events still trigger detections after filtering
  • Deployment considerations for edge buffering, normalization, and low-cost storage tiers

👉 Read Axoflow's analysis of how to cut SIEM costs without losing detection coverage →

SIEM ingestion costs and detection coverage: what teams should do?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 16618
 

Pipeline-first telemetry is a governance response to SIEM economics, not a license for blind filtering. The central issue is that many SOCs still treat every event as equally worthy of the SIEM, even when 60% to 90% of that volume is routine infrastructure chatter. That is not a detection strategy, it is a billing strategy. The practical conclusion is that security teams must classify telemetry by security relevance before it reaches the correlation layer.

A question worth separating out:

Q: Who is accountable if a filtered log later turns out to contain an attack signal?

A: The accountable team is the one that owns routing, detection coverage, and validation of the telemetry pipeline, not just the SIEM contract. If an event is filtered away, that is a governance decision with operational consequences. Security leaders need change control, testing, and escalation paths for any classification rule that can suppress evidence.

👉 Read our full editorial: How to cut SIEM costs without losing detection coverage



   
ReplyQuote
Share: