At 7:00 a.m. a SOC analyst opens a queue of 1,140 alerts. Three of them matter: a burst of failed logons against a file server, a successful logon from the same address four minutes later, and a new member added to that server's local Administrators group. Separately each looks routine. Together they describe an intrusion, and finding that pattern automatically is what a SIEM is for.
On the CompTIA Security+ SY0-801 exam, SIEM sits under objective 4.4, which expects you to explain the concepts and tools organizations use to monitor their environment and raise security alerts. This lesson covers how a security information and event management system collects, normalizes and correlates events, why synchronized clocks and retention decide what you can prove, how dashboards present the results, and how alert tuning keeps the queue worth reading.
A SIEM gathers security events from across the organization into one system
A SIEM combines two older ideas. Security information management is long-term storage, search and reporting over logs. Security event management is real-time monitoring, correlation and alerting. A modern SIEM does both: it ingests events from across the environment, stores them, runs detection rules against them as they arrive, and gives analysts one place to investigate.
Typical sources include domain controllers and identity providers, endpoint and EDR agents, firewalls, VPN concentrators, web proxies, DNS servers, email gateways, cloud and SaaS audit logs, and vulnerability scanners. Events arrive in a few ways:
- Agents or forwarders on hosts read local logs and send them on.
- Network devices and appliances send syslog to a collector.
- Windows Event Forwarding sends selected events from Windows hosts to a central collector.
- API connectors pull audit logs from cloud platforms and SaaS applications.
- Flow collectors receive NetFlow or IPFIX records from routers and firewalls.
Many SIEMs are licensed by data volume, measured in gigabytes per day or events per second, so deciding what to collect is both a security and a budget decision. Authentication, privilege changes, security tool alerts and perimeter traffic usually come first; verbose debug logs usually don't.
A SIEM detects and alerts. Taking automated action on those alerts, such as disabling an account or isolating a host, is the job of orchestration (SOAR) tools, covered in the automation section.
Normalization turns different log formats into the same fields
Every source writes events its own way. The same failed logon looks completely different on a Windows server and a Linux server:
Windows Security log (excerpt):
EventID=4625 TimeCreated=2026-10-21T02:41:07Z Computer=FS01
TargetUserName=jsmith IpAddress=203.0.113.45 LogonType=3 Status=0xC000006D
Linux /var/log/auth.log:
Oct 21 02:41:09 web01 sshd[4127]: Failed password for jsmith from 203.0.113.45 port 51122 ssh2
Normalization parses each format and maps it into a common schema, so one rule can ask the same question of every source:
time=2026-10-21T02:41:07Z host=FS01 event=auth_failure user=jsmith src_ip=203.0.113.45 source=windows
time=2026-10-21T02:41:09Z host=web01 event=auth_failure user=jsmith src_ip=203.0.113.45 source=sshd
The Linux line had no year and no time zone, so the parser had to supply both. That is one reason timestamps cause so much trouble in correlation.
Most SIEMs also enrich events as they arrive, adding the asset's owner and criticality, the user's department, the IP address's geolocation and its reputation from threat intelligence feeds. Many aggregate duplicates too, so 500 identical firewall denies become one event with a count.
Parsing failures are a silent risk. If a firmware update changes a firewall's log format and the parser stops matching, events still arrive but land unparsed, and every rule that depends on them stops firing without any error an analyst would notice. Watching the SIEM's own parse-failure counts catches this.