SIEM & Log Analysis
The SIEM is the nerve center of a SOC. If you work as a SOC analyst, you'll spend more time in a SIEM than any other tool. This module explains what a SIEM is, how logs work, and how to start making sense of what you see.
What is a SIEM?
SIEM stands for Security Information and Event Management. It's a platform that collects log data from every system in an organization โ servers, firewalls, workstations, cloud services, applications โ aggregates it into one place, and automatically analyzes it for suspicious patterns.
Think of it like air traffic control. Hundreds of planes are in the air at once, each sending data about their position, speed, and status. Air traffic controllers watch a single screen that aggregates all that information and alerts them when something is wrong. A SIEM does the same for network and system activity.
The most common SIEMs you'll encounter:
- Splunk โ The most widely used enterprise SIEM. Powerful query language, steep learning curve.
- Microsoft Sentinel โ Cloud-native SIEM for Azure environments. Growing rapidly.
- IBM QRadar โ Common in large enterprises and government.
- Elastic SIEM โ Open-source option, popular for home labs and smaller orgs.
What are logs?
A log is a timestamped record of an event. Every time something happens on a computer โ a user logs in, a file is accessed, a network connection is made โ the operating system or application records it in a log file.
Logs are the raw material of a SOC. They tell you exactly what happened, when, and on which system. Without logs, you're blind.
Common log sources in a SOC
- Windows Event Logs โ Records logins, logouts, privilege use, process creation, and more on Windows machines.
- Firewall logs โ Records every connection allowed or blocked at the network perimeter.
- DNS logs โ Every domain name lookup made on the network. Goldmine for detecting C2 traffic.
- Web proxy logs โ Records every URL visited by users. Helps detect malware downloading files or data being exfiltrated.
- Authentication logs โ Login attempts, successes, and failures across all systems.
- EDR telemetry โ Process creation, file writes, network connections from endpoint security tools.
Reading a log entry
Log entries look intimidating at first. Let's break one down. Here's a simplified Windows login log entry:
Breaking it down:
- Timestamp โ When it happened: June 15, 2026 at 8:43 AM
- Event ID โ 4624 is a Windows code meaning "successful login"
- Account โ The user account that logged in: jsmith
- Logon Type โ Type 2 means interactive (sitting at the keyboard). Type 3 means network logon. Type 10 means remote.
- Source IP โ Where the login came from
Key Windows Event IDs to know
How SIEM alerts work
A SIEM doesn't just store logs โ it runs rules against them in real time. A rule might say: "If the same user fails to log in more than 10 times in 5 minutes, create an alert." When that condition is met, the SIEM creates an alert in your queue.
As a tier 1 analyst, you'll spend most of your day working through these alerts. For each one:
- Read the alert description โ what triggered it?
- Look at the raw log data behind the alert
- Pivot to related logs โ same user, same IP, same time window
- Decide: false positive, or real threat?
- Document your finding and close or escalate
A simple SIEM query (Splunk SPL)
Most SIEMs have their own query language. Here's a simple Splunk query to find failed logins:
| stats count by Account_Name, Source_Network_Address
| where count > 10
| sort -count
In plain English: "Find all failed logins (EventCode 4625) from Windows logs, count them by username and source IP, show only accounts with more than 10 failures, and sort by most failures first." This is a basic brute force detection query.