TL;DR: Detection engineering is increasingly shaped by telemetry pipelines, normalization, and routing before the SIEM, according to Abstract Security, because enterprises need cleaner data, lower hot-ingest costs, and better correlation across identity, endpoint, and network logs. The decisive issue is no longer tool count but whether teams can govern the log supply chain with clear ownership, tests, and measurable detection quality.
NHIMG editorial — based on content published by Abstract Security: State of Enterprise Detection Engineering for a Modern SOC
By the numbers:
- CrowdStrike said its 2025 acquisition of Onum was aimed at redefining the SOC data layer by streaming enriched telemetry and cutting SIEM storage needs.
- CrowdStrike described Onum as capable of up to 50% cost reduction in storage and 5x event throughput.
Questions worth separating out
Q: How should security teams implement telemetry pipelines before the SIEM?
A: Teams should treat the telemetry pipeline as a governed control point.
Q: Why do identity logs matter so much in detection engineering?
A: Identity logs anchor correlation across authentication, endpoint, and network activity.
Q: What do security teams get wrong about log normalization?
A: They often treat normalization as formatting work instead of a detection requirement.
Practitioner guidance
- Formalise log onboarding as a gated process Require source ownership, sample logs, field lists, and explicit success criteria before any new log source enters production.
- Map identity and endpoint data to a common model Standardise fields such as user identifiers, timestamps, IP addresses, and action results across authentication, VPN, EDR, and firewall sources.
- Treat detection content as code with tests Write each rule with documented telemetry prerequisites, ATT&CK mapping, and positive and negative test cases.
What's in the full article
Abstract Security's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step log onboarding process design, including intake gates and success criteria
- Field mapping examples across endpoint, identity, and network sources for CIM-style normalization
- Detection engineering QA practices, including replay testing, tuning, and change management
- SOC pipeline and cost optimisation examples for routing telemetry before the SIEM
👉 Read Abstract Security's analysis of modern SOC detection engineering and telemetry pipelines →
Telemetry pipelines in the SOC: what control gaps teams are missing?
Explore further
Detection engineering is becoming a governance problem, not just an analytics problem. The article shows that SOC performance now depends on whether source systems, security engineering, and operations teams agree on intake gates, ownership, and success criteria. When log onboarding lacks a formal process, the organization creates detection debt that no rule tuning exercise can fully remove. For practitioners, the lesson is that telemetry governance is part of security governance.
A question worth separating out:
Q: How do teams know if detection engineering is actually improving?
A: They should measure whether new detections survive variant testing, whether telemetry is complete enough to support triage, and whether alerts feed back into updated logic without long delays. If the programme only changes during quarterly reviews, it is probably drifting faster than it is improving.
👉 Read our full editorial: Detection engineering now hinges on telemetry pipelines and control quality