SIEM Analysis — Reading Logs Like a SOC Analyst
What the SIEM Is and What It Is Not
A SIEM collects logs from every security-relevant source — firewalls, endpoints, authentication systems, DNS, proxies — normalizes them into a common format, applies correlation rules, and surfaces alerts when patterns match.
What the SIEM is not: it is not an oracle that tells you whether you are being attacked. It surfaces patterns that match rules someone wrote. If the rules are poor, the alerts are noise. If the rules are missing, the attacks are invisible. The SIEM is only as good as the combination of data fed into it, the rules applied to that data, and the analysts who investigate the output.
The Most Important SIEM Skill
PAN-OS Log Types and What Each Tells You
PAN-OS sends multiple log types to the SIEM. Each tells a different part of the story. Understanding which log to query for which question is the foundation of efficient SOC investigation.
| Log Type | Best For | Key Fields | Query When |
|---|---|---|---|
| Traffic | Network connectivity, session volume, who talked to whom | src_ip, dst_ip, app, action, bytes, rule, duration | Investigating suspicious connections, data exfiltration volume, C2 beaconing |
| Threat | IPS hits, blocked malware, URL category blocks, blocked file types | threat_name, severity, action, src_ip, dst_ip, url | Investigating blocked attacks, measuring threat prevention effectiveness |
| URL Filtering | Web browsing behavior, blocked sites, high-risk category access | url, category, action, src_ip, user | Investigating phishing clicks, malware downloads, suspicious browsing |
| Decryption | SSL inspection results, excluded traffic, certificate errors | dst_ip, error, version, cipher | Investigating encrypted traffic anomalies, decryption policy effectiveness |
| Authentication | User logons, failures, MFA events, GP authentication | user, authtype, src_ip, result | Investigating login anomalies, credential attacks, GP auth failures |
| System | Firewall events, HA changes, admin logins, service restarts | subtype, description | Investigating unauthorized admin access, unexpected firewall events |
Reading PAN-OS Traffic Logs for Investigation
The traffic log is the starting point for most network-layer investigations. Here is how to read a traffic log entry for investigation, not just monitoring.
# Sample PAN-OS traffic log entry fields (as seen in Splunk): # time = 2026/05/26 08:23:11 # src_ip = 10.1.1.45 ← which internal host # dst_ip = 185.220.101.45 ← destination (look this up in threat intel) # src_port = 54321 # dst_port = 443 ← port 443 but is it HTTPS or C2? # app = ssl ← App-ID says ssl — not deeply identified # action = allow ← firewall allowed it # bytes_sent = 2048 ← small — not data exfiltration # bytes_received = 892560 ← large — significant download # duration = 3842 ← 64 minutes — long connection # rule = allow-web-traffic # user = domainjohn.doe # session_end_reason = aged-out ← connection timed out naturally # What this tells a SOC analyst: # - Long-duration SSL session (64 min) with significant download # - App-ID did not fully identify — staying as generic ssl # - Destination IP should be enriched against threat intel # - If destination is in a threat feed → high-priority investigation # - If destination is legitimate (CDN, cloud provider) → likely benign
Splunk Query Examples for PAN-OS Traffic Investigation
| Search for C2 beaconing pattern (regular intervals, same destination) index=panos sourcetype=pan:traffic action=allow | where dst_port in (80, 443, 8080, 8443) | bucket _time span=5m | stats count by _time, src_ip, dst_ip | where count > 5 | eventstats stdev(count) as std_count by src_ip, dst_ip | where std_count < 1 | table src_ip, dst_ip, count, std_count | sort -count | rename src_ip as "Internal Host", dst_ip as "Destination" | Search for large data transfers (potential exfiltration) index=panos sourcetype=pan:traffic action=allow | where bytes_sent > 100000000 | stats sum(bytes_sent) as total_bytes by src_ip, dst_ip, user | sort -total_bytes | eval total_MB = round(total_bytes/1048576, 2) | table user, src_ip, dst_ip, total_MB | Find hosts talking to newly registered domains (TLD + age) index=panos sourcetype=pan:traffic action=allow | eval domain = replace(dst_ip, ".*.", "") | lookup domain_age domain OUTPUT age_days | where age_days < 30 | stats count by src_ip, dst_ip, user
Reading the Threat Log for Investigation
What Threat Log Entries Mean
A threat log entry means the firewall's threat prevention engine identified and acted on a specific signature match. Understanding the severity and action fields tells you how much urgency this requires.
| Action | Meaning | SOC Response |
|---|---|---|
| block | Firewall blocked the threat — traffic stopped | Good news — investigate the source to understand intent |
| block-ip | Source IP added to block list after repeated detections | Investigate — is this an external attacker or an infected internal host? |
| reset-client / reset-server | TCP connection reset to stop the threat mid-session | Investigate — threat was partially delivered before reset |
| alert | Threat detected but traffic was allowed — detection-only mode | High urgency — threat reached the destination, investigate immediately |
| allow | Rule said allow regardless of threat (misconfiguration) | Critical — security profile action is overriding correctly — review rule |
Threat Log Investigation Query
| Find all threats from the same internal host in the past 24h
index=panos sourcetype=pan:threat
| where src_ip = "10.1.1.45"
| stats count by threat_name, severity, action, dst_ip
| sort -count
| table threat_name, severity, action, dst_ip, count
| Find high-severity threats that were only alerted (not blocked)
index=panos sourcetype=pan:threat
| where severity in ("critical", "high") AND action = "alert"
| stats count by src_ip, threat_name, dst_ip, dst_port
| sort -count
| table src_ip, threat_name, dst_ip, dst_port, countCross-Source Correlation — Building the Full Picture
A single log source rarely tells the complete story. The skill that separates effective SOC analysts from alert processors is the ability to correlate across multiple log sources to build a timeline and confirm or rule out malicious activity.
Investigation Workflow: Suspicious Outbound Connection
# Starting point: suspicious outbound connection alert for host 10.1.1.45 # to destination IP 185.220.101.45 on port 443 # Step 1: What did the firewall see? index=panos sourcetype=pan:traffic | where src_ip="10.1.1.45" AND dst_ip="185.220.101.45" | table _time, action, app, bytes_sent, bytes_received, duration, user # Step 2: What did DNS logs show for this host around the same time? index=dns | where src_ip="10.1.1.45" | eval time_delta = abs(_time - 1748262000) | where time_delta < 300 | table _time, query, query_type, response_ip, response_code # Step 3: What was the endpoint doing at the same time? index=endpoint | where host_ip="10.1.1.45" | eval time_delta = abs(_time - 1748262000) | where time_delta < 600 | table _time, event_type, process_name, parent_process, command_line # Step 4: Any authentication events from this user? index=auth | where src_ip="10.1.1.45" OR username="domain\john.doe" | eval time_delta = abs(_time - 1748262000) | where time_delta < 600 | table _time, username, result, src_ip, dst_ip
Each step adds a layer to the picture. The firewall log shows the connection. DNS shows which domain was resolved to that IP (and when, and by what). The endpoint log shows which process made the connection. The authentication log confirms which user was active on the machine. Together, they either build the case for escalation or eliminate the alert as benign.
The Two-Signal Rule for Escalation
A single alert from one log source is a signal. Two independent signals pointing at the same asset in the same time window is an incident.
- Firewall blocks a known bad IP AND endpoint EDR sees suspicious PowerShell on the same host → escalate
- SIEM alert for DNS tunneling pattern AND firewall traffic log shows high byte count to same domain → escalate
- Failed logins alert AND successful login from different geographic location 10 minutes later → escalate immediately
- A single failed login at 3am with no other signals → low confidence, document and monitor
Document Everything