The industry is saturated with low-value alerts. We all know the feeling: dashboards flooded with noise, analysts chasing ghosts, and time wasted triaging what should’ve been filtered upstream.
In my experience, the guiding principle of any detection engineering program should be simple:
Low-volume, high-fidelity event data that drives clarity and sound investigation.
These events may trigger direct alerts or serve as structured telemetry to feed correlation logic, enrich threat intel, or inform automation pipelines. But achieving that signal-to-noise balance takes more than just turning on logging. Here’s how I’ve approached it.
1. Know what you want before you need it
One of the biggest missteps I see is “collect everything” thinking. It’s expensive, inefficient, and fails when it matters most.
When maturing EDR and SIEM programs, few things are more frustrating than knowing exactly which log would confirm a theory, only to find out logging wasn’t enabled.
Ask:
- What are your highest-risk assets?
- What logs should they be generating?
- Is collection configured correctly?
- Where does this data live, and who owns it?
2. Define normal behavior
You can’t spot anomalies until you understand what “normal” looks like. There are two paths here:
- Manual log analysis. Slow, but insightful.
- Baselining with machine learning or anomaly detection. Faster, but requires tuning.
This step is non-negotiable. Without it, you’re writing detection logic in the dark.
3. Map detection logic to real-world behavior
Once you have visibility and a behavioral baseline:
- Use your SIEM/EDR tooling (Splunk, Trellix, Defender) to model logic against known TTPs.
- Don’t just alert. Build telemetry events that inform other systems and enrich incident response.
- Prioritize correlation over duplication. An alert flood helps no one.
Real-world result
Using this exact process, I reduced a stream of 120,000+ low-fidelity daily EDR events down to under 7,000 high-value events. These now feed into Splunk as either direct alerts or as structured telemetry for deeper correlation and analytics.
The result:
- Reduced analyst fatigue
- Faster triage
- Higher-confidence detections
- Input for high-fidelity Python automations
- Better SOC metrics
Final thought
Detection engineering isn’t about collecting more. It’s about collecting better.
Every log, rule, or alert should serve a purpose. And every SOC deserves workflows that are as sharp as the threats they defend against.