Skip to main content

​
Correlation Rules

Correlation rules link multiple detections together. They fire when two rules match the same entity within a time window—detecting attack patterns that individual rules miss.

​
Why Correlation?

Single rule detection:
  • ✅ Failed login attempt detected
  • ✅ Successful login detected
  • ❌ Doesn’t connect them as potential credential stuffing
Correlation detection:
  • ✅ Failed login followed by successful login from same IP
  • ✅ Within 5 minutes
  • ✅ High confidence attack pattern

​
How Correlation Works

  1. Rule A fires - e.g., “Failed Login Attempt”
  2. CHAD tracks the entity - e.g., source IP 192.168.1.50
  3. Rule B fires - e.g., “Successful Login”
  4. Same entity within time window - same source IP, within 5 minutes
  5. Correlation alert created - links both detections

​
Creating Correlation Rules

  1. Navigate to Correlation Rules
  2. Click Create Correlation Rule
  3. Configure the rule
  4. Deploy to activate

​
Configuration

FieldDescriptionExample
NameDescriptive titleFailed then Successful Login
Rule AFirst detection ruleFailed Login Attempt
Rule BSecond detection ruleSuccessful Login
Entity FieldField to correlate onsource.ip
Time WindowMaximum time between rules5 minutes
SeverityCorrelation alert severityHigh

​
Entity Field

The entity field determines what “same” means:
Entity FieldCorrelates on
source.ipSame source IP
user.nameSame username
host.nameSame host
process.pidSame process

​
Time Window

How long to wait for Rule B after Rule A:
WindowUse Case
1 minuteRapid attacks (brute force)
5 minutesStandard correlation
15 minutesSlower attack chains
1 hourLong-running attacks
Start with shorter windows and extend if you miss correlations.

​
Example Correlations

​
Credential Stuffing

Rule A: Failed Login Attempt (multiple)
Rule B: Successful Login
Entity: source.ip
Window: 5 minutes
Detects: Attacker tries multiple passwords, eventually succeeds.

​
Lateral Movement

Rule A: RDP Session Started
Rule B: Suspicious Process Execution
Entity: user.name
Window: 15 minutes
Detects: User RDPs to system, then runs suspicious commands.

​
Data Exfiltration

Rule A: Sensitive File Access
Rule B: Large Outbound Transfer
Entity: host.name
Window: 30 minutes
Detects: Sensitive file accessed, followed by data leaving network.

​
Privilege Escalation

Rule A: Standard User Activity
Rule B: Admin Command Execution
Entity: user.name
Window: 10 minutes
Detects: Normal user suddenly executing admin commands.

​
Correlation State

CHAD tracks correlation state per entity: 
Entity: 192.168.1.50
Rule A Matched: 2024-01-15 14:30:00
Waiting for Rule B until: 2024-01-15 14:35:00
If Rule B doesn’t match within the window, state is cleared.

​
Managing Correlation Rules

​
Version Control

Like standard rules, correlation rules have:
  • Full version history
  • Diff view between versions
  • One-click rollback

​
Deploy/Undeploy

Correlation rules must be deployed to be active:
  • Deployed - Actively correlating
  • Undeployed - Saved but inactive

​
Enable/Disable

Temporarily disable without undeploying:
  • Rule remains configured
  • No new correlations created

​
Correlation Alerts

When correlation matches:
  1. New alert created with correlation type
  2. Links to both original alerts (Rule A and B matches)
  3. Severity from correlation rule (often higher)
  4. Full context from both matched logs

​
Investigation

Open a correlation alert to see:
  • Both matched logs
  • Timeline of events
  • Entity that connected them
  • Time between detections

​
Bidirectional Correlation

By default, correlation is directional: A then B. For bidirectional (A then B, or B then A):
  • Create two correlation rules
  • Swap Rule A and Rule B
  • Or use the bidirectional option if available

​
Performance Considerations

Correlation adds overhead:
  • Entity tracking - Memory for pending correlations
  • State management - Database writes for state
  • Time windows - Longer windows = more state
For high-volume environments:
  • Use specific entity fields (not wildcards)
  • Keep time windows reasonable
  • Monitor correlation state table size

​
Best Practices

Begin with obvious correlations (failed → success).
source.ip is better than user.name which can be spoofed.
Start short, extend based on real attack timelines.
Correlations often warrant higher severity than individual rules.
Add descriptions explaining what the correlation detects.

​
Troubleshooting

​
Correlation not firing

  1. Both rules must be deployed
  2. Entity field must exist in both logs
  3. Check time window (Rule B must fire after Rule A within window)
  4. Verify entity values match exactly

​
Too many correlations

  1. Entity field too broad (try more specific)
  2. Time window too long
  3. Base rules fire too frequently

​
State growing large

  1. Reduce time windows
  2. Clean up old correlation state
  3. More specific entity fields

​
Next Steps

Threshold Alerting

Count-based detections

Rule Management

Create base detection rules