First developed as part of our SIEM capability whitepaper, May 2026. Expanded and updated for this site.

Correlation Rules: Connecting the Dots Across Logs

For nine months, the SolarWinds attackers operated undetected. Their trojanized update reached roughly 18,000 customer environments, and in the subset they targeted for follow-on intrusion, they moved laterally, accessed email systems, exfiltrated data, and established persistent backdoors. Individual log sources recorded fragments of this activity: an OAuth token minted here, a federation trust modified there, an unusual service principal accessing Graph API at 3 AM. Each event, viewed in isolation against a single log source, appeared legitimate. Only when you connect events across sources and time -- when you correlate the OAuth anomaly with the trust modification with the off-hours API access on the same identity -- does the pattern emerge as supply-chain compromise rather than routine administration.

SolarWinds was not an intelligence failure. The data existed in logs across multiple environments. It was a correlation failure.

This article covers how correlation rules work, the five pattern types that matter, how to build them, and how to avoid the performance and accuracy traps that turn correlation from a force multiplier into another source of noise.

Why Now

Two forces are converging that make correlation rules non-optional for any organization that takes detection seriously:

CISA BOD 22-01 (Nov 2021): Mandates that federal civilian agencies remediate known exploited vulnerabilities within aggressive timelines. Lateral movement detection feeds directly into KEV-driven remediation -- you cannot patch what you have not detected. Compliance requires cross-source correlation.
Attack sophistication: Nation-state and ransomware groups increasingly operate below single-source detection thresholds. The MOVEit campaign (CVE-2023-34362) used legitimate file-transfer sessions that looked normal in application logs but triggered anomalies only when correlated against network flow and identity telemetry. Living-off-the-land techniques are designed to be invisible to any one log source.

Organizations that rely solely on single-source detection rules are structurally incapable of detecting the most consequential threats within meaningful timeframes.

Why Single-Source Detection Falls Short

A failed login is not an attack. An RDP connection is not lateral movement. A large file transfer is not exfiltration. Each event, viewed in isolation, is likely legitimate.

Consider a concrete example: a user authenticates to VPN from an unusual country. In isolation, this might be travel. Now add: that same user account, within 20 minutes, accesses a file share containing CUI. Still possibly legitimate. Now add: within an hour of that access, a large outbound data transfer hits an external IP never previously contacted. Each event is a minor anomaly in its own log source. Together, they describe credential theft followed by targeted exfiltration.

Correlation rules analyze relationships between events from multiple log sources to identify these multi-step patterns. They are the core capability that distinguishes a SIEM from a log aggregator.

The Five Correlation Pattern Types

1. Sequential Correlation

Events occurring in a specific order within a time window.

Example: Brute force followed by success

50+ failed login attempts from IP X against account Y (authentication logs, within 10 minutes)
Followed by successful login from IP X as account Y (authentication logs)
Followed by access to sensitive resource (application logs, within 30 minutes of success)

Neither the failed logins nor the successful login alone is necessarily malicious. The sequence -- high-volume failure followed by success followed by immediate privilege use -- indicates successful brute-force with immediate objective exploitation.

Time window: Tight (5-30 minutes). Brute-force attackers act quickly once they gain access.

2. Cross-Source Correlation

Events from different log sources sharing a common entity (IP, user, host).

Example: Compromised credential detection

VPN login from unusual geographic location (VPN logs)
Same user accesses file shares containing CUI (file server logs)
Large data transfer to external destination (network flow logs)

Each event comes from a different log source. Only by correlating on the user account across sources does the pattern emerge. This is the pattern that would have flagged the SolarWinds federation-trust manipulation if correlated against the subsequent Graph API calls.

Correlation key: User account (identity-based). The attacker must authenticate somewhere, and that identity links their actions across every system they touch.

3. Threshold Correlation

Event volume exceeding a defined baseline within a window.

Example: Port scanning detection

Single source IP connects to more than 50 unique destination ports on internal hosts within 5 minutes (firewall logs)

Example: Mass file access

Single user account opens more than 500 files in a directory tree within 1 hour (file audit logs)

Threshold correlation is the simplest pattern but also the noisiest. Effective threshold rules require accurate baselines -- what is "normal" for this entity in this environment? A developer machine making 200 connections per minute to build servers is baseline; the same machine making 200 connections to production databases is an anomaly.

4. Absence Correlation

Expected events that do not occur within a defined window.

Example: Missing heartbeat

A critical system that normally generates health-check events every 60 seconds has produced none in 10 minutes (system monitoring)

Example: Missing MFA challenge

User authenticates to high-value system but no MFA challenge event appears in the identity provider logs within the expected window (identity + application logs)

Absence correlation is often overlooked but extremely powerful for detecting evasion. Attackers who disable logging, intercept MFA, or kill monitoring agents create detectable absences in the event stream.

5. Temporal Correlation

Events whose relationship is defined by timing relative to a non-security event.

Example: Insider threat post-resignation

HR system records employee termination notice (HR system, day 0)
Same user authenticates after hours within 14 days of notice (authentication logs)
Same user downloads bulk data from restricted shares within the same session (file audit logs)

Example: Attack immediately following vulnerability disclosure

CVE advisory published for software version running in environment (threat intel feed)
External scanning against the vulnerable service port begins within 24 hours (firewall logs)
Exploit attempt pattern matches the CVE (WAF/IDS logs)

Temporal correlation links security events to business context. The after-hours login is unremarkable in isolation. Correlated against the HR event, it is a high-priority insider-threat indicator.

Building Effective Correlation Rules

Step 1: Define the Attack Story

Start by describing the attack scenario you want to detect:

What is the attacker's goal?
What observable actions must the attacker take?
What log sources would record those actions?
What sequence and timing would distinguish this from legitimate activity?

Map to MITRE ATT&CK techniques. Each technique has documented data sources. If you cannot answer question 3, you have a visibility gap, not a correlation problem.

Step 2: Select the Right Time Window

Attack Type	Typical Window	Rationale
Brute force	5-30 minutes	Automated; speed is the point
Lateral movement	1-4 hours	Attacker needs reconnaissance between hops
Data exfiltration	1-24 hours	Large volumes take time; staging precedes transfer
Insider threat	7-30 days	Behavior change correlates to employment events
Supply chain	30-90 days	SolarWinds-style attacks operate on long timelines

Too short: miss slow attacks. Too long: generate false positives from unrelated events that coincidentally share an entity and window. Start with the "typical window" and tune based on false positive rate.

Step 3: Choose Correlation Keys

The field(s) that link events across sources:

Source IP -- Network-based correlation (useful for external attackers)
User account -- Identity-based correlation (most versatile; survives IP changes)
Hostname/asset -- Asset-based correlation (catches attacks that pivot across accounts)
Session ID -- Session-based correlation (precise but limited to single-session attacks)
Process ID/hash -- Execution-based correlation (malware tracking)

Identity-based keys (user account) are the most robust because attackers can change IPs, rotate sessions, and move across hosts, but they must authenticate as someone.

Step 4: Test Against Historical Data

Before deploying in production, run the correlation rule against 90 days of historical logs:

True positives: Does it catch known-bad activity from past incidents?
False positives: How often do legitimate workflows trigger the pattern?
Volume: How many correlated alerts per day/week?
Performance: Does the rule strain your SIEM's query engine under production load?

If the false positive rate exceeds 10%, adjust thresholds, tighten the time window, add excluding conditions for known-good patterns, or increase the minimum event count.

Step 5: Tune and Maintain

Correlation rules require more tuning than single-source rules because they combine multiple sources of noise. Establish a cadence:

Weekly: Review fires; verify correlation keys are resolving correctly across sources (normalization failures are the #1 cause of correlation rule failure)
Monthly: Review false positive rate; adjust thresholds and windows
After every incident: Did correlation rules detect it? If not, what pattern was missing?

Common Correlation Scenarios

Scenario	Sources	Correlation Logic	Window
Account compromise	Auth + VPN + File	Unusual login location then sensitive data access	1 hour
Malware C2	EDR + DNS + Proxy	Process creation then DNS to known C2 then HTTP POST to rare domain	30 min
Privilege escalation	Auth + AD + Endpoint	Standard user then admin group add then admin action	30 min
Data staging	File + Endpoint + Network	Bulk file copy to temp then compression then outbound transfer	4 hours
Insider threat	HR + Auth + DLP	Resignation notice + after-hours login + bulk download	14 days
Credential stuffing	WAF + Auth + Identity	High-volume login attempts then success then MFA enrollment change	1 hour
Ransomware preparation	EDR + Backup + AD	Shadow copy deletion + backup agent killed + admin credentials used	2 hours

Performance Considerations

Correlation rules consume significantly more compute than single-source rules because they must join events across sources in near-real-time.

State management: Every in-progress correlation rule maintains state -- "I have seen event A from user X; I am waiting for event B within the next 4 hours." If you have 50 correlation rules, each tracking thousands of entities, the state table grows rapidly.

Log normalization: Correlation only works if the same entity is named consistently across sources. If your VPN logs record jsmith@corp.com but your file server logs record CORP\jsmith, the correlation key will not match. Normalization failures are invisible -- the rule simply never fires, and you assume the attack pattern does not exist in your environment.

Throughput: Correlation rules that join high-volume sources (DNS + firewall) against tight time windows consume disproportionate resources. Consider pre-filtering: apply single-source filters first (DNS queries to rare domains only) before feeding into the cross-source join.

Testing Correlation Rules

Testing correlation is harder than testing single-source rules because you must generate events across multiple sources in the correct sequence and timing.

Replay testing: Capture events from known incidents (red team exercises, past breaches) and replay them through the correlation engine. Verify the rule fires at the expected point in the sequence.

Synthetic injection: Generate synthetic events in each source that match the correlation pattern. Verify end-to-end detection within the defined time window.

Break testing: Deliberately omit one event in the sequence. Verify the rule does not fire (absence of one required event should prevent false correlation on the remaining events).

Performance testing: Run the rule against production-volume log rates for 24 hours. Monitor SIEM CPU, memory, and state-table growth. A rule that works in testing but saturates the correlation engine at production volume is worse than no rule.

Key Takeaways

Single-source detection rules cannot detect the most consequential threats (SolarWinds, supply chain, lateral movement) because those attacks span multiple log sources by design
Five correlation patterns cover the attack landscape: sequential, cross-source, threshold, absence, and temporal
Identity-based correlation keys (user accounts) are the most robust because attackers can change IPs and sessions but must authenticate as someone
Time window selection is the primary tuning lever -- too short misses slow attacks, too long generates false positives
Log normalization failures are the silent killer: if entity naming is inconsistent across sources, correlation keys never match and rules never fire
CISA BOD 22-01 mandates remediation timelines that demand detection speed single-source rules structurally cannot deliver
Test correlation rules with replay, synthetic injection, AND break testing before production deployment

Frequently Asked Questions

How many correlation rules should a mature SOC have active?

Quality matters more than quantity. A mature SOC typically runs 20-40 well-tuned correlation rules covering the highest-priority attack patterns mapped to their specific threat model. This is far fewer than the 200-500 single-source detection rules they also run. Each correlation rule is expensive in compute, state management, and tuning effort. Start with 5-10 covering your most critical scenarios (credential compromise, lateral movement, data exfiltration) and expand based on threat model coverage gaps identified through MITRE ATT&CK mapping.

What is the biggest reason correlation rules fail silently?

Log normalization failures. If your VPN logs record usernames as jsmith@corp.com, your Active Directory logs use CORP\jsmith, and your cloud logs show john.smith@corp.com, the correlation engine treats these as three different entities. The rule logic is correct but the join key never matches, so the rule never fires. You assume the attack pattern does not exist. Fix: establish a normalization layer that resolves all identity formats to a canonical form before events reach the correlation engine.

Can correlation rules detect zero-day attacks?

Yes -- this is their primary advantage over indicator-matching rules. Correlation rules detect behavior patterns, not signatures. A zero-day exploit has no known signature, but the post-exploitation behavior (privilege escalation followed by lateral movement followed by data staging) follows recognizable patterns regardless of the initial access technique. Log4Shell (CVE-2021-44228) was caught within minutes by organizations that had correlation rules detecting "inbound web request followed by outbound LDAP/RMI connection from the same host" -- a behavior pattern, not a signature.

How do correlation rules interact with SOAR playbooks?

Correlation rules are the trigger; SOAR playbooks are the response. A correlation rule fires when the multi-source pattern matches. The resulting alert includes all correlated events as context. A SOAR playbook attached to that alert type can automatically execute response steps -- isolate the host, disable the user account, capture forensic data -- with full context from all correlated sources rather than the limited context of a single-source alert.

What is the performance impact of correlation rules on SIEM infrastructure?

Correlation rules consume 5-20x more compute than single-source rules because they maintain state across time windows and join events across sources. A rule correlating DNS (high volume) with authentication (medium volume) across a 4-hour window maintains state entries for every DNS query to a rare domain, waiting for a matching authentication event. At scale, this can consume gigabytes of state memory. Mitigations: pre-filter high-volume sources before correlation (only feed rare-domain DNS into the correlator), use sliding windows rather than fixed windows, and monitor correlation engine resource utilization weekly.

How Advisedly Helps

Advisedly includes pre-built correlation rules covering the most common multi-source attack patterns -- credential compromise, lateral movement, data exfiltration, insider threat, and ransomware preparation -- with full tunability for your environment. The platform normalizes entity identifiers across all ingested log sources automatically, eliminating the silent-failure normalization problem that causes most correlation rules to fail. Cross-source correlation spans SIEM data, vulnerability scans, endpoint telemetry, and compliance data to surface threats that no single source can detect alone. Contact begin@advisedly.ai to see correlation rules in action against your log sources.