Security Log Analysis and SIEM Correlation
This domain tests normalization discipline, correlation logic design, and the detection-engineering judgment to know when a rule is firing correctly versus firing loudly.
From raw logs to a searchable schema
- Parsing and normalization map vendor fields to a common schema (ECS, CEF, LEEF) so that
src_ipmeans the same thing everywhere. - All timestamps normalize to UTC. Ingest lag and index-time versus event-time differences must be accounted for before you assert ordering.
- Log source health is part of the analysis: a silent firewall may mean a stopped forwarder, not an absence of attacks. Syslog over UDP loses events under load; Windows Event Forwarding has its own queue behavior.
- Query patterns you should be fluent in: aggregation (
stats count by user, src_ip), time bucketing (bin/bucket), and joins on entity fields.
Correlation patterns
- Threshold: N failures in T seconds (4625 bursts, 4776 NTLM failures).
- Sequence: event A followed by event B inside a window, for example five 4625 then a 4624 from the same source.
- Deviation: first-seen process, new country, new user agent for an established host.
- Entity join: correlate on account and host, not just IP - NAT collapses many internal hosts into one external address.
Worked example
At 02:14 UTC, six workstations each log five to eight 4625 events across many different usernames from a single source IP, followed at 02:19 by 4624 type 3 on two of them and 4672 on one. Reasoning: many accounts, few attempts each, one source equals password spraying, not brute force (which would be many attempts against one account). The successful 4624 type 3 confirms at least partial success. Pivot: check 4768/4769 for Kerberos activity from that source, and verify the source IP is not a NAT gateway or vulnerability scanner before escalating.
Traps that cost marks
- Correlating across sources without confirming time zone and clock sync.
- Reporting "no activity" when the log source simply stopped forwarding.
- Writing rules broad enough to fire on routine admin behavior, then suppressing the rule entirely instead of tuning it.
- Assuming rolled-up or summarized logs retain per-event fields they actually dropped.