Simple definition
A correlation rule is a rule that evaluates related security events or signals together to detect a pattern, sequence, threshold, or combination of conditions that is more meaningful than any single event by itself.
Correlation rules are commonly used in SIEM platforms to connect activity across identity, endpoint, network, cloud, application, asset, and threat-intelligence data.
What does a correlation rule do?
A correlation rule transforms separate pieces of security telemetry into a higher-level signal that analysts can investigate.
Connect multiple data sources
Combines events from identity, endpoint, network, cloud, application, or threat-intelligence sources.
Detect sequences
Looks for a meaningful order of activity, such as repeated failures followed by a successful login.
Apply thresholds
Triggers when the number, frequency, or concentration of events crosses a defined threshold.
Add user and asset context
Uses identity, asset, risk, or business context to make a pattern more meaningful.
Apply exclusions
Suppresses known benign activity, service accounts, expected scanners, or approved behavior.
Create a security signal
Produces an alert, incident, notable event, risk change, or response action when conditions are met.
Why correlation rules matter
Many attacks are made up of several small actions. Each action may look normal in isolation, but the combination can reveal suspicious behavior.
- Helps detect multi-stage behavior that single-event rules may miss.
- Connects activity across identities, assets, and security domains.
- Reduces analyst effort by presenting a more meaningful security pattern.
- Supports risk-based detection by combining signals over time.
- Makes security detections more context-aware when normalized asset and identity data is available.
- Can trigger automated actions after a higher-confidence pattern is detected.
How a correlation rule works
Define the security use case
Start with the behavior or risk the rule is intended to identify.
Identify required data
Determine which logs, fields, identities, assets, or threat-intelligence sources are needed.
Normalize and enrich the events
Use consistent fields and add context so events from different sources can be compared.
Write the correlation logic
Define the sequence, threshold, grouping, time window, filters, or relationships that represent suspicious activity.
Configure alert behavior
Decide what happens when the rule matches, including severity, grouping, incident creation, or automation.
Test and tune
Validate the rule with representative data and adjust thresholds or exclusions to control false positives.
Common correlation rule examples
Failed logins followed by success
Correlates repeated authentication failures with a later successful login for the same user or asset.
Identity plus endpoint risk
Connects a high-risk user with suspicious endpoint activity to raise detection confidence.
Cloud privilege change
Combines a privilege modification with unusual access or activity from the affected identity.
Threat-intelligence match
Correlates network, DNS, proxy, or endpoint events with known malicious indicators.
Malware concentration
Detects when the same malware or indicator appears across many systems in a defined period.
Impossible or unusual access
Combines login events, geography, device, or identity context to identify suspicious access patterns.
Key components of a correlation rule
Data sources
The events, tables, indexes, data models, or telemetry needed for the detection.
Field relationships
The user, IP address, hostname, process, indicator, session, application, or other fields used to connect activity.
Time window
The period in which related events must occur to be considered part of the same pattern.
Threshold
The count, frequency, or risk level required before the rule creates a security signal.
Filters and exceptions
Conditions that exclude expected or low-value activity from the result.
Response action
The alert, incident, risk update, ticket, or automated action produced after the rule matches.
Correlation rule vs detection rule
| Term | Primary focus | Typical example |
|---|---|---|
| Detection Rule | Identifies suspicious activity using defined logic. It may use one event, many events, behavior, thresholds, or correlations. | Alert when a sensitive command executes on an endpoint. |
| Correlation Rule | Specifically connects multiple related events, signals, or contextual data to identify a larger pattern. | Multiple failed logins followed by success from a new device. |
| Event Correlation | The broader process of connecting related events so they can be analyzed as one security pattern. | Grouping network, identity, and endpoint activity around the same entity. |
Correlation rule tuning considerations
Threshold selection
Thresholds should separate meaningful behavior from expected baseline activity.
Lookback and scheduling
The rule schedule and time window need to match how quickly the behavior occurs.
Entity grouping
Events should be grouped around the correct user, asset, IP, process, or other entity.
Suppression
Known benign patterns should be excluded carefully without hiding true security activity.
Data consistency
Field mapping and normalization must be reliable enough to connect events from different sources.
Validation
Test with known scenarios and review results with analysts before enabling production alerting.
Benefits and common problems
Benefits
- Detects larger patterns across security data.
- Adds context and improves alert quality.
- Supports cross-domain and risk-based analytics.
- Can reduce the number of isolated alerts analysts must review.
- Enables automated response for higher-confidence detections.
Common problems
- Missing or inconsistent fields break event relationships.
- Overly broad thresholds create alert fatigue.
- Short lookback windows can miss slow activity.
- Poor exclusions hide real incidents or create noise.
- Changes in log sources can silently weaken correlation logic.
How ForshTec helps with correlation rules and SIEM detection content
ForshTec helps security teams and vendors design detection-ready data pipelines, normalized schemas, SIEM content, and production detection workflows.
- Correlation rule and detection use-case design
- SIEM query and analytics development
- Data-source and field requirement analysis
- ECS, OCSF, CIM, and platform-specific normalization
- Rule tuning, validation, documentation, and ATT&CK mapping
- Connector and parser engineering for reliable security telemetry
Need better correlation across your security data?
ForshTec can help build the data and detection layers required for reliable SIEM correlation.
Talk to ForshTecFAQs
What is a correlation rule?
A correlation rule connects multiple related events, signals, entities, or conditions to detect a larger security pattern that may indicate suspicious activity.
How is a correlation rule different from a detection rule?
A detection rule is a broad category of security analytics. A correlation rule is a type of detection logic focused on combining multiple events, signals, or contextual conditions.
Can correlation rules use multiple data sources?
Yes. Correlation rules commonly combine identity, endpoint, network, cloud, asset, and threat-intelligence data when the fields are consistent enough to connect the activity.
What is a time window in a correlation rule?
The time window defines how close related events must occur for the rule to treat them as part of the same pattern.
Why do correlation rules create false positives?
False positives can result from poor thresholds, incomplete context, broad conditions, expected business activity, or weak exclusions.
What makes a correlation rule production-ready?
A production-ready rule needs reliable telemetry, normalized fields, tested logic, appropriate thresholds, useful context, clear alert metadata, and ongoing tuning.