What Are Security Correlation Rules?

Most security teams do not choose their detection quality when they choose a SIEM; they choose it in the months afterward, rule by rule. The platform supplies log storage, a query engine, and an alerting pipeline, but the logic that decides which of the day’s millions of events deserve an analyst’s attention lives in correlation rules, and the quality of that rule set is what separates a SIEM that catches a multi-stage intrusion in progress from one that quietly archives the evidence.

This post explains what security correlation rules are and how they work, how they differ from single-event detection rules, the main rule types and the data sources they draw on, the architecture a rule depends on, how correlation engines execute rules at scale, and a set of worked examples with the rule logic sketched out.

What are security correlation rules?

A security correlation rule is a piece of detection logic that relates two or more events, usually from different sources and separated in time, and asserts that together they indicate something no single event does. Ten failed logins are noise; ten failed logins followed by a success from the same address, followed by access to a sensitive share, is a candidate account takeover. The rule is the artifact that encodes that judgment: which events to select, which entity to group them by, how much time may pass between them, what threshold or sequence must be met, and what should happen when it is.

Correlation rules are the workhorse technique of security event correlation, the broader practice of turning a flood of low-level security events into a small set of findings worth acting on. That practice also includes statistical baselines and machine-learning models, but rules remain its backbone because they are precise, transparent, and auditable: an analyst can read a rule and see exactly why an alert fired. The trade-off is equally well known: a rule only catches what someone thought to write, which is why rule sets are living artifacts, seeded from vendor content packs and community repositories, then continuously tuned and retired by detection engineers as the environment and the threats change.

The term is worth separating from its neighbors. A correlation rule is not the platform that runs it (that is the correlation engine, covered below), and it is not any alert-producing logic whatsoever (that is the broader category of detection rules, covered next). It is specifically the stateful, multi-event end of detection logic: the rules whose whole point is the relationship between events.

How security correlation rules work

Whatever the vendor syntax, correlation rules share an anatomy. Walking through it with a running example, the classic brute-force-then-success rule, shows what each part contributes.

The first three clauses scope the rule: which events it sees, how they are grouped into entities, and how far apart in time they may sit.

Selection conditions decide which events the rule looks at, expressed as filters over normalized fields: event category is authentication, outcome is failure or success. Selection is where a rule first touches the data model, and it only works if the field names mean the same thing across sources, which is why normalization is a precondition rather than a nicety.

A grouping key partitions the stream by entity, typically a user, host, IP address, or session. Grouping by source IP and account name means ten failures spread across ten different accounts do not trip a rule meant for ten failures against one account. Choosing the key is choosing what the rule is about.

A time window bounds how far apart the correlated events may be. Windows encode an assumption about attacker tempo: minutes for a brute-force burst, hours for lateral movement, sometimes days for low-and-slow activity. Everything inside the window is candidate state the engine must hold; everything outside it is invisible to the rule.

The remaining three decide what the rule asserts over that scope and what a match sets in motion.

A pattern condition states what must be true across the grouped, windowed events: a count crossing a threshold, a set of distinct values, or an ordered sequence. This is the correlation itself, the assertion that these events together mean something.

Exceptions and suppression carve out the known-benign cases (a vulnerability scanner’s subnet, a service account that legitimately fails often) and throttle repeat firings so one incident does not produce a hundred identical alerts.

Severity and action finish the rule: the priority the finding carries and what the platform does with it, from raising an alert with the matched events attached to opening an incident or triggering an automated playbook.

In a compact generic syntax, the running example looks like this:

rule:     brute-force-then-success
select:   event.category = "authentication"
group_by: source.ip, user.name
window:   10 minutes
pattern:  count(outcome = "failure") >= 10
          followed_by outcome = "success"
exclude:  source.ip in scanner_allowlist
severity: high
action:   create alert, attach matched events

Every clause is a tuning surface, and tuning is where rules earn or lose their keep. Thresholds set too low flood the queue; set too high, they miss the attack they were written for. The stakes of getting this wrong are well documented: in the SANS 2025 Detection and Response Survey, 73% of organizations listed false positives as their number one challenge in threat detection. A correlation rule is never finished so much as currently calibrated.

Correlation rules vs detection rules

The two terms are often used interchangeably, and the vendors do not help: one platform’s “analytics rule” is another’s “correlation search” regardless of what the logic inside does. The useful distinction is not the label but the state. A detection rule, in the broad sense, is any codified logic that turns telemetry into an alert. Many detection rules are single-event: a signature that matches one process-creation event with a suspicious command line, an IDS rule that matches one packet, a match against a threat-intelligence indicator. A correlation rule is the subset of detection rules that must hold state across multiple events, and usually across sources, before it can decide anything.

The boundary matters for two practical reasons. The first is cost: a single-event rule is a stateless filter the engine can evaluate and discard, while a correlation rule obliges the engine to remember partial matches for every active entity in its grouping key, so an ill-considered correlation rule can degrade a platform in a way no signature can. The second is coverage: single-event rules catch the moments an attacker does something individually loud, and correlation rules catch the campaigns whose every step is individually quiet. A rule set needs both layers, but the second is the one that finds the intrusions designed to slip past the first.

Types of security correlation rules

Most correlation rules in production reduce to a handful of shapes. The Sigma correlation rules specification, the open detection format’s vendor-neutral treatment of the same idea, standardizes on nearly the same set, which is a good sign the taxonomy reflects practice rather than one vendor’s menu.

Threshold rules count occurrences of one event type per entity within a window: N failed logins from one source, N denied firewall connections to one port, N DNS queries for domains never seen before. Sigma calls this shape event_count. Thresholds are the simplest correlation and the most sensitive to tuning, because the right N is a property of the environment, not the attack.

Cardinality rules count distinct values rather than occurrences: one source IP failing logins against thirty distinct accounts is password spraying even though no single account crosses a brute-force threshold; one workstation connecting to fifty internal hosts in ten minutes suggests scanning or worm behavior. Sigma’s name for the shape is value_count. Cardinality is often the cheaper and sharper way to express an attack that spreads across entities.

Sequence rules require events in a specific order within the window: a phishing click, then a new process, then an outbound connection. Order is what separates cause from coincidence, and sequence rules are how a chain of individually explainable events becomes a finding. Sigma models both the unordered version (temporal, the events merely co-occur in the window) and the ordered one (temporal_ordered).

Cross-source join rules relate events by a shared entity across different telemetry: the same user signing in from two countries an hour apart (identity plus geolocation), an EDR alert on a host followed by that host’s first connection to a rare external domain (endpoint plus proxy). These are the rules that justify the correlation name most literally, and they lean hardest on normalization, because the join key must mean the same thing in both sources.

Baseline-deviation and risk-accumulation rules blur into statistical territory: fire when an entity’s behavior departs from its own history (an account moving ten times its usual data volume), or accumulate a risk score per entity from many weak signals and alert only when the total crosses a line. Risk-based rules trade the crisp explainability of a single pattern for resilience against attacks that never trip any one rule hard enough to fire it.

The shapes compose. A realistic detection often stacks a cardinality condition inside a sequence, or feeds threshold hits into a risk score. What all five shapes share is the same skeleton from the anatomy section: entity, window, pattern. The craft is in picking the shape that expresses the attacker behavior most directly, because the most direct expression is the one with the fewest knobs to mistune.

Data sources used in security correlation rules

A correlation rule can only relate events it can see, so the reach of the rule set is set by the telemetry feeding it. The sources below are the ones production rules lean on most; the fuller treatment of each event type is in our security event correlation post, so the angle here is what rules key on in each.

Authentication and identity events carry the fields most rules group by: account, source address, outcome, authentication method. Nearly every account-takeover, brute-force, and privilege-abuse rule is built on them, and identity is the join key that stitches most cross-source rules together.

Endpoint and process telemetry from EDR agents and host logs supplies process names, command lines, parent-child process relationships, and file activity. It is the richest source for sequence rules, because an intrusion’s on-host steps are naturally ordered.

Network telemetry (firewall logs, flow records, DNS queries, proxy records) contributes the source, destination, port, and volume fields behind lateral-movement, beaconing, and exfiltration rules, where the relationship between endpoints is itself the signal.

Cloud and SaaS audit logs record control-plane actions: API calls, role assignments, policy changes. Rules over them catch the cloud-native chains (new key created, then used from an unfamiliar address, then permissions enumerated) that never touch a traditional host.

Alerts from other security tools and threat intelligence round out the inputs. Alert-correlation rules treat the outputs of EDR, DLP, and cloud-security tools as events to relate, and threat-intel indicators both enrich events and serve as match conditions. Context sources such as a CMDB or identity provider are not event streams at all, but rules reference them constantly, to weigh a finding by asset criticality or user role.

The recurring dependency across all of these is the schema. A cross-source rule joins on field names, so it exists only where normalization (whether a vendor’s own data model or an open schema such as OCSF or Elastic ECS) has made user.name in an identity log and user.name in a proxy log the same field. Every normalization gap is a correlation the rule set silently cannot express.

Security correlation rule architecture

A rule looks self-contained on the page, but it runs at the top of a stack, and each layer below it shapes what the rule can say.

 The normalization layer parses raw formats into the common schema the rule’s selection conditions and join keys assume. It is the foundation in a literal sense: a rule written against fields the parser does not populate is dead code that reports nothing, which is quieter and worse than an error.

The enrichment layer joins context onto events before rules see them: asset criticality from a CMDB, user role from an identity provider, geolocation for addresses, reputation for domains and hashes. Enrichment is what lets a rule’s conditions and severity reference what an event touches rather than only what it says.

The rule layer itself is a content-management problem as much as a detection one. Rules arrive from vendor content packs, community repositories, and in-house detection engineering, and mature teams manage them as detection-as-code: versioned in a repository, peer-reviewed, tested against replayed logs, and deployed through a pipeline rather than edited live in a console. Formats vary by platform (Splunk Enterprise Security calls them detections, formerly correlation searches; Microsoft Sentinel expresses analytics rules in KQL), and the Sigma format plays the portable role, letting one rule definition compile to many backends, with its correlation extension covering the multi-event shapes described above.

The state store and the output layer belong to the engine: the memory that holds partial matches while windows are open, and the pipeline that turns a fired rule into an alert, an incident, or a playbook run. They are covered next, because how they are built is what decides which rules are affordable.

The layering explains a fact every detection engineer learns early: most rule failures are not logic failures. A rule misses because a parser changed upstream, an enrichment source went stale, or a log source silently stopped flowing, all layers below the rule text. Treating the stack, not the rule file, as the unit that needs monitoring is one of the quieter best practices that separates mature detection programs from rule collections.

How correlation engines execute security rules

The component that evaluates rules is the correlation engine, and its internals deserve their own post; what matters here is the execution model, because it determines a rule’s latency, cost, and failure modes.

Engines execute rules in one of two modes. Streaming evaluation tests each event against active rules as it arrives, maintaining partial-match state in memory: after the tenth failed login, the brute-force rule holds a partial match for that IP-and-account pair and waits for a success or for the window to expire. This is the complex-event-processing lineage, and it is what near-real-time detection requires. Scheduled search instead re-runs the rule as a query over the indexed store every few minutes, which is simpler and easier to backtest but adds up to a scheduling interval of latency and re-scans data the previous run already saw. Most platforms mix the modes, streaming for time-critical rules and scheduled search for expensive joins and retrospective sweeps.

Either way, the engine’s hard problem is state. Every open window for every active grouping-key value is memory the engine must hold and expire correctly, so a rule’s real cost is roughly the product of its window length and its key cardinality. A ten-minute window grouped by account is cheap; a seven-day window grouped by source IP on an internet-facing service is a memory bill, and engines protect themselves with state caps and eviction, which quietly become detection gaps when a rule’s state is evicted mid-pattern. This is why detection engineers treat window length and grouping key as performance decisions, not just logic.

Execution is also where the shape of the underlying store starts to bind. A correlation rule relates events through joins on shared identifiers over what is, in nearly every platform, a flat indexed table, and that works well for the two-to-four-event patterns rules are written in. But the moment a rule fires, the analyst’s next questions outgrow that shape: what else can this account reach, which paths connect the flagged host to sensitive data, which other alerts touch the same identity through some chain of shared infrastructure. Those are relationship traversals, not windowed patterns, and on flat stores each additional hop is another self-join that gets slower and harder to write, which in practice means the questions are answered by hand or not asked.

PuppyGraph addresses that gap from outside the rule pipeline. It is a graph query engine that maps the tables a SIEM’s findings already reference (assets, identities, events, alerts, vulnerabilities) to nodes and edges and runs multi-hop traversals over them where they live, in SQL databases, data warehouses, or data lakes using open table formats like Iceberg, with no ETL into a separate graph database. An analyst investigating a fired rule queries with openCypher (Gremlin is also supported) to walk from the alert’s entities outward: the account’s reachable assets, the paths to crown-jewel data, every alert within two hops of the same credential. Because it compiles a traversal into graph operators executed in its own engine rather than translating it into SQL for the source to run, the deep multi-hop questions stay practical over data that was never modeled as a graph. PuppyGraph is not a SIEM or a correlation engine: it does not ingest event streams and it does not execute detection rules. It is a relationship layer that complements them, turning the entities a fired rule names into a graph the investigation can traverse. This kind of graph layer for security correlation, unified asset inventory, and exposure analysis is used by Palo Alto Networks, Datadog, Netskope, Trend Micro, Sola Security, and Blackpoint Cyber.

Security correlation rule examples

The examples below are the shapes from earlier sections instantiated as concrete rules, each with the logic sketched in the same generic syntax as the anatomy section. The point in every case is that the constituent events are individually unremarkable.

Password spraying. A cardinality rule. No account crosses a brute-force threshold, because the attacker tries one or two passwords against many accounts; the tell is the fan-out from a single source.

rule:     password-spraying
select:   event.category = "authentication" and outcome = "failure"
group_by: source.ip
window:   30 minutes
pattern:  distinct_count(user.name) >= 30
severity: high

Impossible travel. A cross-source join through enrichment. Two successful sign-ins, each fine alone, become a high-confidence signal when geolocation and timestamps say no airplane connects them. The tuning work is almost entirely in the exclusions, because VPN egress points and cloud proxies produce the same pattern legitimately.

rule:     impossible-travel
select:   event.category = "authentication" and outcome = "success"
enrich:   geo = geolocate(source.ip)
group_by: user.name
window:   1 hour
pattern:  pair of sign-ins where distance(geo) / time_between > 800 km/h
exclude:  source.ip in vpn_and_proxy_ranges
severity: medium

Privilege escalation followed by exfiltration. An ordered sequence across identity and network telemetry, joined on the account. A role grant is legitimate on its own and a large transfer is just traffic; the order, the shared account, and the deviation from that account’s own baseline are what make it a finding.

rule:     escalation-then-exfiltration
select:   identity change events, outbound network flows
group_by: user.name
window:   24 hours
pattern:  sequence(
            privilege_grant to elevated role,
            outbound_bytes > 10x account 30-day baseline
          )
severity: critical

Ransomware precursors. An endpoint sequence per host: mass file modification together with the command that deletes volume shadow copies, a common step ransomware takes to block recovery. The window is short because the behavior is a burst, and severity is set to page rather than queue.

rule:     ransomware-precursors
select:   endpoint file and process events
group_by: host.name
window:   15 minutes
pattern:  count(file_modify across distinct directories) >= 500
          and process.command_line matches shadow_copy_deletion
severity: critical

Read as a set, the examples repeat one lesson. Each rule is a small assertion about entities, order, and time, and what makes it fire reliably in production is rarely the pattern clause; it is the layers underneath, the normalization that makes user.name mean one thing, the enrichment that supplies geolocation and baselines, and the exclusions that encode what is normal for this environment. Writing the rule is an afternoon; making it true is the program.

Conclusion

Security correlation rules are where a detection program’s intent becomes executable: small, auditable assertions that certain events, grouped by an entity and bounded by a window, mean more together than apart. They sit one level below the practice of security event correlation and one level above the engine that executes them, and their quality is decided less by the pattern clause than by the stack underneath it, the normalization, enrichment, and tuning that make the same rule text sharp in one environment and noisy in another.

The through-line is relationships. A rule encodes a known relationship between a few events in advance; the investigation that follows a fired rule chases relationships no rule anticipated, across accounts, hosts, alerts, and data. Try the forever-free PuppyGraph Developer Edition and book a demo with the team to see how openCypher and Gremlin queries run over warehouse and lakehouse tables, with no graph-specific ETL, alongside the correlation rules your SIEM already executes.