Sigma 2.1 Correlation Rules
Understand Sigma 2.1 correlation as stateful reasoning over related events, with explicit aliases, grouping, windows, order, cardinality, and backend limits.
Correlation starts with well-defined event selections
A correlation rule does not repair ambiguous source rules. Each referenced event selection should state the behavior and evidence it recognizes. If one rule’s user means actor and another’s means target, grouping them by user can create a persuasive but false sequence.
Sigma 2.1 correlation rules describe relationships among event selections or rules. They can express counts, distinct-value counts, temporal relationships, and ordered temporal relationships. The correlation layer adds a new claim beyond any individual match.
Document the source rule identity and version, log source, required fields, event time, entity roles, and expected match granularity. A source rule that emits several matches for one underlying action can inflate correlation unless deduplication is defined.
Counts need populations, keys, and boundaries
An event-count correlation asks whether matches exceed a threshold within a period and grouping. A value-count correlation asks whether enough distinct values appear. Ten failures by one user is different from ten failures across a tenant.
State the grouping key, namespace, threshold rationale, duplicate policy, and window boundaries. Distinct values need normalization rules: case, null, aliases, and recycled identifiers can change cardinality.
Test just below, at, and above the threshold; events at both window edges; duplicates; missing keys; and activity split across entities. A threshold chosen only to reduce alert volume is a tuning decision, not evidence that the number is inherently malicious.
Temporal correlation needs a clock model
A temporal relationship says events occur within a period. Ordered temporal correlation also requires sequence. Decide whether event, observation, or ingestion time drives the order and how clock drift and late arrival are handled.
Aliases align equivalent entity roles across different event schemas. They should map meaning, not convenient names. A source address in one rule may not represent the same entity as a device address in another. Record alias type, namespace, and source fields.
Overlapping sequences need policy. One first event can pair with several later events; concurrent sessions for one user can interleave. State whether the engine emits every combination, one result per entity, or consumes events after a match.
Backend support determines executable meaning
A target may lack ordered correlation, value cardinality, alias support, or sufficient state. A converter can approximate the rule with scheduled searches, joins, or aggregations, but the approximation may change overlap, lateness, or output.
Use portable intent and backend semantics to compare the source claim with the emitted implementation. Treat unsupported features as scope decisions. Do not label an unordered count as equivalent to an ordered sequence.
Measure state cost and high-cardinality grouping. A correct rule that exhausts backend limits can drop state or delay results. Performance testing is part of semantic assurance when resource pressure changes what gets evaluated.
Make the correlated result explainable
The alert should carry the source matches, event identifiers and times, grouping entity, aliases used, window, order, threshold or cardinality, late-data status, correlation version, and source health. The analyst should see why the engine treated the events as one behavior.
State the bounded assessment. The same identity performed a new grant and accessed the protected resource within the tested interval under a shared tenant and application relation. That supports review; it does not automatically prove malicious intent.
Correlation is valuable because relationships can make weak observations meaningful. It is dangerous when state and joins disappear behind a single severity label. Preserve the chain that earned the higher-level claim.
Frequently asked questions
Why is a Sigma correlation rule more than several rules joined together?
Because it adds state and relationship semantics: which events qualify, how fields align, which entity groups them, what time means, whether order matters, and when a result is emitted.
