Security Monitoring, Detection, and Analysis
Security Monitoring, Detection, and Analysis
This domain tests whether you can build a detection pipeline and reason from evidence. Items ask which telemetry proves an activity, why an alert is noisy, or how to distinguish a benign anomaly from an intrusion.
Core rules and concepts
- Pipeline: collection → normalization/parsing → enrichment (asset, identity, threat intel) → correlation → alerting → triage → tuning. Gaps in collection are silent; document log coverage against ATT&CK data sources.
- Log sources: endpoint (EDR, Sysmon, PowerShell script block logging), network (firewall, proxy, DNS, Zeek, NetFlow), identity (domain controller, IdP, MFA), cloud control plane (CloudTrail, Azure Activity), and application logs.
- Windows events worth memorizing: 4624 successful logon (Type 2 interactive, 3 network, 5 service, 10 RDP), 4625 failure, 4648 explicit credentials, 4672 special privileges assigned, 4688 process creation, 4720 account created, 4728 group membership change, 4768/4769 Kerberos TGT/TGS requests, 4771 pre-authentication failure, 7045 service installed, 1102 audit log cleared, 4104 PowerShell script block. Sysmon adds Event 1 process create, 3 network connect, 8 CreateRemoteThread, 10 process access (LSASS reads), 11 file create, 13 registry set, 22 DNS query.
- Detection engineering: write vendor-neutral logic as Sigma rules and convert to the SIEM query language; version rules; test against known-bad and known-good data.
- Baselining and tuning: know your normal (log volume, authentication patterns, service accounts, scheduled jobs) before alerting on deviations. Measure false positive rate per rule and retire rules nobody acts on.
- Time discipline: NTP synchronization across all sources; normalize to UTC before correlation. Skewed clocks destroy timelines.
- Base rate fallacy: a highly accurate rule over a rare event still produces mostly false positives - weighting and asset criticality matter.
Worked example
You see many 4625 failures and 4771 pre-authentication failures, few per account but across 40 distinct accounts, all from one source within ten minutes, followed by a burst of 4624 Type 3 successes. Reasoning: one account with hundreds of failures is brute force; many accounts with a couple of failures each is password spraying, chosen to stay under lockout thresholds. The detection should count distinct targeted accounts per source per window, then check for subsequent success - that pair is the escalation trigger.
Traps that cost marks
- Alerting on a single log source when the behavior requires endpoint plus identity correlation.
- Ignoring log collection gaps and assuming absence of alerts means absence of activity.
- Leaving rules untuned until analysts ignore the queue.
- Forgetting UTC normalization when building a timeline.