Incident Detection with SIEM
Incident Detection with SIEM
A SIEM aggregates logs, normalizes fields, correlates events, and alerts. Candidates must understand the pipeline: collection → parsing/normalization → enrichment → correlation rules → alerting → triage. Know the difference between log sources (firewall, EDR, DNS, proxy, IdP, cloud audit logs) and detection content (rules, correlation searches, threat-intel matches, UEBA baselines).
Core concepts:
- Correlation: combining events across sources (e.g., failed logons followed by a success from a new geography).
- Threshold/aggregation rules: alert when N events occur in T minutes.
- Tuning: reducing false positives without blinding the rule; suppression and whitelisting carry risk.
- Use cases: brute force, impossible travel, lateral movement, data exfiltration volume anomalies, privileged group changes.
- Threat-intel integration: matching IoCs against telemetry, with attention to false positives from shared infrastructure.
Traps: assuming more alerts means better detection (alert fatigue degrades response); confusing correlation with simple keyword search; forgetting that SIEM detection depends entirely on log source coverage and time synchronization; and treating a SIEM alert as a confirmed incident (it is a lead requiring triage).
Rule of thumb: Detection quality = coverage × rule fidelity × log integrity. If a log source is missing, no rule can compensate.
Worked example: Rule: "5 failed logons in 2 minutes followed by a success from the same account, different source IP." This is a correlation rule combining authentication events. If it fires repeatedly for a service account with a known scanner, the correct fix is tuning (exclude the scanner or adjust threshold), not deleting the rule.