SIEM: Detection Logic, Tuning, and Correlation
From logs to alerts
A SIEM ingests logs, normalizes fields, correlates events, and fires alerts. Understand the pipeline: collection (agents, syslog, API), parsing/normalization to a common schema, enrichment (GeoIP, asset criticality, threat feeds), correlation rules, and alerting. Know the difference between a log source (where data comes from) and a rule (logic that triggers).
Detection concepts
Be comfortable with threshold rules (N failures in M minutes), correlation across sources (EDR process creation plus firewall egress), watchlists and allowlists, and baselining to spot anomalies. Understand false positive versus false negative trade-offs and why tuning matters: noisy rules cause alert fatigue, and over-suppression creates blind spots. Know common Windows event IDs used in detection, such as 4624/4625 (logon success/failure), 4688 (process creation), 4720 (user created), and 1102 (audit log cleared).
Traps and a worked example
Traps: assuming more logs equal better detection (unparsed logs are useless); confusing correlation with aggregation; forgetting time synchronization (skewed clocks break correlation); and treating a single failed logon as an incident. Also note that encrypted or missing logs create detection gaps you must state explicitly.
Worked example: detect password spraying. Rule: count 4625 events grouped by source IP across many distinct usernames in a 10-minute window. A brute-force rule groups by username instead. If the same IP fails against 40 accounts once each, that is spraying; if it fails 40 times against one account, that is brute force. Rule of thumb: write the detection question as "what behavior, in which source, over what window, with what baseline?" and document expected false positives before enabling the rule.