Detection Engineering and Analytics
The Detection Engineering and Analytics domain evaluates detection logic: XQL-based rules, IOC and BIOC rules, correlation, analytics and ML detections, alert tuning, and mapping to MITRE ATT&CK. The exam expects you to choose the right rule type and validate it against real data.
Core rules
- IOC rules match known indicators; BIOC rules match behavioral event sequences from endpoint telemetry; XQL rules query arbitrary datasets; correlation rules combine alerts or events across entities and time.
- Analytics detections use behavioral baselines and entity context. They need clean identity and asset data to reduce noise.
- A production detection includes severity, description, MITRE mapping, entity fields, and a test plan. Test historical data and known-good activity before enabling.
- Tuning is not blanket suppression. Use precise exceptions, allowlists, and entity scoping; document why each exception exists.
- Alert volume is a design constraint. Correlate related detections into incidents rather than firing one alert per event.
Worked example
Build a detection for encoded PowerShell. Write XQL against process events: process name equals powershell.exe, command line contains -enc or -encodedcommand, and parent process is not a known management tool. Test against 30 days of data, exclude two admin servers by hostname, set severity high, map to T1059.001, and add a correlation rule that groups hits by endpoint within 10 minutes. Reasoning: the query is specific, the exception is narrow, and correlation reduces duplicate alerts.
Traps
Using raw fields in a normalized detection without checking parser output; enabling a rule without historical validation; suppressing by user instead of by verified service account; forgetting MITRE mapping and entity fields; treating an IOC hit as proof of compromise without enrichment.