SEP: Condition Extension in Temporal Correlation Rules

[nasbench]

SEP: Condition Extension in Temporal Correlation Rules

Author(s)

Nasreddine Bencherchali - @nasbench
Ryan Stillions - @rstillio

SEP Type

New Detection Logic (correlation types, aggregation functions)

Abstract

Allow the expression of complex conditions in temporal correlation rules through the condition attribute, maintaining consistency with standard Sigma rule syntax.

Problem Statement

Currently correlations allow only for the expression of positive matches with a logical AND linking.

In cases where we want to express the absence of events for example, the specification and by extension pySigma does not define a clear syntax on how we should do that.

The proposal is for the specification to allow the usage of negation when referencing rules in correlations through a familiar condition attribute that mirrors the approach used in standard Sigma rules.

Use Cases

The main gain is the ability to express detections with a complex condition for example to express the absence of specific events while maintaining a familiar Sigma syntax pattern that doesn't require rule authors to context switch between standard rules and correlation rules.

Detailed Specification

This change will affect the Related rules section and introduce a new condition attribute to the correlation specification.

---

Condition

Attribute: condition

Use: optional

Supported Correlation Types:

The condition attribute is supported for the following correlation types:

• temporal
• temporal_ordered

The condition attribute defines the logical relationship between referenced rules using string-based rule identifiers (names or IDs from the rules attribute).

The condition attribute supports:

• Rule identifiers: References to rules defined in the rules attribute by their name or id.
• Logical operators: and, or, not.
• Parentheses for grouping: () to define operator precedence.

condition: rule_A and not rule_B and rule_C

Important: Conditions reference rule identifiers (strings) defined in the rules section, unlike standard Sigma rules where conditions reference map keys (selections) defined in the detection section.

Negation Behavior for Temporal Correlations:

• For temporal: Rules prefixed with a not keyword in the condition attribute, must NOT produce any matching events within the timespan for the same group-by values. The presence of any negated rule match will exclude that group from the results.

• For temporal_ordered: Rules prefixed with a not keyword in the condition attribute, must NOT produce any matching events within the timespan for the same group-by values. Negated rules do not affect the ordering requirement of positively referenced rules; only the non-negated rules must appear in the specified order.

Examples

Example 1: Temporal Correlation with Negation

title: Correlation - Successful Login Without MFA Verification
id: 7f8e9d6c-5b4a-3c2d-1e0f-9a8b7c6d5e4f
status: experimental
description: Detects successful authentication events that are not followed by MFA verification
author: Nasreddine Bencherchali
date: 2025-12-04
correlation:
    type: temporal
    rules:
        - successful_login
        - mfa_verification
    group-by:
        - User
        - ComputerName
    timespan: 5m
    condition: successful_login and not mfa_verification
falsepositives:
    - Service accounts without MFA
    - Legacy systems
level: medium

Example 2: Temporal Ordered with Multiple Filters

title: Correlation - Process Chain Without Expected Parent
id: 8a9b0c1d-2e3f-4a5b-6c7d-8e9f0a1b2c3d
status: experimental
description: Detects suspicious process execution chain without legitimate parent spawn
author: Nasreddine Bencherchali
date: 2025-12-04
correlation:
    type: temporal_ordered
    rules:
        - high_privilege_process
        - legitimate_parent_spawn
    group-by:
        - ComputerName
        - ProcessId
    timespan: 30s
    condition: high_privilege_process and not legitimate_parent_spawn
falsepositives:
    - Administrative tools
    - Software installers
level: high

Backward Compatibility Impact

As @thomaspatzke suggested.

Regarding backend support I think that this should be supported by most backends that already support the current temporal correlations. To maintain backwards compatibility I would add this internally as separate correlation subtype to pySigma, such that existing backends with temporal correlation support continue to work.

Implementation Areas

• YAML structure changes
• Sigma conversion tools (pySigma)
• Backend updates
• Documentation

Implementation Notes

N/A

Submitter Checklist

• I have searched existing issues and SEPs to avoid duplicates
• I have provided concrete examples and use cases
• I have considered backward compatibility implications
• I have thought about implementation complexity
• I have aligned syntax with existing Sigma conventions

Implementation Assistance

Yes, I can help with the review of the implementation and documentation.

Additional Context

N/A

[Res260]

I like this idea and agree with the proposed implementation

However, I'm not sure that it truely will be backward-compatible with backends. It seems to me like a future update of pysigma that implements this would break existing functionnality. I'm not too sure, though.

[nasbench]

I like this idea and agree with the proposed implementation

However, I'm not sure that it truely will be backward-compatible with backends. It seems to me like a future update of pysigma that implements this would break existing functionnality. I'm not too sure, though.

Yeah I agree. We've discussed this internally but the scope of the implementation has not yet fully developed.

For now since it'll be just a simple negation and not a full scope boolean conditions it shouldn't be that hard to implement nor introduce major changes.

But if it does I will update it and it'll get reflected in the change log.

[pH-T]

I like the idea but I would propose a different yaml syntax:

title: Correlation - Multiple Failed Logins Followed by Successful Login
id: b180ead8-d58f-40b2-ae54-c8940995b9b6
correlation:
    type: temporal_ordered
    rules:
        - name: multiple_failed_login
        - name: successful_login
          not: true
        - id: <some id>
    group-by:
        - User
    timespan: 10m

--> having a "not" before the rule name/id feels a bit wrong to me

[nasbench]

I like the idea but I would propose a different yaml syntax:

title: Correlation - Multiple Failed Logins Followed by Successful Login
id: b180ead8-d58f-40b2-ae54-c8940995b9b6
correlation:
    type: temporal_ordered
    rules:
        - name: multiple_failed_login
        - name: successful_login
          not: true
        - id: <some id>
    group-by:
        - User
    timespan: 10m

--> having a "not" before the rule name/id feels a bit wrong to me

Correlations do not have a condition field hence it's an implied AND. Your suggestion is not sigma like imo.

If we want that explicitly structured then we could add a

condition: and build the actual condition.

condition: rule1 and not rule2

But this would lead to confusion on what's allowed without reading the spec. People can think 1 of and all of. since we're only introducing a not operator for now.

But the structured yaml as you propose it feels un-sigma to me.

[rstillio]

+1 in favor of the idea of adding condition to correlation rules, over using a not modifier expression. Primarily to maintain familiar conventions in correlation rules that we have today in standard rules, so that rule authors aren't having to context switch or memorize growing list of spec nuances and drift between the two.

Here's a contrived temporal that feels more familiar and sigma...ish to me.

title: Correlation - Multiple things must occur and only when a few other things are NOT occurring
id: b180ead8-d58f-40b2-ae54-c8940995b9b6
correlation:
    type: temporal
    rules:
        - name: rule_that_must_occur
        - name: another_rule_that_must_occur
        - id: <another_rule_that_must_occur>
    filter_rules:
        - name: rule_that_must_not_occur
        - id: <another_rule_that_must_not_occur>
    group-by:
        - User
    timespan: 10m
    condition: (rules and not filter_rules)

As you can see, here I suggest a concept of filter_rules + condition (or something similar to it) which makes the filtering more explicit by expressing it in the correlation body and then explicitly constructing it's usage in condition. I believe this is a familiar pattern well established in regular rules.

A contrived temporal_ordered example would look like:

correlation:
   type: temporal_ordered
   rules:
       - name: rule_that_must_occur_first
       - name: rule_that_must_not_occur_inbetween_these_two
       - name: another_rule_that_must_occur_here
       - id: <another_rule_that_must_occur>
       - id: <another_rule_that_must_not_occur_last>
   filter_rules:
       - name: rule_that_must_not_occur_inbetween_these_two
       - id: <another_rule_that_must_not_occur_last>
   group-by:
       - User
   timespan: 10m
   condition: (rules and not filter_rules)

This would also help to better organize large rules, containing groups of filters, e.g., condition: (rules and not filter_rules_*)

I would further suggest that the expression of filter_rules be optional. In other words, if there is no negation needed, you don't have to state the filter_rules or the condition. This is more inline with how Sigma standard rules work and is more familiar to rule authors.

... would need to think through the other correlation types, but putting this out here for initial feedback.

[Res260]

I'm not 100% sure but I'm still leaning on the OP's proposed implementation.

One possible benefit or condition would be the ability to add or later but since we can already do that in normal rules I'm not sure it really adds value.

[thomaspatzke]

I also prefer the full condition proposed by @rstillio and add the default behavior that all rules must appear if no condition is provided, to maintain backwards compatibility.

The implementation for this solution would certainly have the highest effort, but in the end I anticipate that at some point this will be requested anyways.

Regarding backend support I think that this should be supported by most backends that already support the current temporal correlations. To maintain backwards compatibility I would add this internally as separate correlation subtype to pySigma, such that existing backends with temporal correlation support continue to work.

[nasbench]

Hey guys, I have updated the SEP with the proposal from @rstillio with more details and structure. The Detailed Specification section contains what will be written in the spec. If you do have further suggestions, please include them now. Else put a 👍 on this comment to indicate your approval. Once all parties have agreed, I will move on to create a PR for this.

Thank all and thanks to @rstillio for improving on the original condition suggestion.