Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

SIEM augmentation and OT dwell time: what should SOCs change now?


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

TL;DR: SIEM augmentation can help SOCs work around IOC scale limits, storage caps, ingestion costs, and AI triage gaps without a rip-and-replace migration, according to Anomali, while one healthcare example showed OT dwell time drop from 47 days to 4 hours. That shifts the control question from replacement to where analytics, intelligence, and response layers should sit.

NHIMG editorial — based on content published by Anomali: Modernize Your SIEM

By the numbers:

  • The paper says a composite healthcare case study saw dwell time on an unmonitored OT device fall from 47 days to 4 hours.
  • The paper cites up to 60% TCO reduction from the three levers that drive SIEM augmentation economics.
  • The paper describes a 38% SIEM renewal hike in the healthcare case study that prompted the change in approach.

Questions worth separating out

Q: Should organisations replace the SIEM or augment it first?

A: Most teams should augment first.

Q: Why do SIEMs struggle when IOC volume grows quickly?

A: Because many SIEMs are tuned for collection and correlation, not for processing very large indicator sets at low latency over long retention periods.

Q: What do security teams get wrong about AI-driven alert triage?

A: They often focus on speed and ignore governance.

Practitioner guidance

  • Benchmark log-volume pressure by source class Measure which sources drive the largest ingest, storage, and query costs, then separate high-value telemetry from low-value noise before deciding on augmentation or renewal.
  • Preserve SIEM workflows while relocating heavy analytics Keep existing dashboards, rules, and SOAR playbooks intact, but move enrichment, deduplication, and intelligence scoring into the layer that can absorb scale more cheaply.
  • Treat identity telemetry as part of the SOC data model Correlate alerts with human, service, and workload identity context so privileged access and machine activity are visible in the same investigation flow as endpoint and cloud events.

What's in the full article

Anomali's full white paper covers the operational detail this post intentionally leaves for the source:

  • The sit-on-top versus selective offload decision framework for different renewal and budget conditions.
  • The four-step rollout plan for augmentation without a migration project.
  • The KPI set used to measure dwell time, visibility, and SOC efficiency after augmentation.
  • The healthcare case study breakdown behind the 38% renewal hike and the 47-day to 4-hour dwell-time change.

👉 Read Anomali's white paper on modernising SIEM with augmentation patterns →

SIEM augmentation and OT dwell time: what should SOCs change now?

Explore further

View Full Forum →  |  NHI Foundation Course →



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

SIEM augmentation is a governance response, not just a tooling preference. Once log volume, IOC scale, and retention needs exceed the practical limits of the incumbent platform, the real decision is how to preserve detection quality without destabilising operations. That is why augmentation patterns are gaining traction in mature SOCs. For practitioners, the question is whether the current architecture still supports the speed and depth of investigation the programme now requires.

A question worth separating out:

Q: How can teams measure whether SIEM augmentation is working?

A: Look for shorter dwell time, lower false-positive burden, and faster first-pass triage without losing coverage on OT, identity, or cloud events. If those metrics improve but investigators still cannot connect alerts back to the right identity or asset, the model is only partly working.

👉 Read our full editorial: SIEM augmentation is becoming the path around log-volume limits



   
ReplyQuote
Share: