SIEM (Security Information and Event Management) questions appear regularly on the Security+ exam. The exam tests whether you understand what a SIEM does, how it differs from other security tools, and what specific capabilities it provides.
What a SIEM Does
A SIEM combines two functions:
Security Information Management (SIM) — Long-term storage, indexing, and retrieval of log data from across the organisation. Provides historical records for forensic investigation and compliance reporting.
Security Event Management (SEM) — Real-time monitoring, correlation, and alerting. Identifies patterns across multiple sources that individually look benign but together indicate an attack.
Core SIEM capabilities:
- Log aggregation — Collects logs from firewalls, servers, endpoints, applications, network devices in one central location
- Normalisation — Converts logs from different formats into a standard format for analysis
- Correlation — Identifies relationships between events across different sources
- Alerting — Generates alerts when correlated events match a known attack pattern (a correlation rule)
- Dashboards and reporting — Visualises security posture and provides compliance reports
SIEM vs Other Security Tools
This is where most exam questions focus — knowing when to choose SIEM versus another tool:
| Tool | Primary Purpose |
|---|---|
| SIEM | Aggregate logs, correlate events, alert on patterns |
| IDS/IPS | Detect/prevent known attack signatures in real-time traffic |
| Firewall | Filter traffic based on rules (allow/deny) |
| DLP | Detect and prevent data exfiltration |
| EDR | Monitor and respond to threats on endpoints |
| SOAR | Automate incident response workflows |
Exam trap: a question describes an analyst who wants to see all authentication failures across every server in the organisation over the past 30 days. The answer is SIEM — not IDS, not firewall logs, not individual server logs. The SIEM aggregates and stores all of those in one searchable place.
Correlation Rules
A SIEM correlation rule defines what pattern of events should trigger an alert. Examples:
- Five failed logins followed by a successful login within 60 seconds = possible brute force
- Traffic from an internal host to a known malicious IP = possible C2 communication
- User logging in from two geographically impossible locations within 30 minutes = impossible travel
The exam asks which tool uses correlation rules to detect attacks across multiple log sources — the answer is always SIEM.
Log Sources
A SIEM collects from:
- Syslog — Standard protocol for sending log data from network devices, servers, and applications
- Windows Event Logs — Authentication, policy changes, application events
- NetFlow/IPFIX — Network traffic flow data (not packet contents)
- Firewall logs — Allow/deny decisions
- DNS logs — Query records
- Web proxy logs — URLs accessed
Exam scenario: "A security analyst wants to determine which websites employees visited last week." The answer is reviewing web proxy logs — ideally through a SIEM that has already aggregated them.
SIEM and Compliance
Many regulations (PCI DSS, HIPAA, SOX) require log retention and security monitoring. A SIEM satisfies these requirements by providing:
- Centralised log storage with defined retention periods
- Audit trails for security events
- Automated reporting for compliance audits
A question asking which tool helps an organisation meet log retention requirements for a compliance framework — the answer is SIEM.
SOAR vs SIEM
SOAR (Security Orchestration, Automation, and Response) takes the next step after SIEM. Where a SIEM alerts on an event, a SOAR can automatically respond — blocking an IP address, disabling an account, or opening a ticket.
The exam distinguishes between them: SIEM = detect and alert. SOAR = automate the response.
Practice Security+ questions on monitoring and SIEM to solidify the distinctions between these tools.
How SIEM Works in Practice — From Log to Alert
Understanding the flow is what lets you answer scenario questions correctly, because the exam describes a step in the flow and asks you to identify what component handles it.
Step 1 — Event occurs on an endpoint. A user on a Windows workstation fails authentication three times. Windows generates Event ID 4625 (failed logon) three times in the Security event log.
Step 2 — Agent collects the event. A log agent (Windows Event Forwarding, or a vendor agent like Splunk Universal Forwarder) running on the workstation reads the Security event log and forwards the event data.
Step 3 — SIEM ingests and normalises. The SIEM receives the raw Windows event data and normalises it into its internal schema. A failed logon event from Windows, a failed authentication from a Linux PAM module, and a failed login from a firewall all get mapped to the same internal "authentication failure" event type.
Step 4 — Correlation rule fires. The SIEM has a rule: "five failed authentications from the same source IP within 60 seconds." The rule matches the pattern across the normalised events and triggers.
Step 5 — Alert is created. The SIEM generates an alert with context: source IP, username, timestamps, the specific events that triggered the rule, a severity rating.
Step 6 — Analyst reviews. The alert appears in the analyst's queue. The analyst investigates: is this a brute force attack or a user who forgot their password? They pull additional context — did this IP appear in any other alerts? What happened after the failed logins?
Exam scenario: "Which component of the SIEM process converts raw log data from different sources into a standard format?" The answer is normalisation — step 3. "Which component identifies patterns across multiple log sources?" Correlation engine — step 4.
UEBA — User and Entity Behavior Analytics
UEBA is specifically added to the SY0-701 objectives and represents the evolution of SIEM beyond rule-based correlation.
Traditional SIEM correlation rules are brittle — they catch known attack patterns but miss novel ones. UEBA uses machine learning to build a baseline of normal behaviour for each user and entity (devices, service accounts), then flags deviations.
What "entity" means: Not just users. UEBA covers servers, applications, network devices, service accounts — any entity that produces behavioural data.
Examples of UEBA detections:
- A developer who normally accesses only the development environment suddenly accesses the production database at 2am — anomalous behaviour, flagged even though no rule explicitly covers it.
- A service account that normally makes 50 API calls per hour suddenly makes 50,000 — entity behaviour anomaly.
- A user who normally logs in from London suddenly authenticates from Singapore 3 hours later — impossible travel detection.
Exam context: UEBA appears in questions about detecting insider threats, detecting compromised accounts (which will still authenticate successfully but behave differently), and advanced threat hunting. The keyword is "behaviour analytics" or "baseline."
Log Retention and Compliance
Why the exam cares about log retention: without logs, you cannot investigate incidents, meet compliance requirements, or support legal proceedings.
The compliance drivers:
- PCI DSS requires at least 12 months of log retention, with the most recent 3 months immediately available for analysis.
- HIPAA requires audit logs to be retained for 6 years.
- GDPR does not specify exact retention periods for security logs, but requires them for incident response and breach notification purposes.
The SIEM's role: A SIEM centralises log retention and makes compliance reporting easier. Instead of proving to an auditor that every server retained its own logs correctly, you show them the centralised SIEM with all logs ingested and searchable.
Storage tiers for logs: Hot storage (immediately searchable in the SIEM) is expensive. Organisations often move older logs to cold storage (S3, Azure Blob) to reduce cost while maintaining retention compliance. The SIEM can re-ingest cold storage logs for investigations.
The False Positive Problem — Why Tuning Matters
A SIEM that generates thousands of alerts per day is not useful — analysts cannot investigate every alert, so they start ignoring them. This is "alert fatigue" and it leads to real attacks being missed because they're buried in noise.
False positive: An alert fires, but investigation reveals no actual threat. A correlation rule fires for "five failed logins" but the user is an admin running an automated script that authenticates repeatedly.
The tuning process: After a SIEM is deployed, analysts work through the alert backlog, identify which alerts are consistently false positives, and modify the correlation rules. Common tuning actions: whitelist known-good IP addresses, adjust thresholds (five failed logins was too low, raise to fifteen), add context conditions (only alert if the account has no prior failed logins this week).
Exam context: A question describing an analyst who is overwhelmed with alerts and cannot investigate all of them, with many turning out to be benign, is testing alert fatigue and the need for SIEM tuning. The solution is tuning correlation rules and thresholds — not disabling the SIEM.
Syslog, CEF, and LEEF — Log Formats the Exam Expects You to Know
Syslog: The oldest and most universal log transport protocol. Defined in RFC 5424. Uses UDP (port 514) or TCP for log forwarding. Syslog has a severity level (0=Emergency through 7=Debug) and a facility code that identifies the source of the log. Every network device, server, and application that supports syslog can send logs to a central syslog server or SIEM.
CEF (Common Event Format): Developed by ArcSight (HP/Micro Focus). A structured log format designed for SIEM ingestion. Includes mandatory fields (device vendor, device product, device version, event class ID, name, severity) plus extensible custom fields. CEF logs are easier to parse consistently than freeform syslog messages.
LEEF (Log Event Extended Format): Developed by IBM QRadar. Similar goal to CEF but specific to QRadar's SIEM platform. A structured format for consistent log ingestion.
Exam pattern: If a question mentions a SIEM ingesting logs from many different device types and asks what protocol/format is most universally supported, the answer is syslog. If a question mentions structured log formats for SIEM integration, CEF and LEEF may appear in answer options alongside syslog.
SIEM vs EDR vs XDR — How to Tell Them Apart on Exam Questions
These three tools all produce security alerts and all appear in SY0-701 questions. Getting them confused costs marks.
SIEM: Aggregates logs from the entire environment (network devices, servers, endpoints, applications). Provides historical analysis and compliance reporting. Reactive — alerts after events occur. Does not take automated response actions natively (that's SOAR's role).
EDR (Endpoint Detection and Response): Lives on the endpoint (workstation, server). Monitors process execution, file changes, network connections, registry modifications at the host level. Can respond automatically — quarantine a file, kill a process, isolate the endpoint from the network. Real-time, endpoint-centric.
XDR (Extended Detection and Response): EDR expanded across multiple data sources — endpoint, network, email, cloud. XDR correlates detections across these domains in a single platform. An XDR platform might catch an attack that starts with a phishing email, progresses to endpoint compromise, and involves lateral movement — by correlating across all three domains.
The exam question tells you which to use by describing the data source and action:
- "Centralise logs from 200 servers, firewalls, and applications for correlation" → SIEM
- "Automatically quarantine a process that exhibits ransomware behaviour on an endpoint" → EDR
- "Correlate a phishing email with subsequent endpoint activity and lateral movement" → XDR