SIEM and Alert Correlation

A Security Information and Event Management system aggregates logs from across the entire environment — endpoints, network devices, cloud services, identity platforms — and applies correlation rules to surface potential threats. The challenge is that a single attack generates dozens of alerts across different systems. The analyst's job is to correlate these into a coherent attack timeline.

Alert correlation is the core analytical skill of a SOC analyst. It transforms individual data points — a failed login here, a suspicious process there, an unusual outbound connection — into a unified understanding of what the attacker did, in what order, and where they are now. This synthesis skill is what separates an analyst who can investigate from one who can only respond to pre-configured alerts.

Why Correlation Requires Multiple Sources

Each SIEM data source has a narrow window of visibility. The email gateway sees delivery and clicks but not what the process did after executing the attachment. The endpoint EDR sees process execution and file creation but not the network traffic to C2. The firewall sees the outbound connection but not which process on which endpoint made it. The identity platform sees authentication events but not what the authenticated session accessed. Only by joining all four sources on the common fields — timestamp, username, hostname, IP — does the complete attack chain emerge.

This is not a limitation to be overcome with better tools. It is the fundamental architecture of modern enterprise IT: different systems log different things, and the attacker's trail runs through all of them. The analyst who can correlate across all sources is the analyst who catches attacks that single-source rules miss entirely.

SIEM Data Sources

Identity    Azure AD, Active Directory -- logon events, MFA, privilege changes
Endpoint    EDR, Sysmon, Windows Events -- process, file, registry, DLL activity
Network     Firewall, proxy, DNS, NetFlow -- connections, traffic patterns
Email       Mail gateway -- phishing delivery, link clicks, attachment activity
Cloud       AWS CloudTrail, Azure Activity Log -- API calls, config changes
Application Web app logs, database audit, API gateways

SIEM Correlation in Practice

09:14  [EMAIL]    Phishing email delivered to j.smith@corp.com
09:22  [PROXY]    j.smith clicks link: malicious-site.xyz/invoice.html
09:23  [PROXY]    payload.exe downloaded from malicious-site.xyz
09:24  [ENDPOINT] New process: payload.exe spawned by chrome.exe
09:25  [ENDPOINT] Encoded PowerShell executed (C2 staging)
09:26  [FIREWALL] Outbound: CORP-WS-022 to 185.220.101.45:443 ESTABLISHED
09:26  [ENDPOINT] Persistence: HKCU Run key created
# Six separate source-specific alerts. Joined on j.smith + CORP-WS-022 + timestamp:
# One complete phishing-to-C2-to-persistence chain -- 12 minutes start to finish

# Splunk SPL -- impossible travel detection across Azure AD sign-in logs:
index=auth sourcetype=azure_ad EventType=Signin
| stats values(Country) as countries values(src_ip) as ips
        earliest(_time) as first latest(_time) as last by user
| where mvcount(countries) > 1
| eval time_diff = last - first
| where time_diff < 3600
| table user countries ips time_diff
# Fires when same user logs in from 2+ countries within 1 hour
# Severity: High -- near-certain account compromise

Initial Access    T1566.001  Spearphishing Attachment
Execution         T1059.001  PowerShell (encoded command, -enc flag)
Persistence       T1547.001  Registry Run Keys (HKCU\...\Run)
C2                T1071.001  Web Protocols (HTTPS port 443)
Lateral Movement  T1021.002  SMB / Windows Admin Shares (PsExec/lateral)

14 May 2026 -- Incident INC-2026-047

09:14:33  Phishing email delivered to j.smith (mail gateway)
09:22:01  j.smith clicks embedded link (proxy log)
09:23:44  payload.exe downloaded from malicious-site.xyz (proxy + endpoint)
09:24:12  payload.exe executed; parent: chrome.exe (Sysmon Event 1)
09:25:01  Encoded PowerShell: C2 beacon established to 185.220.101.45
09:26:18  Outbound HTTPS to 185.220.101.45:443 ESTABLISHED (firewall)
09:26:55  HKCU Run key: WindowsUpdate persistence (Sysmon Event 13)
10:14:22  RDP lateral movement to CORP-SRV-02 (Event 4624 Type 10)

Critical  Active ransomware / confirmed data exfiltration / domain compromise
          SLA: 15-minute response, CISO notification, crisis team activated

High      Active C2 beacon / lateral movement confirmed / privileged account compromise
          SLA: 1-hour response, security manager notification, IR playbook initiated

Medium    Phishing delivered (no click confirmed) / policy violation / anomalous behaviour
          SLA: 4-hour response, analyst investigation, potential escalation

Low      Blocked attempt / informational alert / single failed login
          SLA: Next business day, log and continue monitoring

What You Need to Know

Writing Effective Correlation Rules

Correlation rules are the automation layer that makes a SIEM more than a log storage system. A well-designed rule fires reliably on real attacks, rarely on legitimate activity, and when it fires, provides enough context for an analyst to make an immediate triage decision without additional investigation. A poorly designed rule either floods the queue with false positives (training analysts to ignore it) or misses attacks entirely through over-specificity.

The balance between sensitivity and specificity is the central challenge of rule design. Rules should be specific enough to have low false positive rates — but not so specific that they only catch one historical attack and miss all variants. The best rules are written at the behavioural level (technique) rather than the indicator level (specific IP or hash), because techniques persist while indicators rotate.

// Microsoft Sentinel KQL -- multi-source C2 detection
// Requires: encoded PowerShell on endpoint AND outbound HTTPS to new external IP
let endpoint_events = SecurityEvent
| where EventID == 4688
| where CommandLine has "-enc" or CommandLine has "-EncodedCommand"
| project TimeGenerated, Computer, Account, CommandLine;

let firewall_events = AzureFirewallNetworkRule
| where Action == "Allow" and DestinationPort == "443"
| where DestinationIP !startswith "10." and DestinationIP !startswith "172."
| project TimeGenerated, SourceIP, DestinationIP;

endpoint_events
| join kind=inner (firewall_events) on $left.Computer == $right.SourceIP
| where abs(datetime_diff('minute', TimeGenerated, TimeGenerated1)) < 5
| project TimeGenerated, Computer, Account, CommandLine, DestinationIP
// Fires only when: encoded PowerShell runs AND outbound HTTPS follows within 5 minutes
// Both signals required -- dramatically reduces false positives from either alone

MITRE ATT&CK as a Detection Coverage Map

MITRE ATT&CK is most useful not just as a labelling system for incidents, but as a structured map for identifying where your detection coverage has gaps. For each tactic in the kill chain, mapping your current SIEM rules to ATT&CK technique IDs reveals which techniques you can detect and — critically — which techniques an attacker could use in your environment without triggering any alert.

Professional Incident Report Structure

The incident timeline is necessary but not sufficient as a deliverable. A professional incident report contextualises the timeline for different audiences — technical (what happened and how), management (business impact and remediation status), and legal (evidence chain and liability assessment). Writing for multiple audiences from a single investigation is a core analyst skill.

Multi-Source Correlation — Full Kill Chain Investigation

Core Concepts Summary