Extended Correlation Support in V2

[nzedler]

I'm coming from a Graylog background where the correlation engine supports the following methods:

1. Rule A triggers at least X times
2. (optional) AND Rule B doesn't trigger AND followed by Rule C
3. (optional) AND Rule D doesn't trigger in the next Y timespan
4. (optional) AND Rule E triggers at least Z times
5. etc.

Using the latest V2 specs the optional scenarios are not possible (at least from my understanding) without creating separate Sigma sub-rules, especially when the counting should differ from rule to rule.

Is it intention that such correlations are not possible in one single rule, probably for compatibility for other SIEM systems?

[Res260]

What would be an example rule with such logic? I don't see what links Rule A B C D and E together

[nzedler]

Let's use the official example of Failed Logins Followed by Successful Login:

This is the official spec:

title: Correlation - Multiple Failed Logins Followed by Successful Login
id: b180ead8-d58f-40b2-ae54-c8940995b9b6
status: experimental
description: Detects multiple failed logins by a single user followed by a successful login of that user
references:
    - https://reference.com
author: Florian Roth (Nextron Systems)
date: 2023-06-16
correlation:
   type: temporal_ordered
   rules:
    - multiple_failed_login
    - successful_login
   group-by:
    - User
   timespan: 10m
falsepositives:
    - Unlikely
level: high
---
title: Multiple failed logons
id: a8418a5a-5fc4-46b5-b23b-6c73beb19d41
description: Detects multiple failed logins within a certain amount of time
name: multiple_failed_login
correlation:
  type: event_count
  rules:
    - failed_login
  group-by:
    - User
  timespan: 10m
  condition:
    gte: 10
---
title: Single failed login
id: 53ba33fd-3a50-4468-a5ef-c583635cfa92
name: failed_login
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID:
      - 529
      - 4625
  condition: selection
---
title: Successful login
id: 4d0a2c83-c62c-4ed4-b475-c7e23a9269b8
description: Detects a successful login
name: successful_login
logsource:
  product: windows
  service: security
detection:
  selection:
      EventID:
        - 528
        - 4624
  condition: selection

What the Graylog Correlation Engine could do is the following (not Sigma spec conform):

title: Correlation - Multiple Failed Logins Followed by Successful Login
id: b180ead8-d58f-40b2-ae54-c8940995b9b6
status: experimental
description: Detects multiple failed logins by a single user followed by a successful login of that user
references:
    - https://reference.com
author: Florian Roth (Nextron Systems)
date: 2023-06-16
correlation:
   type: temporal_ordered
   rules:
    - failed_login:
      condition:  # <-- Graylog uses per rule counts
        gte: 10
    - successful_login:
      condition:  # <-- Graylog uses per rule counts
        gte: 1
   group-by:
    - User
   timespan: 10m
falsepositives:
    - Unlikely
level: high
---
title: Single failed login
id: 53ba33fd-3a50-4468-a5ef-c583635cfa92
name: failed_login
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID:
      - 529
      - 4625
  condition: selection
---
title: Successful login
id: 4d0a2c83-c62c-4ed4-b475-c7e23a9269b8
description: Detects a successful login
name: successful_login
logsource:
  product: windows
  service: security
detection:
  selection:
      EventID:
        - 528
        - 4624
  condition: selection

What I'm saying is that sub correlations like "Multiple failed logons" are not needed in Graylogs case. Depending on the capablities of other SIEM systems correllation engines (non-EQL and non-Lucene), this would make sense to me to include in the specs.

[nzedler]

An example for Rule A triggers at least X times AND Rule B doesn't trigger AND followed by Rule C could be the an permission escalation scenario ">1 successful login event followed by 0 no log out events followed by >1 successful root login". This could simply be done with this schema:

title: Permission Escalation
correlation:
   type: temporal_ordered
   rules:
    - successful_login:
      condition:
        gte: 1
    - successful_logout:
      condition:
        eq: 0
    - successful_root_login:
      condition:
        gte: 1
   group-by:
    - User
   timespan: 10h
falsepositives:
    - Unlikely
level: high
---
# ... the rules 'successful_login', 'successful_logout', 'successful_root_login'