Threat Detection and Monitoring
Threat Detection and Monitoring
This domain tests detection engineering and monitoring judgment: which data sources to use, how to turn alerts into evidence, and how to decide whether an alert is a true positive. OSIR-style items often ask you to correlate identity, endpoint, and network telemetry rather than rely on a single signature.
Core rules and concepts
- Detection sources include SIEM correlation, IDS/IPS, EDR, DNS/proxy logs, authentication logs, cloud audit logs, and threat intelligence. Each has blind spots.
- MITRE ATT&CK maps observed behavior to tactics and techniques, such as T1110 Brute Force. Mapping helps prioritize detection coverage, not just alert volume.
- The Pyramid of Pain ranks indicators: hashes and IPs are easy for an adversary to change; TTPs and tools are harder. Detection should emphasize behaviors and chokepoints.
- Tune for false positives and false negatives. A noisy rule that analysts ignore is a detection failure; a rule that misses a known technique is a coverage gap.
- Baselining matters: impossible travel, new admin account creation, or unusual service creation only becomes meaningful against normal behavior.
Worked example
A SIEM rule fires: 40 failed logins followed by one success for a finance user, from an unfamiliar ASN. Reasoning: correlate VPN, identity provider, and EDR logs. If the success came from the same ASN as the failures and the endpoint shows a new mailbox rule, treat it as a true positive credential attack and possible business email compromise. Map to T1110 and T1137; contain the session, reset credentials, and search for mailbox rules. If the success came from the user's normal office IP after a mistyped password, close as a benign true positive with tuning feedback.
Traps
Do not treat alert count as risk; do not rely only on IOCs; do not ignore identity context; do not tune a rule silently without documenting the change.