Key Takeaways: Security Information and Event Management (SIEM)

A scannable, reference-grade summary for review and the exam. Roughly 80% tables and decision aids. If you remember one thing: a breach is usually a failure to correlate data, not to collect it — and fidelity, not coverage, is the currency of a SOC.

Core definitions (the term ledger for this chapter)

Log-source priority (collect top-down, by detection value)

Rule of thumb: Easy-to-collect ≠ worth-collecting. Collect what serves a use case; send a cheaper full copy to a data lake.

Collection methods

Normalization at a glance

RAW (3 sources, same event)                    NORMALIZED (common schema)
 sshd "Failed password for jchen from X"   ┐    {timestamp, source, user, src_ip,
 4625 TargetUserName=jchen IpAddress=X     ┼──►  action, outcome, host}
 firewall "DENY TCP X:p -> Y:22"           ┘    -> one query/rule works across all

• Parse to get fields out; normalize to give them common names/formats.
• Map to a published model — ECS, OCSF, or Splunk CIM — don't invent field names.
• UTC everywhere; NTP on every source. Time-based correlation breaks under clock drift.

The correlation ladder (simple → powerful)

Why correlation beats single-event alerting: attacks are processes (kill chain, Ch.2); each step looks ordinary, but the sequence/combination betrays the attacker.

Meridian's first ten use cases (starter catalog)

Querying: the same shape in three dialects

Investigation: count logins by user for one source IP, last hour, most first.

-- SQL
SELECT user, COUNT(*) attempts FROM events
WHERE action='login' AND src_ip='203.0.113.77' AND timestamp >= NOW()-INTERVAL '1' HOUR
GROUP BY user ORDER BY attempts DESC;

-- SPL
index=auth action=login src_ip="203.0.113.77" earliest=-1h
| stats count AS attempts by user | sort - attempts

// KQL
Events | where action=="login" and src_ip=="203.0.113.77" | where timestamp >= ago(1h)
| summarize attempts=count() by user | sort by attempts desc

Shape to memorize: filter (lead with time bound) → aggregate → sort → (sometimes join).

Alert tuning — the fatigue toolkit

Decision rule: a noisy-but-valuable rule → TUNE (narrow conditions). A noisy-and-worthless rule → consider disable as a documented risk decision. Disabling a valuable rule = a silent false negative — strictly worse than visible noise.

The fatigue arithmetic: 800 alerts/day × 3% true ≈ 24 true positives buried in 776 false; a 5-analyst SOC (~100 alert capacity) cannot find them. Fidelity, not coverage.

SIEM vs. Data Lake vs. SOAR

Modern pattern: high-value logs → SIEM (hot, real-time); cheaper full copy → data lake (cold, long retention); response orchestrated by SOAR.

Dashboards & metrics (bridge to Ch.36)

Metrics are born in the SIEM: MTTD/MTTR need timestamped activity + alert records. No logging → no measurement (developed in Ch.36).

Recurring themes surfaced

Certification crosswalk

Common pitfalls (quick hit-list)

• ☐ "Collect everything" → expensive, noisy SIEM that gets ignored. Collect by use case.
• ☐ Easy-to-collect sources prioritized over high-value ones.
• ☐ No time bound on queries → scans terabytes, degrades the SIEM.
• ☐ Clocks not synced / not UTC → sequence correlation silently fails.
• ☐ Importing hundreds of vendor-default rules → instant alert fatigue.
• ☐ Disabling a noisy-but-valuable rule instead of tuning it → silent blind spot.
• ☐ Allowlists added without owner/justification/review → undocumented holes.
• ☐ Logs only on the host → an attacker clears them. Ship off-box.

Program + toolkit additions

• Program artifact: Meridian's logging & monitoring standard — prioritized source list (with owners/onboarding), normalization + UTC/NTP, ≥1-year retention with hot/cold split, first-ten use-case catalog, detections-as-code, weekly tuning review.
• bluekit module: siem.py — normalize(raw, source) (raw event → common schema) and correlate(events, rule) (threshold/sequence rule → alerts).
• Builds on: Ch.10 (network monitoring feeds the SIEM), Ch.7 (firewall/IDS as sources). Sets up: Ch.22 (detection engineering & hunting, Sigma), Ch.24 (IR consumes alerts; SOAR orchestrates response), Ch.36 (metrics & board reporting). Spaced review: Ch.10, Ch.6.