Detection is a pipeline: logs flow in, rules match suspicious activity, alerts flow out to analysts. Understand the flow and the SIEM that runs it before writing a single rule.
Why: a Security Operations Center (SOC) detects attacks by collecting logs from across the environment, matching them against detection logic, and raising alerts for humans to investigate — so detection is a data pipeline, not a product you buy. When: think in terms of this flow when designing any detection. Where: the SIEM (Security Information and Event Management) is the engine that ingests, stores, searches, and alerts on that log data.
SOURCES ─► COLLECT ─► NORMALIZE ─► DETECT ─► ALERT ─► TRIAGE ─► RESPOND
(endpoints, (agents/ (common (rules/ (to an (analyst (IR — see
servers, syslog) schema) ML) queue) reviews) DFIR course)
network,
cloud, apps)
The SIEM runs COLLECT -> DETECT -> ALERT. Good detection needs good data.Why: a SIEM centralizes logs from everywhere so you can search across them, correlate events from different sources, and run detection rules continuously — no single log tells the whole story of an attack. When: route all security-relevant logs into it. Where: Splunk, Elastic (ELK), Microsoft Sentinel, and Wazuh (open-source) are common SIEMs; the concepts transfer between them.
A SIEM gives you:
CENTRALIZATION one place for endpoint + network + cloud + app logs
SEARCH query across all of it fast (over huge volumes)
CORRELATION link events from different sources into one story
DETECTION run rules continuously; alert on matches
RETENTION keep logs long enough to investigate + comply
Examples: Splunk, Elastic/ELK, Microsoft Sentinel, Wazuh (open source).Why: you cannot detect what you do not log — a rule for "PowerShell downloading a file" is useless if PowerShell logging is off — so detection engineering starts with ensuring the right telemetry exists. When: before writing a rule, confirm the source data is collected and complete. Where: this is why log-source coverage (next lesson) precedes rule writing.
"We didn't detect it" almost always means "we weren't logging it."
Before any detection rule, ask:
- is the source log being collected at all?
- is it complete (right verbosity / audit level enabled)?
- is it reaching the SIEM reliably (no gaps)?
- is it retained long enough to investigate after the fact?
No data -> no detection. Coverage first, rules second.