If you’re not logging it, it didn’t happen. That’s the foundational truth of security operations. But here’s the part nobody puts on the slide deck: if you’re logging everything and nobody’s reading it, the outcome is functionally identical. The breach still happens. The attacker still dwell for months. The only difference is that afterward, you get to discover in horrifying detail exactly how long you were compromised and how many alerts you ignored.

A SIEM — Security Information and Event Management — is the central nervous system of a security operations center. It’s supposed to be the thing that sees everything and tells you when something’s wrong. In practice, most SIEMs are expensive log dumpsters that generate thousands of alerts nobody investigates. That’s not a technology problem. That’s a people-and-process problem wearing a technology mask.

The TLDR

A SIEM collects logs from across your environment, correlates events, and generates alerts when something looks wrong. The technology works. The problem is that most organizations either collect the wrong logs, write terrible detection rules, or drown their analysts in so many false positives that the real alerts die in a queue nobody checks. A well-tuned SIEM is a superpower. An untuned one is an expensive liability.

The Reality

Here’s the number that should make you uncomfortable: SOC analysts ignore or fail to investigate more than 30% of alerts. Not because they’re lazy — because they’re buried. The average enterprise SOC sees thousands of alerts per day. After weeks of chasing false positives, analysts develop a survival behavior that looks a lot like learned helplessness. They start triaging by gut feel, closing alerts in bulk, and hoping the real ones are loud enough to stand out. Sometimes they are. Sometimes they aren’t.

The Verizon DBIR has consistently shown that log evidence of a breach existed in the victim’s systems — they just never looked at it, or looked at it and didn’t recognize it. The data was there. The detection was there. The human bridge between “alert fired” and “incident declared” collapsed under its own weight.

Meanwhile, attackers know this. The entire concept of living off the land (MITRE ATT&CK T1218) — using legitimate system tools like PowerShell, WMI, and certutil for malicious purposes — exists specifically because these actions blend into normal activity. Your SIEM sees a PowerShell execution. Is it an admin running a script or an attacker downloading a payload? Without context, enrichment, and well-tuned baselines, you genuinely cannot tell.

How It Works

What a SIEM Actually Does

At its core, a SIEM performs five functions: log aggregation (collecting logs from everywhere), normalization (translating different log formats into a common schema), correlation (connecting related events across sources), alerting (telling you when correlated events match known-bad patterns), and reporting (compliance dashboards, metrics, forensic queries).

The value isn’t in any single log. It’s in the correlation. A failed login attempt is noise. Three hundred failed login attempts from the same source IP against different accounts followed by a successful authentication and immediate access to a file share — that’s a story. That’s brute force (T1110) followed by lateral movement. The SIEM connects those dots because no individual log source can.

The Critical Log Sources

Not all logs are created equal. If you’re building or tuning a SIEM, start with these five — they cover the attack surface that matters most:

Authentication logs. Active Directory, LDAP, SSO providers, VPN concentrators. Every login, every failure, every privilege escalation. This is where you catch credential stuffing, password spraying, and compromised accounts. If you log nothing else, log this.

Firewall and IDS/IPS. Perimeter and internal segment boundaries. Blocked and allowed connections, intrusion detection signatures, anomalous traffic patterns. Attackers have to move data across your network — this is where you see it.

Endpoint detection (EDR). Process creation, file modifications, registry changes, network connections from endpoints. EDR telemetry is the richest source you have for understanding what’s actually happening on a machine. Tools like MITRE ATT&CK map directly to the process-level events EDR captures.

DNS logs. Every DNS query tells you where your machines are trying to go. Command and control (C2) channels, data exfiltration over DNS, domain generation algorithms — DNS is the canary in the coal mine that most organizations don’t bother to watch. CISA’s logging guidance specifically calls out DNS as a critical telemetry source.

Cloud audit trails. CloudTrail, Azure AD audit logs, Google Workspace admin logs. If your infrastructure is in the cloud — and it probably is — these logs capture API calls, configuration changes, and access patterns. An attacker disabling MFA on a compromised admin account shows up here. If you’re watching.

The Log Pipeline

Raw logs are useless until they’re processed. The pipeline looks like this:

Collection — Agents, syslog forwarding, API pulls, cloud-native connectors. Logs flow from sources to the SIEM. Reliability matters here. If your collection pipeline drops logs during high-volume events (like, say, during an active attack), you lose visibility exactly when you need it most.

Parsing and normalization — Different sources use different formats. A firewall log doesn’t look like an Active Directory event. The SIEM normalizes everything into a common schema so you can query across sources. Bad parsing means bad correlation. Garbage in, garbage out.

Enrichment — Adding context. Geolocating IP addresses. Resolving hostnames. Tagging assets with business criticality. Enrichment is what turns “192.168.1.47 authenticated to 10.0.0.12” into “the CFO’s laptop just authenticated to the domain controller from an unusual location at 3 AM.”

Correlation — Rules that connect events across sources and time windows. This is where detection engineering lives, and it’s where most SIEMs succeed or fail.

Alerting — The output. An alert fires, an analyst investigates. In theory.

Detection Engineering

Three approaches, and you need all of them:

Signature-based — Match known-bad patterns. Specific malware hashes, known C2 domains, exact attack tool signatures. High fidelity, zero coverage of novel attacks.

Behavioral — Baseline normal activity, alert on deviation. A service account that’s never authenticated interactively suddenly logging in from a workstation. An admin account active at 3 AM in a timezone where nobody works nights. Lower fidelity, broader coverage.

Anomaly detection — Statistical outliers. Unusual data transfer volumes, new processes on servers with stable baselines, first-time connections to external destinations. Noisy, but catches what the other two miss.

Map your detection rules to MITRE ATT&CK techniques. It gives you a coverage map — you can see which tactics you’re detecting and where your blind spots are. Spoiler: most organizations have excellent detection for initial access and almost nothing for defense evasion (TA0005).

Retention: How Long You Keep It

This isn’t optional — it’s regulatory. PCI DSS requires one year of log retention with three months immediately accessible. HIPAA requires six years. SOX requires seven. NIST SP 800-92 — Guide to Computer Security Log Management provides the framework, but your compliance team dictates the floor. Keep them longer than required if you can afford the storage. Attackers with 200-day dwell times don’t care about your 90-day retention policy.

How It Gets Exploited

Attackers don’t just evade detection — they actively undermine your logging infrastructure. Here’s the playbook the usual suspects run:

Log clearing. The first thing a competent attacker does after gaining access is check what’s being logged and clear their tracks. Windows Event Log clearing, Linux log rotation manipulation, database audit log truncation. MITRE T1070.001 — Indicator Removal: Clear Windows Event Logs.

Timestomping. Modifying file timestamps to confuse forensic timelines. If your correlation depends on accurate timestamps — and it does — an attacker who manipulates them can make events appear to happen in a different order or not at all. MITRE T1070.006.

Living off the land. Using built-in system tools — PowerShell, cmd, WMI, certutil, mshta — so that malicious activity looks indistinguishable from normal admin work. Your SIEM sees a PowerShell command. Is it an attacker or IT running a deployment script? Without behavioral baselines, you’re guessing.

Disabling EDR. If the attacker can kill the agent generating the telemetry, the SIEM goes blind on that endpoint. Techniques range from killing processes to loading vulnerable drivers that allow kernel-level tampering. No telemetry, no alert, no investigation.

What You Can Do

Start with the critical five. Authentication, firewall, EDR, DNS, cloud audit. Get these feeding into your SIEM reliably before you worry about anything else. Coverage of five sources done well beats coverage of fifty done poorly.

Tune aggressively. Every false positive that stays in the queue erodes analyst trust. Track your false positive rate by rule. If a rule fires 500 times a week and produces zero true positives, disable it or rewrite it. Tuning isn’t weakness — it’s operational maturity.

Implement detection-as-code. Version-control your detection rules. Peer review them. Test them against known-attack datasets like MITRE ATT&CK Evaluations. Treat detection rules like production code, because that’s what they are.

Forward logs to immutable storage. If an attacker can clear your logs, your SIEM is blind retroactively. Forward logs to a write-once store — S3 with object lock, a hardened syslog server, a separate SIEM instance the attacker doesn’t know about. The forensic copy survives even if the primary doesn’t.

Solve alert fatigue with structure, not hope. Tiered alerting — Tier 1 alerts are auto-enriched and routed to junior analysts, Tier 2 gets escalated with context, Tier 3 goes directly to senior responders. Automated enrichment (IP reputation, asset lookup, threat intel matching) reduces the manual work per alert. Playbook-driven triage means analysts follow a decision tree, not their instincts. OWASP’s operational security guidance and ISC2’s SOC resources both provide frameworks for building this out.

Related Deep Dives

Sources & Further Reading