Contents
🛠️ Detection Engineering 101
Detection engineering is the process of designing, implementing, testing, and refining alerts that identify malicious or risky activity in your environment. It bridges the gap between threat intel, attacker TTPs, and real-time security monitoring.
🎯 “Good detection starts with knowing what you want to catch—and how attackers will try to hide it.”
🎓 What Is Detection Engineering?
Detection engineering involves:
- Creating rules and logic for SIEMs, EDRs, and SOARs
- Mapping detections to MITRE ATT&CK tactics and techniques
- Validating detections with threat simulations and test data
- Tuning and suppressing false positives
- Converting threat intelligence into actionable detections
🧱 Key Components of Detection Engineering
Component | Description |
---|---|
Data Sources | Logs from endpoints, firewalls, cloud, DNS, etc. |
Normal Baseline | What’s expected behaviour for users/systems? |
Detection Logic | Rule-based queries, thresholds, anomaly models |
Validation | Simulated attacks, threat emulation, red team |
Alert Quality | Low false positives, high confidence, actionable |
Coverage Mapping | Use MITRE ATT&CK to track what you detect |
🧪 Detection Lifecycle
- Hypothesis – “What if an attacker was using PowerShell to exfil data?”
- Log Availability – Ensure you’re collecting relevant logs (Sysmon, EDR, proxy, etc.)
- Rule Creation – Build logic using SPL, KQL, Sigma, or EQL
- Validation – Run emulated activity (e.g. Caldera, Atomic Red Team)
- Tuning – Eliminate noise; create suppression logic or thresholds
- Deployment – Push to SIEM/EDR with alert metadata
- Monitoring & Feedback – SOC analysts triage and tune based on response
⚙️ Tools of the Trade
Tool | Use |
---|---|
Sigma | Write generic detection rules for SIEMs |
Splunk / Sentinel / Elastic | Implement and test detection rules |
Atomic Red Team | Run small-scale attacker simulations |
Caldera / Prelude | Adversary emulation and validation |
MITRE ATT&CK Navigator | Visualise detection coverage |
YARA | File/memory pattern detection (esp. for malware) |
Kibana / Grafana | Visualise detection hits and patterns |
🔍 Detection Rule Example (Sigma)
yamlCopyEdittitle: Suspicious Encoded PowerShell Command
logsource:
product: windows
service: security
detection:
selection:
EventID: 4104
ScriptBlockText|contains: '-enc'
condition: selection
level: high
tags:
- attack.execution
- attack.t1059.001
This Sigma rule looks for PowerShell encoded commands, commonly used in obfuscated attacks.
🧠 Best Practices
- ✅ Start with high-confidence, low-noise detections
- ✅ Use MITRE ATT&CK as your detection blueprint
- ✅ Validate each detection with test data before deploying
- ✅ Track your detection coverage like a product roadmap
- ✅ Involve SOC analysts in tuning and feedback loops
- ✅ Document each detection’s purpose, logic, coverage, and limitations
📊 Detection Engineering Metrics
Metric | Why It Matters |
---|---|
True Positive Rate | High = detection works as intended |
False Positive Rate | Low = fewer wasted analyst hours |
Detection-to-Response Time | Helps measure effectiveness |
Coverage Gaps | Prioritise missing tactics/techniques |
Detection Decay | Identify rules that no longer trigger or are outdated |
✅ Summary
Detection engineering turns logs into insight and insight into action. By aligning detection efforts with real-world threats, security teams can reduce attacker dwell time and catch threats earlier in the kill chain.
🧩 “It’s not about having alerts—it’s about having the right ones.”