Monitoring, Detection, and Analysis
This domain tests whether you can turn raw telemetry into a defensible conclusion: which source to consult, how to baseline, how to tune, and how to separate a true positive from noise.
Core rules
- Coverage before alerting. Map log sources to ATT&CK tactics; a gap in DNS or proxy logging blinds you to command-and-control and exfiltration no matter how many rules you own.
- Centralise and normalise. SIEM value comes from correlated, time-synchronised (NTP), parsed events with consistent field names. Skewed timestamps make timelines useless.
- Detection types trade off. Signatures are precise but brittle; anomaly detection catches novel behaviour but generates volume; behavioural rules (parent-child process anomalies, rare destinations) sit between.
- Baseline the normal. Beacon jitter, patch-window traffic, and admin scripts should be known so they are not re-investigated weekly.
- Enrich, then decide. Add asset criticality, user context, threat-intel reputation, and ASN/geo before assigning severity.
- IOCs are atomic and perishable; TTPs are durable. Hunt on behaviours - credential access, lateral SMB, scheduled task creation - not just hashes.
- Every alert needs a disposition: true positive, benign true positive, or false positive, plus a tuning action.
Worked example
A SIEM rule fires: one workstation queries a newly registered domain every 60 seconds with roughly 5% jitter, each response returning TXT records of about 200 bytes. Proxy logs show the same host POSTing to that domain with a user agent matching no installed software. Is this malware?
Reasoning: periodicity plus jitter is machine-generated, not human browsing. TXT-record C2 is a known technique because TXT is rarely filtered. Small, consistent byte counts fit tasking-and-response rather than file transfer. The mismatched user agent is corroboration, not proof. Verdict: probable C2 beacon, moderate-to-high confidence. Next steps: pull Sysmon Event ID 22 (DNS) and Event ID 3 (network connect) to identify the parent process, check persistence via 7045 and scheduled tasks, then isolate the host and sinkhole the domain. What would change the verdict: a sanctioned update agent with documented infrastructure, or the same pattern appearing fleet-wide during a patch window.
Traps
- Equating alert volume with detection quality; more rules can mean more noise, not more coverage.
- Closing an alert because the IP is not on a blocklist - new infrastructure is unlisted by definition.
- Analysing a single event without building a timeline across sources.
- Ignoring DNS, DHCP, and authentication logs because they seem boring.
- Disabling a noisy rule instead of tuning its logic or whitelisting the legitimate case.