eCDFP: Log Analysis and Detection study guide

This domain tests whether you can turn raw log sources into a defensible detection: choose the right telemetry, normalise fields, apply time correctly, and tune logic so it fires on attacks rather than on routine administration.

Core rules and concepts

Know the sources. Syslog severity runs 0 (emergency) to 7 (debug). Windows channels include Security, System, Application, Sysmon Operational and PowerShell Operational. Add EDR, network devices, cloud audit logs such as CloudTrail and Azure sign-in, and application logs. Each has its own field names, so normalise to common fields (user, src_ip, host, process, timestamp) before correlating.
Time is a control. Store and report in UTC, know the offset of exported logs, and keep NTP healthy. Clock skew silently breaks correlation and timelines.
Detection types: signature or IOC match, behavioural or anomaly logic, and threat-intel matching. Behaviour survives indicator rotation.
Thresholds plus sequence beat single events. 'Ten 4625 failures from one source in five minutes followed by a 4624 success for the same account' is a brute-force detection; ten failures alone is noise from a stale service account.
Baseline by role. Know what a domain controller, a developer laptop and a web server normally do. Rarity, such as first-seen parent processes or first-seen destination countries, is a strong signal.
Sigma provides vendor-neutral rule logic that you convert to your SIEM query and map to an ATT&CK technique for coverage tracking.
Detection lifecycle: identify the data source, write the logic, test against known-good and known-bad, tune false positives, document, then monitor for drift.
Log integrity: forward off-host promptly, restrict access, hash where evidentiary. Missing logs (1102, 104) are findings.

Worked example

You want to detect password spraying, not single failures. Rule logic: count 4625 with Logon Type 3 grouped by source IP, alert when one source fails against ten or more distinct accounts within ten minutes, and escalate if any 4624 Type 3 follows for a targeted account. Reasoning: spraying spreads a few attempts across many accounts, so per-account thresholds miss it, while per-source distinct-account counting catches it. Before enabling, exclude the vulnerability scanner's subnet and verify the account set against the authentication baseline.

Traps that cost marks

Detections built on a single event; ignoring timezone and ingestion latency; overbroad wildcards that flood the queue; shipping a rule untested against benign admin activity; assuming a log source exists because it is configured.

Key points

Normalise user, host, source IP and process fields before correlation.
Use UTC everywhere; clock skew destroys timelines.
Detection = threshold plus sequence plus context, not one event.
Password spraying is caught by distinct-account counts per source, not per-account failures.
Test rules against known-good activity before production.