SIEM and Correlation
A SIEM — security information and event management — centralizes logs from across the environment and correlates them, so that events meaningless in isolation (a failed login here, a new process there, an outbound connection) become a detectable attack pattern when seen together. It is the SOC's console: where alerts are generated, triaged, and investigated.
This topic covers what a SIEM does, the correlation that gives it value, and the tuning problem that decides whether it helps or just generates noise — because an untuned SIEM buries its own detections.
Aggregation and Normalization
A SIEM ingests logs in many formats and normalizes them to a common schema, so a single query or rule can reason across endpoints, network, cloud, and identity at once. That normalization is what makes correlation possible — without a common schema, an endpoint event and a cloud audit event cannot be compared, and the pattern that spans them stays invisible.
Correlation Rules
Correlation is logic that fires when a combination or sequence occurs: failed logins followed by a success and then a new process is a possible credential attack, meaningless as three separate events. Correlation turns isolated events into meaningful alerts, and mapping rules to ATT&CK techniques (Chapter 1) structures coverage so you can see which attacker moves you can and cannot detect.
Alerting, Triage, and the Analyst Workflow
The SIEM generates alerts that analysts triage — true or false positive, severity, scope — and escalate to incident response. The queue and the enrichment (context added automatically, like asset criticality and user role) are where SOC efficiency lives: an alert that arrives with context is triaged in minutes, while a bare alert starts every investigation from scratch.
The Tuning and Volume Problem
An untuned SIEM buries real detections under false positives, and alert fatigue means real alerts get closed unread. Continuous tuning, suppression of known-good, and prioritization by fidelity are the ongoing work — the SIEM is measured by detections that led to real outcomes, not by log volume or alert count. Meridian's SIEM shows the intruder's whole campaign correlated into one incident: the scan, the failed-then-successful logins, the new persistence, the command-and-control egress, tied together.
SIEM — aggregates and correlates logs, generates and stores alerts; the detection and investigation hub.
SOAR — automates the response to alerts (enrichment, playbooks, containment) on top of the SIEM.
XDR — vendor-integrated detection across endpoint, network, cloud, and identity, often replacing parts of the SIEM-plus-EDR stack. They overlap; many SOCs run SIEM plus SOAR, or an XDR platform, or both.
- Deploying a SIEM and never tuning it, so false positives bury real detections and analysts stop trusting the alerts.
- Ingesting logs without correlation rules, getting an expensive search tool but not detection.
- No enrichment or context on alerts, so every triage starts from scratch and the queue never clears.
- Measuring the SIEM by log volume or alert count rather than detections that led to real outcomes.
- Failing to map rules to ATT&CK, so coverage gaps stay invisible.
- Write correlation rules mapped to ATT&CK techniques so coverage is structured and gaps are visible (Chapter 1).
- Tune continuously — suppress known-good, prioritize high-fidelity alerts — to keep analysts trusting the queue.
- Enrich alerts automatically (asset criticality, user context, threat intel) so triage is fast.
- Integrate response (SOAR or playbooks) so detection flows into containment (Chapter 11), and measure outcomes, not volume.
- Correlate across endpoint, network, cloud, and identity, not one source in isolation.
Knowledge Check
What does correlation add over simply aggregating logs in one place?
- It fires on event sequences, revealing an attack pattern
- It compresses all the aggregated logs to save on storage space
- It encrypts the aggregated logs once collected
- It removes the need to collect logs at all
Why does an untuned SIEM often fail to improve security?
- False positives bury detections; analysts stop reading
- It simply cannot ingest logs from more than one single source
- It automatically blocks all network traffic by default
- It deletes stored logs faster than they arrive
How should a SIEM's effectiveness be measured?
- By detections that led to real outcomes
- By the total number of alerts it generates per day
- By how many gigabytes of raw logs it stores
- By how many distinct data sources it ingests
You got correct