Lion Cipher Lab
Build a SIEM correlation engine from scratch
- SOC Analyst / Blue Team
- Advanced
- ~60 min
- Free · no account required
Why it matters
Single-event alerting is where most detection programs drown: a port scan, a login after a few failures, a large upload -- each is common and benign on its own, so a rule that fires on any one of them buries the analyst in false positives while still missing the story that only emerges when those events are read together. Correlation is the craft of reading events together. A real intrusion is a sequence -- recon, then a brute-forced login, then lateral movement to a second host, then exfiltration -- and no single log line reveals it; the signal lives in the join between sources and the order…
What you'll learn
- fusing events from multiple log sources (auth, process, firewall/netflow, DNS) into one detection
- designing a correlation-rule model: an ordered sequence of predicates joined by a key within a sliding time window
- implementing a stateful, windowed state machine that advances partial matches and fires once on a completed chain
- carrying identity forward across hosts with variable binding (attacker IP -> user -> pivot host) instead of a single flat join key
- mapping each correlation stage to MITRE ATT&CK technique IDs (T1046, T1110, T1021, T1048)
- measuring the payoff: collapsing many noisy single-event alerts into one high-confidence incident and cutting false positives
- reconstructing an ordered attack timeline from correlated evidence
- naming and reproducing the two headline failure modes of correlation: base-rate/too-broad join keys and cross-source clock skew
Steps in this lab
- What a SIEM correlation engine actually is (and why single events lie)
- Open a terminal and make a clean folder
- Model the multi-source event stream (with a real kill chain hidden in it)
- Write the naive per-event detector (the strawman we will beat)
- Build the correlation engine: a windowed state machine with variable binding
- Run it: watch 8 noisy alerts collapse into 1 incident
- Failure mode 1 -- base rate: a join key that is too broad
- Failure mode 2 -- clock skew between sources breaks the ordering
- Why this, not that -- and when a simple detection wins