What Is a SIEM?

Last verified on Nov 8, 2026.

A SIEM (security information and event management) system collects logs from many systems into one place, analyzes them together, and raises the events that look like an attack. NIST's glossary describes SIEM software as a program that provides centralized logging capabilities for a variety of log types.

The idea is simple: one failed login on one host means little, but the same source failing on twenty hosts, then succeeding on one, is a story. A SIEM exists to see the story, because no single log source can.

What a SIEM Does

NIST SP 800-92 describes the core loop. A SIEM server receives logs from log generators, analyzes data from all the different sources, correlates events among the log entries, identifies and prioritizes significant events, and can initiate responses.

SP 800-92 notes that SIEM products usually support several dozen types of log sources, such as operating systems, security software, web and email servers, and even badge readers. Because they know what each field means for each source, they normalize and correlate better than a plain syslog setup.

A Normalized Event

Normalization turns three different formats into one shape you can query. A normalized authentication event might look like this (field names follow a common convention, not any single product):

{
  "@timestamp": "2026-11-08T02:14:09Z",
  "event": { "category": "authentication", "outcome": "failure" },
  "user": { "name": "svc-deploy" },
  "source": { "ip": "203.0.113.50" },
  "observer": { "type": "sshd", "hostname": "bastion-2" }
}

A correlation rule then states the story in terms of those fields. This one is generic pseudocode:

rule: failures-then-success
window: 10m
steps:
  - match: { event.category: authentication, event.outcome: failure }
    group_by: [source.ip]
    count_at_least: 20
  - match: { event.category: authentication, event.outcome: success }
    group_by: [source.ip]

SIEM vs Log Management

The two overlap. SP 800-92 says log management software typically handles a wide range of log entries and is not focused on analysis of security-related ones, while a SIEM is. In practice the line is the analysis: log management answers "what happened on this host", while a SIEM answers "which of these ten thousand events deserve a person".

If you only need central search and retention, see log aggregation and syslog. A SIEM adds the security layer on top.

What to Feed It First

More sources is not better if nobody tunes the rules. CISA, ASD's ACSC, and international partners published guidance on implementing SIEM and SOAR platforms, including a practitioner guide on which logs to prioritize for ingestion. A reasonable first set answers "who got in and what did they change":

• Authentication and identity logs, which feed authentication anomaly checks.
• Cloud audit logs such as AWS CloudTrail, which feed privilege change checks.
• Network edge logs such as VPC Flow Logs and WAF logs.
• Host audit logs, which record logins and sudo use.

For logging choices that apply before any SIEM, read security logging and the audit log entry.

Sazabi and SIEM Workloads

Sazabi, an AI-native observability and security platform, ingests many of the same sources. Its CloudTrail connection streams events through CloudWatch Logs and keeps CloudTrail's JSON fields searchable, and you can ask questions of the logs in plain language from the CLI. For the signals worth watching in that data, see security issues.