A comprehensive study guide covering SIEM architecture and deployment, data collection techniques, normalization and parsing, UTC time synchronisation, secure logging, Windows event log categories, Syslog, and hands-on agent configuration with Beats, Wazuh, and Security Onion.
Objective 1.1 — System & network architecture in security operationsObjective 1.3 — Analyze data in security monitoring activities
1
What is a SIEM? — Architecture & Deployment
Log review is a critical part of security assurance — but gathering logs does nothing if no one reviews them. Logs should be reviewed regularly and proactively for threat hunting, not only after an incident. At the scale of an enterprise network, doing this manually across dozens of systems is impossible without a SIEM.
A Security Information and Event Management (SIEM) system provides real-time or near-real-time analysis of security alerts generated by network hardware and applications. Its core value is correlation — connecting events across multiple systems that individually appear benign but together indicate a threat.
The correlation example: John Smith logs into a VPN from Asia (legitimate — he's on a business trip). Minutes later, John Smith's credentials are used to badge into the server room in your building. Neither event alone triggers an alarm. A SIEM correlates the two timestamps and geographic impossibility — instantly flagging the anomaly that a human reviewing individual logs would likely miss.
Seven SIEM deployment requirements
1
Log all relevant events and filter out irrelevant data — don't collect everything indiscriminately.
2
Establish and document the scope of events — what is inside and outside your collection boundary.
3
Develop use cases to define threats — what constitutes a threat vs. normal behaviour in your specific environment.
4
Plan incident responses for given events — pre-define what actions are taken when specific alert types fire.
5
Establish a ticketing process — track flagged events through to resolution so nothing is dropped.
6
Schedule regular threat hunting — proactively search for things that escaped automated alerts.
7
Provide auditors and analysts an evidence trail — the SIEM is the central repository for compliance and investigation.
SIEM deployment models
Software
Installed on dedicated servers in your data centre. Maximum control over data and configuration. Requires in-house expertise to operate.
Hardware appliance
Purpose-built device from the vendor. Easier setup and vendor support. Less flexible for custom integrations.
Managed service (MSSP)
Outsourced SIEM operated by a Managed Security Service Provider. No infrastructure to manage, but data leaves your control.
2
SIEM Tools — Market Overview
You do not need to know how to operate specific tools for the CySA+ exam. However, recognising these names and knowing that they function as SIEMs is expected — and most are excellent additions to a home lab.
Splunk
Commercial · market leader
Big data analysis platform with connectors for most OSes and applications. Uses its own Search Processing Language (SPL). Pre-built dashboards, security intelligence searches, and incident response workflows. Local or cloud deployment.
paid
ELK / Elastic Stack
Open-source · four components
Elasticsearch = query/analytics, Logstash = log collection & normalization, Kibana = visualization dashboard, Beats = lightweight endpoint agents. Data flows: Beats → Logstash → Elasticsearch → Kibana. Local or cloud.
free tier
ArcSight
Commercial · compliance focus
SIEM with strong compliance reporting for HIPAA, SOX, and PCI DSS. Enterprise-grade analytics and a mature ecosystem of integrations.
paid
QRadar
IBM · enterprise SIEM
IBM's SIEM platform for log management, analytics, and compliance reporting. Deep integration with IBM security ecosystem.
paid
AlienVault / OSSIM
AT&T Cybersecurity · integrator
OSSIM (Open-Source Security Information Management) integrates Snort IDS and OpenVAS vulnerability scanner into one web-administered platform. Owned by AT&T, increasingly rebranded. Budget-friendly all-in-one.
open-source core
Graylog
Open-source · DevOps focus
Open-source SIEM with an enterprise tier focused on compliance and IT/DevOps operations. Less incident-response-oriented than Splunk; stronger for operational log management.
open-source
Exam tip: You will not be asked to operate or compare these tools in detail. Know the names, know they are SIEMs, and know the ELK Stack component names (Elasticsearch / Logstash / Kibana / Beats) because the Beats agent configuration appears in hands-on exam scenarios.
3
Security Data Collection — Three Collection Paths
A SIEM covers stages 2–4 of the intelligence lifecycle: Collection & Processing, Analysis, and Dissemination. Data reaches the SIEM via three distinct collection mechanisms. Understanding which one to choose for a given source type is a key architectural decision.
The three data paths to a SIEM (signature element)
Agent-based
Windows Server Beats / Wazuh agent
→
local filter + normalize
→
DC / Endpoint HIDS / EDR agent
→
port 5044
→
SIEM Logstash → Elastic
Listener/collector
pfSense / Router syslog client
→
syslog UDP 514 / TCP 1468
→
Switch / AP SNMP / syslog
→
push to collector
→
SIEM
Sensor / TAP
Network TAP inline hardware
→
SPAN port switch mirror
→
PCAP / flow data
→
IDS sensor Snort / Zeek / Bro
→
SIEM
Agent-based
Host-installed software
An agent (Beats, Wazuh/OSSEC) is installed on each host or server. It logs, filters, aggregates, and normalises data locally before forwarding to the SIEM. Best for endpoint visibility — process events, file integrity, registry changes, application logs.
Listener / collector
Push over syslog or SNMP
Hosts configured to push their logs to a collector using syslog or SNMP. No agent installation required — most network devices (routers, firewalls, switches) support this natively. Ideal for infrastructure devices where agent installation is impossible.
Sensor / TAP
Passive network capture
Packet capture and traffic flow data from network sniffers and sensors (SPAN ports, hardware TAPs, IDS sensors like Snort/Zeek). Captures network-layer evidence without requiring any host-side configuration.
False positives vs. false negatives
False positive
Alert on benign activity
The SIEM flags an event as malicious when it is not. Overwhelms analyst and response resources — someone has to investigate every alert. Erodes confidence in the system over time. Fix: tune rules to be more specific.
False negative
Fails to alert on real threat
A genuine threat is categorised as benign — analysts are exposed to a threat without being aware of it. More dangerous than false positives. Fix: review use case coverage, expand rule sensitivity where needed.
4
Use Cases & the 5Ws Framework
The key to reducing false positives and false negatives is developing well-defined use cases. A use case is a specific condition that should be reported — it tells the SIEM exactly what to look for, what data to collect, and what action to take when it is found.
Use case template — three required elements
Data sources + indicators
Which systems provide the relevant data and what specific indicators should be collected (e.g. Windows Security event ID 4625 from all domain controllers).
Query strings
The correlation logic — how to join and filter indicators across multiple systems to detect the threat (e.g. 30 failed logins from the same source IP within 30 seconds).
Response actions
What the SIEM or analyst does when the condition is met — create a ticket, send an alert, auto-block the IP, quarantine the endpoint, or escalate to IR.
The 5Ws — every use case must answer these
When
Time of event
When did the event start? When did it end? Duration of the incident.
Who
Identity involved
Which user account? Which host? Which service?
What
Specific details
What happened? Malware execution? Authentication failure? Data transfer?
Where
Location of event
Which host, server, file system, or network segment did it occur on?
Where
Origin of event
Did it originate inside (insider threat) or outside (external attacker)? Which IP? Which country?
Use cases mirror the threat hunting hypothesis from Chapter 5 — the difference is that a use case is codified into the SIEM as an automated rule or query, so the system monitors continuously rather than requiring manual hunting each time.
5
Data Normalization — Parsing, Formats & UTC
Security data arrives from dozens of sources in incompatible formats. Before a SIEM can correlate events across systems, all data must be transformed into a single consistent structure. This is normalization.
Raw log formats arriving at a SIEM
Binary (proprietary)
Tab-separated (TSV)
Comma-separated (CSV)
Database storage
Syslog format
SNMP format
XML
JSON
Plain text
A connector or plug-in is installed on the SIEM for each data source type. It handles parsing (interpreting the raw format) and normalization (mapping fields to a standard schema). The breadth of available connectors is a major differentiator between SIEM products — Splunk's connector ecosystem is one reason for its market leadership.
Time synchronization — UTC as the universal standard
An organisation operating across multiple time zones generates log events timestamped in different local times. Without synchronization, correlating events across locations becomes unreliable or impossible. The solution is to normalize all timestamps to UTC (Coordinated Universal Time) — a time standard, not a time zone, that every system can reference unambiguously.
2021-01-01T00:00:01Z
UTC format — unambiguous, no offset
=
2020-12-31 19:00:01−05:00
US Eastern time — same instant, different representation
Both timestamps represent the same moment: one second after midnight UTC on January 1, 2021 — which is one second after 7:00 PM Eastern Standard Time on New Year's Eve. Without UTC normalization, a SIEM treating these as different times would fail to correlate related events that happened simultaneously in different time zones.
Time synchronization failures are a primary cause of failed incident timeline reconstruction. If a compromise spans multiple geographic locations and the logs have inconsistent timestamps, establishing the true sequence of events becomes extremely difficult. Configure NTP (Network Time Protocol) on all systems to synchronize to a common authoritative time source, then configure the SIEM to normalize all timestamps to UTC.
Secure log storage — CIA principles applied to logs
Confidentiality
Encrypt log data at rest on the SIEM server. Logs contain sensitive data (credentials, PII, business processes) that is equally valuable to attackers.
Integrity
Hash log entries to detect tampering. A compromised attacker who can modify logs before you analyse them can erase their tracks entirely — hashing detects this.
Availability
Back up log data and build in redundancy. Losing log data during or after an incident destroys the forensic trail. Large organisations generate gigabytes to terabytes of log data per hour.
6
Windows Event Logs — Categories & Event Forwarding
Windows Event Logs record how users and software interact with the operating system. Each Windows system maintains multiple event log channels, each covering a distinct scope.
Five Windows event log categories
Category
What it contains
Example events
Application
Events generated by applications and services
Printer service fails to start, application crash, service exception
Security
Audit events — logon success/failure, access control decisions
Failed logon (4625), successful logon (4624), access denied to file, process creation (4688)
System
Events from the OS and system services
Storage volume health failure, driver load error, Windows service crash
Setup
Events generated during Windows installation
Setup errors, installation status messages (mostly relevant at deployment time)
Forwarded events
Events collected from other computers on the network
Any event from any remote Windows host, forwarded in XML .evtx format. Built into Windows 8+.
Four event severity levels
Information
Successful events — an operation completed normally. The vast majority of log entries.
Warning
Not a problem yet, but may become one. Example: disk space getting low, reaching a threshold.
Error
Significant problem — reduced functionality or service failure. Requires attention.
Audit success / failure
Unique to the Security log — records whether an audited operation (logon, access, privilege use) succeeded or was denied.
Windows Event Forwarding
Windows 8 and later have a built-in event forwarding mechanism that eliminates the need for a separate SIEM agent. It uses an XML-formatted subscription to collect events from remote hosts and forward them to a central Windows Event Collector in .evtx (Event Trace XML) format. This appears in the SIEM as the "Forwarded Events" log category on the collecting host.
Key Windows Security event IDs to know: 4624 = successful logon, 4625 = failed logon, 4688 = new process created, 7045 = new service installed, 4719 = system audit policy changed. These appear constantly in exam scenario questions about endpoint monitoring.
7
Syslog — Protocol, Structure & Modern Improvements
Syslog is the de facto standard for logging events from distributed systems across a network. Unlike Windows Event Logs (which are Windows-specific), syslog runs on Linux, macOS, Cisco routers, firewalls, switches — virtually every networked device. It is also one of the three collection paths to a SIEM.
Three meanings of "syslog": (1) The protocol used to transmit log data. (2) The server that receives logs (syslog server / syslog daemon). (3) The log entries themselves (syslog data). People use the word to mean any of these depending on context.
Syslog message structure
PRI code
Priority code calculated from the facility (which system generated it) and the severity level (0–7 from the syslog scale covered in Ch.7). You won't be asked to calculate this on the exam.
Header
The timestamp of the event (ideally in UTC) and the hostname of the source device. Enables correlation and geographic/network source identification.
Message
The source process that generated the event and the event content itself — this is the forensically relevant data. All of the actual log information lives here.
Original syslog limitations vs. modern improvements
Original syslog — drawbacks
⚠️ Uses UDP port 514 — fire-and-forget, no guaranteed delivery
⚠️ Congested networks drop messages silently — gaps in logs
⚠️ No encryption — messages readable by anyone on the path
⚠️ No authentication — cannot verify the source is legitimate
⚠️ No integrity checking — messages can be altered in transit
Modern syslog-ng / rsyslog — improvements
✅ TCP port 1468 — reliable delivery, retransmits on failure
✅ TLS encryption — protects messages in transit
✅ MD5 / SHA-1 — message authentication and integrity
✅ Message filtering — reduces noise at the source
✅ Automated log analysis and event response scripting
Configuring syslog forwarding (pfSense example)
pfSense syslog remote logging configuration
# Status → System Logs → Settings → Remote Logging
Enable remote logging:✓ checked Source address:LAN← log traffic from inside the firewall IP format:IPv4 Remote syslog server:10.1.0.246:514← SIEM IP, UDP port 514
Log contents to forward: ✓ System events← OS-level events ✓ Firewall events← ACL permit/deny records ✓ DNS events← DNS queries and responses ✓ Gateway monitoring← WAN link health ☐ DHCP events← not needed for this deployment ☐ NTP events← excluded — not in scope
# Only forward what you need — over-logging overwhelms the SIEM
8
Configuring a SIEM Agent — Beats, Wazuh & Syslog Sources
This section summarises the hands-on lab workflow for connecting endpoints and network devices to a Security Onion / ELK Stack SIEM. The commands below are for context and exam understanding — you are not expected to memorise them, but you should understand the sequence and purpose of each step.
Lab architecture overview
Security Onion
The SIEM appliance (VM)
Bundles Elastic Stack (Logstash + Elasticsearch + Kibana), Zeek/Bro passive sensor, Snort/Suricata IDS. IP: 10.1.0.246. Listens on port 5044 (Beats/Logstash) and port 514 (syslog).
Sensor (TAP/SPAN)
Passive network collection
Port mirror on the switch feeds all traffic to Security Onion's eth1. Zeek/Bro processes this passively. Zenmap port scans generate NIDS alerts visible in Kibana near-instantly.
Winlogbeat (Beats)
Windows endpoint agent
Installed on DC1 and MS1. Forwards Application, System, and Security event logs (plus IIS-specific logs on the web server) to Logstash on the SIEM.
Wazuh / OSSEC
HIDS agent on workstations
Installed on PC1/PC2. Generates security-relevant host alerts (file integrity, authentication, rootkit checks). Authentication key exchange ensures only authorised agents report to the SIEM.
Winlogbeat deployment sequence
winlogbeat installation on Windows (DC1 / MS1)
# 1. Edit winlogbeat.yml — set the SIEM Logstash endpoint # (YAML is whitespace-sensitive — 2 spaces per indent level) output.logstash: hosts:["10.1.0.246:5044"]← SIEM IP:port
# Optional: add IIS log source on the web server winlogbeat.event_logs: - name:Microsoft-IIS-Logging/Logs
# 2. Test the configuration file PS>./winlogbeat test config -c winlogbeat.yml -e Config OK
# 3. Install as a Windows service (persists across reboots) PS>./install-service-winlogbeat.ps1 PS>Start-Service winlogbeat
# 4. Verify firewall allows Beats traffic on SIEM side $sudo so-allow-view← shows port 5044 is open for Beats
# Register agent with the SIEM manager cmd>ossec-agent\agent-auth.exe -m 10.1.0.246 ↑ -m = manager IP (the SIEM) — creates authentication key
# In Wazuh Agent Manager GUI: Manager IP:10.1.0.246 Save → Manage → Start → OK
# Query SIEM for HIDS alerts from PC workstations # In Kibana discovery tab, index: log-ossec-* agent.name: PC* AND alert_level: >=5
Creating Kibana index patterns to query data
OSSEC / Wazuh alerts
Index pattern: log-ossec-*. Query by agent name and alert level. Use agent.name: PC* to filter workstations. Expand individual records to see full event context.
Syslog sources
Index pattern: log-syslog-*. Query by source IP: syslog-sourceip: 10.1.0.254 to isolate a specific appliance's (e.g. pfSense's) syslog stream.
The complete SIEM data picture in the lab: (1) network traffic via SPAN port → Bro/Zeek → NIDS alerts in Kibana, (2) Windows endpoint logs via Beats → Logstash → Kibana Host Hunting dashboard, (3) HIDS alerts via Wazuh → Kibana OSSEC dashboard, (4) firewall syslog via UDP 514 → Kibana syslog index. Each layer answers different questions — together they give complete visibility.
Exam
Quick Reference Cheat Sheet
SIEM purpose
Real-time security alert analysis + correlation. Covers intelligence lifecycle stages 2–4 (Collection, Analysis, Dissemination). Can be software, hardware appliance, or managed service. Requires scoped collection, use cases, ticketing, and regular threat hunting.
Agent-based = installed on host (Beats, Wazuh/OSSEC) → normalises locally → sends to SIEM. Listener/collector = syslog push from network devices. Sensor/TAP = passive PCAP from SPAN ports and hardware TAPs.
False +/−
False positive = alert fires on benign activity → analyst fatigue, resource waste. False negative = real threat not alerted → dangerous exposure. Both fixed by well-tuned use cases with specific query conditions.
Use case 5Ws
When (time). Who (user/host). What (event details). Where (location on network). Where (origin — inside/outside). Each use case also needs: data sources, query strings, and response actions.
Normalization
Parsing = interpret data from 9+ raw formats. Normalization = restructure into one standard schema. Done by connectors/plug-ins. All timestamps → UTC. Secure logs with encryption (C), hashing (I), backups (A).
UTC time sync
UTC = time standard (not a zone). All SIEM timestamps should be UTC. Offset notation: 2020-12-31 19:00:01−05:00 = 2021-01-01T00:00:01Z (same instant, five time zones apart). NTP keeps clocks aligned.
Windows event categories
Application (app/service events). Security (audit — logon 4624/4625, process 4688). System (OS/service errors). Setup (installation). Forwarded Events (from remote hosts, XML .evtx, built into Win 8+).
Lightweight ELK agent for Windows. Configured via winlogbeat.yml (YAML — whitespace-sensitive). Set output.logstash hosts to SIEM IP:5044. Test config before deploying. Install as Windows service for persistence. Forwards App/System/Security + custom logs.
Wazuh / OSSEC
Open-source HIDS agent. Register with SIEM manager using agent-auth.exe -m [SIEM-IP]. Authentication key exchange ensures only authorised agents report. Query OSSEC index in Kibana: agent.name + alert_level >= 5.
Security Onion stack
All-in-one: Elastic Stack + Kibana + Zeek/Bro + Snort/Suricata + Wazuh. Three data paths: SPAN → Bro NIDS alerts, Beats → Logstash endpoint logs, Syslog UDP 514 → syslog index. Use Kibana discovery + index patterns to query each source.