What Problem SIEM Solves
An enterprise network generates millions of log entries every day — firewall logs, authentication logs, DNS query logs, endpoint protection logs, application logs, cloud audit logs, and more. Each source uses its own format, timestamp convention, and severity classification. Reviewing logs from a single source is manageable; making sense of the relationships across dozens of sources simultaneously is impossible for a human analyst without tooling.
SIEM solves this by centralising all log collection into a single platform, normalising different formats into a common schema, and applying correlation rules that identify patterns across multiple sources simultaneously. A single failed login doesn't warrant attention. A thousand failed logins from the same IP address across multiple accounts within two minutes does — and a SIEM correlation rule fires an alert the moment that pattern is detected, rather than waiting for an analyst to manually review authentication logs.
Core SIEM Functions
How Correlation Rules Work
A correlation rule defines a pattern that, when matched, should generate a security alert. Rules are defined by security engineers and threat intelligence teams based on known attack techniques (MITRE ATT&CK is the primary reference framework). A simple correlation rule might be: "If more than 10 failed authentication attempts occur for the same account within 5 minutes, generate a Brute Force alert." A more complex rule might detect a lateral movement pattern: "If a workstation authenticates to more than 5 different internal servers within 30 minutes after a failed external login attempt, generate a Lateral Movement alert."
The quality of a SIEM's detection capability is largely determined by the quality of its correlation rules and threat intelligence feeds. Out-of-the-box SIEM rules catch common attack patterns; organisations tune these rules over time and add custom rules specific to their environment. A SIEM with poor rule quality generates either too many false positives (alert fatigue — analysts start ignoring alerts) or too many false negatives (missed attacks).
SIEM vs SOAR — Understanding the Difference
SIEM detects threats and notifies analysts. The analyst then decides what to do and takes manual action — blocks an IP in the firewall, disables an account in Active Directory, quarantines an endpoint via EDR. This human-in-the-loop response introduces latency: an attack can progress significantly in the minutes or hours between alert generation and analyst response.
SOAR (Security Orchestration, Automation, and Response) adds automated response playbooks on top of SIEM alerts. When a SIEM alert fires, a SOAR playbook can automatically: enrich the alert with threat intelligence, check the affected account's history, disable the account if a confidence threshold is met, quarantine the endpoint, create a ticket with all context pre-populated, and notify the on-call analyst — all within seconds of the initial alert. SOAR doesn't replace human analysts; it handles repetitive, time-sensitive response tasks automatically and provides analysts with context-rich tickets for complex decisions.
On the exam: SIEM = detect and alert. SOAR = detect, alert, AND automate response. A question asking which technology "automatically responds to security incidents" is asking for SOAR. A question asking which technology "aggregates and correlates logs" is asking for SIEM.
Common SIEM Use Cases
Brute force and credential stuffing detection: Correlation rules fire when authentication failure counts exceed thresholds. The SIEM correlates failed logins across multiple systems — the same IP attempting to log into the VPN, web application, and email simultaneously is a stronger signal than attempts on one system alone.
Lateral movement detection: After an initial compromise, attackers move laterally through the network using legitimate credentials and tools. SIEM correlation rules detect patterns like a single account authenticating to an unusual number of internal systems in a short time window, or an account accessing resources it has never accessed before at an unusual hour.
Data exfiltration detection: Large data transfers to external destinations — especially to unusual geographic locations or at unusual times — trigger exfiltration alerts. DLP (Data Loss Prevention) integration adds context about whether the transferred data included sensitive content.
Compliance logging and reporting: PCI-DSS requires logging of all access to cardholder data. HIPAA requires audit trails for PHI access. SIEM provides centralised logging that satisfies these requirements and generates the audit reports auditors request, demonstrating continuous monitoring is in place.
SIEM Architecture — How Logs Actually Flow
Understanding how data flows into and through a SIEM demystifies what the platform does and how it's managed. Log collection uses several mechanisms depending on the source type. Agents — lightweight software installed on endpoints and servers — forward logs to the SIEM in real time. Windows events, application logs, and endpoint protection telemetry are typically agent-collected. Agentless collection uses protocols like syslog (UDP/TCP port 514), SNMP traps (port 162), and API integrations to pull logs from network devices, cloud platforms, and applications that can't run agents. Firewalls, switches, routers, and SaaS applications are typically collected agentlessly.
Once logs arrive at the SIEM, a parsing and normalisation engine processes each log entry into a common schema. A Windows Event ID 4625 (failed logon) and a Linux PAM authentication failure are fundamentally the same event — an authentication failure — but they look completely different in their raw formats. Normalisation converts both into a standardised "authentication_failure" event type with consistent field names (source_ip, username, timestamp, target_system) that correlation rules can work with regardless of source.
Normalised events flow into the correlation engine, where rules evaluate incoming events against time windows and conditions. The correlation engine is essentially a real-time database query engine that continuously asks: "has this pattern appeared in the last N minutes?" When a pattern matches, an alert is generated and routed to the ticketing system and analyst dashboard. Events that don't match any rules are stored in the log database for forensic search — most SIEM implementations retain logs for 90 days to 7 years depending on compliance requirements.
Alert Fatigue — The Biggest SIEM Operations Challenge
Alert fatigue is the operational enemy of effective SIEM. When a SIEM generates hundreds or thousands of alerts per day — many of them false positives — analysts quickly learn to skim alerts rather than investigate them thoroughly. The result is that real threats are missed because they're buried in noise. Managing alert fatigue is a critical SIEM operations skill that the Security+ exam tests indirectly through questions about tuning and false positives.
Reducing alert fatigue requires tuning correlation rules to reduce false positives, implementing alert prioritisation (Critical alerts get immediate attention, Informational alerts are reviewed in batch), suppressing known-good activity (whitelisting authorised administrative accounts that trigger brute force rules, excluding known vulnerability scanners from IDS alerts), and using threat intelligence feeds to automatically prioritise alerts involving known malicious IPs or domains. A well-tuned SIEM generates tens of meaningful alerts per day that all warrant investigation — not thousands of alerts that analysts learn to ignore.
Key SIEM Use Cases for the Exam
Account compromise detection: SIEM correlates failed logins (from the authentication logs), successful login after failures (from authentication logs), and subsequent unusual activity (from access logs) — individually innocuous events that together indicate credential compromise. The correlation rule fires when a pattern match is detected across all three log types within a configurable time window.
Insider threat detection: Behaviour that deviates from a user's baseline triggers anomaly alerts. A user who downloads 500 MB of files at 2am on a Sunday when they've never worked outside business hours is statistically anomalous. SIEM User and Entity Behaviour Analytics (UEBA) builds behavioural baselines and alerts on deviations without requiring a specific signature for the attack technique.
Compliance evidence: Every major compliance framework (PCI-DSS Requirement 10, HIPAA, SOC 2 CC7) requires centralised logging and monitoring. A SIEM provides the audit trail that auditors examine to verify that logging is active, events are reviewed, and incidents are responded to within required timeframes. The SIEM's reports become the primary evidence that compliance obligations are being met.