Source Technologies & Events

Understanding event sources in security monitoring

Week 4 TOPIC 4.1 - Network Intrusion Analysis

Security Event Sources

A SOC analyst's effectiveness depends on understanding where security events originate and how to correlate data across multiple source technologies. Modern security operations aggregate events from dozens of sources into a centralized SIEM. Without this aggregation, an analyst would need to log into 20+ different systems to investigate a single alert.

Event Source Categories

Network Security

Firewalls (Palo Alto, Fortinet, Cisco ASA), IDS/IPS (Snort, Suricata, Zeek), proxy servers (Zscaler, Squid), NetFlow collectors, packet captures (full PCAP), DNS servers. Provides perimeter and internal network visibility.

Endpoint Security

EDR agents (CrowdStrike, SentinelOne, Carbon Black), antivirus/EPP, host-based IDS, Windows Event Logs, Sysmon, syslog (Linux). Provides process-level visibility on individual hosts.

Identity & Access

Active Directory (Event IDs 4624-4634), LDAP, SSO providers (Okta, Azure AD), MFA systems (Duo), PAM solutions (CyberArk). Critical for detecting credential abuse and unauthorized access.

Cloud & SaaS

AWS CloudTrail (API audit), Azure Monitor / Sentinel, GCP Audit Logs, O365 Unified Audit Log, Salesforce event monitoring. Cloud environments require API-based log collection vs traditional syslog.

Log Collection Architecture

Understanding how logs flow from source to SIEM is essential -- if a link breaks, you lose visibility:

Sources

Firewalls, endpoints, servers, cloud APIs, applications

-->

Transport

Syslog (UDP/514, TCP/6514-TLS), agents, API collectors, Kafka

-->

Parsing

Logstash, Fluentd, Cribl -- normalize fields, enrich with context

-->

SIEM

Splunk, Sentinel, Elastic -- search, correlate, alert, dashboard

Source: Eye House > Tools > SIEM Simulator Open SIEM Simulator

Event Source Details

Source Type	Log Format	Key Fields	Use Case
Firewall (Palo Alto)	Syslog/CEF	src_ip, dst_ip, action, rule, app, bytes	Perimeter traffic analysis, blocked C2 detection
Windows Event Log	XML/EVTX	EventID, Account, LogonType, SourceIP	Authentication tracking, process execution audit
Snort/Suricata IDS	Unified2/EVE JSON	signature_id, priority, protocol, payload	Intrusion detection, exploit identification
Zeek (Bro)	TSV/JSON logs	conn_state, service, duration, JA3 hash	Network metadata analysis, protocol inspection
AWS CloudTrail	JSON	eventName, userIdentity, sourceIPAddress	Cloud API auditing, IAM activity
Proxy (Zscaler/Squid)	CSV/W3C	user, URL, category, action, content_type	Web filtering, data exfil via uploads
EDR (CrowdStrike)	JSON/API	process, command_line, parent, file_hash	Malware execution, LOLBin abuse, process trees
DNS Server	Syslog/ETW	query, query_type, response, client_ip	DNS tunneling, DGA detection, C2 identification
Email Gateway	Syslog/CEF	sender, recipient, subject, attachment_hash	Phishing detection, malicious attachment analysis

Windows Security Event IDs

These are the event IDs you will encounter most frequently during SOC investigations:

Authentication Events: 4624 - Successful logon (check LogonType: 2=interactive, 3=network, 10=RDP) 4625 - Failed logon (brute force indicator when clustered) 4634 - Logoff (correlate with 4624 for session duration) 4648 - Logon using explicit credentials (pass-the-hash indicator) 4672 - Special privileges assigned (admin logon - always review) Account Management: 4720 - User account created (backdoor detection) 4726 - User account deleted (evidence destruction) 4732 - Member added to security group (privilege escalation) 4738 - User account changed (password reset without ticket) Process & Service Events: 4688 - Process creation (with command line if audit policy enabled) 7045 - Service installed (PsExec, malware persistence) Anti-Forensics: 1102 - Audit log cleared (the event that survives log clearing) 4719 - System audit policy changed (attacker disabling logging)

SOC Analyst Tip

Log Source Coverage Gaps: During your first week, ask: "What systems are NOT sending logs to the SIEM?" Common blind spots: IoT devices, OT/SCADA systems, shadow IT cloud services, BYOD devices, legacy systems running unsupported OS versions. An attacker who discovers a blind spot has an unmonitored attack path.

SOC Integration Strategies

Log Collection Methods

Syslog Forwarding

Traditional method via UDP/514 (unreliable, no encryption) or TCP/6514 with TLS (reliable, encrypted). Most network devices support syslog natively. Be aware: UDP syslog can lose events under load -- use TCP for critical sources.

Agent-Based Collection

Splunk Universal Forwarder, Elastic Agent, Wazuh agent. Installed on each endpoint. More reliable than syslog, handles parsing at source, survives network outages (buffers locally). Higher deployment overhead.

API Integration

REST APIs for cloud services (AWS CloudTrail, Azure Activity Log, O365 API, Okta). Rate limits and pagination must be handled. Authentication via API keys, OAuth tokens, or service principals.

Log Aggregators

Kafka, Logstash, Fluentd, Cribl as intermediate layers. Handle scale (millions of EPS), transformation (field renaming, enrichment), and routing (send firewall logs to SIEM, debug logs to cold storage).

Normalization -- Why It Matters

Different sources use different field names for the same data. Without normalization, you cannot write a single query that searches across sources:

Concept	Firewall Log	Windows Event	Zeek conn.log	Normalized (CIM)
Source IP	`src`	`IpAddress`	`id.orig_h`	`src_ip`
Destination IP	`dst`	`TargetServerName`	`id.resp_h`	`dest_ip`
Username	`user`	`TargetUserName`	`---`	`user`
Action	`action`	`Keywords`	`conn_state`	`action`

SOC Analyst Tip

Normalization is Critical: Splunk uses CIM (Common Information Model). Elastic uses ECS (Elastic Common Schema). Sentinel uses ASIM. Learn your SIEM's schema -- it determines whether your queries work across all log sources or only against one source type. A query that only searches firewall logs will miss the same attacker in endpoint logs.

Event Correlation Example

This Splunk query correlates failed logins with subsequent successful logins from a different IP -- a classic indicator of credential compromise:

// Step 1: Find accounts with 5+ failed logins index=windows EventCode=4625 | stats count as fail_count, values(src_ip) as fail_ips by TargetUserName | where fail_count > 5 // Step 2: Join with successful logins from different IPs | join TargetUserName [ search index=windows EventCode=4624 | stats latest(src_ip) as success_ip, latest(_time) as login_time by TargetUserName ] // Step 3: Flag cases where the success IP differs from fail IPs | where NOT match(fail_ips, success_ip) | table TargetUserName, fail_count, fail_ips, success_ip, login_time

Log Parsing Lab

SOC analysts must be able to read raw logs from different source technologies. Select a log source below to see a sample log entry, then parse out the critical fields for investigation.

Select a Log Source

Select a log source above to see a sample entry.

Reading Logs Like a Pro

When you see a raw log for the first time: (1) Find the timestamp -- it anchors everything, (2) Find the source and destination -- who is talking to whom, (3) Find the action/result -- was it allowed, denied, or something else, (4) Find the unique identifier -- event ID, signature ID, rule name. These four fields let you write a basic SIEM query to find all related events.