Incident Response
Security information and event management
Security information and event management is a platform capability for collecting, normalizing, correlating, searching, alerting on, and retaining security-relevant logs and events.
In plain terms
A SIEM collects logs from across the organization and correlates them to detect and investigate threats. The central nerve center that ties scattered events into a picture, so an attack spread across systems can be seen as one.
By aggregating telemetry from firewalls, endpoints, identity providers, and cloud services into a central hub, security information and event management (SIEM) enables analysts to detect complex attacks that span multiple systems. A SIEM helps security teams see activity across many systems instead of investigating each data source separately.
SIEM data can come from identity providers, endpoints, servers, firewalls, cloud platforms, SaaS tools, applications, databases, DNS, email gateways, EDR tools, VPNs, network sensors, source code platforms, and privileged access systems. The value comes from combining these signals into searchable timelines and detections that support investigation and response.
NIST SP 800-92 remains a foundational reference for computer security log management because it emphasizes log generation, transmission, storage, analysis, protection, and disposal as an enterprise process. A SIEM is not only a search box. It is part of a log management and monitoring discipline with lifecycle decisions.
Collection alone is not enough. Logs must be parsed, normalized, timestamped, enriched, retained, protected, and understood. Poor parsing can break detections. Missing time synchronization can ruin timelines. Missing identity context can make alerts hard to interpret. Overly short retention can prevent historical investigation after a delayed discovery.
Correlation is a core SIEM use case. A single failed login may be unimportant. Failed logins followed by impossible travel, MFA changes, mailbox forwarding, privilege assignment, and data export from the same account may indicate compromise. Correlation turns scattered events into higher-confidence signals.
SIEM detections require engineering. A detection should define the threat scenario, data sources, fields, logic, severity, expected false positives, response steps, owner, test method, and tuning process. MITRE ATT&CK can help connect detections to techniques and data sources, but the logic still has to match local systems and logs.
Data onboarding should be prioritized by use case. High-value sources often include identity provider logs, cloud audit logs, endpoint alerts, privileged access logs, DNS, VPN, firewall, email security, and critical application logs. Low-value verbose logs can create cost without improving detection. Missing one critical source can make an otherwise good detection impossible.
Retention should match investigation needs. Some incidents are discovered weeks or months after initial access. Short retention may prevent responders from establishing root cause, scope, data exposure, and timeline. Retention decisions must balance security value, cost, privacy obligations, legal requirements, and storage architecture.
Access to SIEM data must be controlled. Logs may contain personal data, credentials accidentally recorded, sensitive business records, internal IP addresses, security tool details, and incident evidence. Analysts need enough access to investigate, but SIEM administration, rule editing, log deletion, and data export should be governed and logged with strong documented approval paths.
SIEM is distinct from security monitoring. Security monitoring is the practice of observing and acting on signals. A SIEM is one tool that supports that practice. A team can monitor without a SIEM, and a SIEM can exist without effective monitoring if no one tunes detections, responds to alerts, or validates coverage.
Modern SIEM programs often integrate with SOAR, EDR, cloud detection, data lakes, case management, and threat intelligence. Integration can help enrichment and response, but it can also create brittle workflows. Automation should be tested and should preserve evidence, not hide important context behind a ticket summary.
SIEM health should be monitored like any other critical security service. Teams should alert on stopped log sources, delayed ingestion, parser errors, clock drift, dropped events, storage saturation, disabled rules, failed enrichments, and unexpected cost spikes. A SIEM that silently loses identity or endpoint logs can make an active incident look clean and delay containment decisions.
Failure modes include ingesting everything without use cases, underfunding retention, failing to normalize key fields, ignoring parser failures, letting detections age without review, giving too many people administrative access, and measuring success by log volume rather than detection and investigation value. Another failure is assuming SIEM alerts equal security operations.
For example, a SIEM might correlate a suspicious cloud administrator login, a new API key, a disabled logging setting, and unusual data transfer from the same account into one high-severity investigation. The analyst receives a timeline, source events, related assets, identity context, and enough evidence to begin containment quickly. The same events also become evidence for post-incident review, control improvement, and customer or regulator questions when applicable. That chain of evidence is the SIEM’s operational value.