Sigma correlations support: Event Count

[YamatoSecurity]

@fukusuket Here is a (maybe) hard one for you. I'd like to start supporting sigma correlations starting with Event Count and Value Count types since we already have the logic for those with | count. We should probably start with Event Count as that is the easiest.

Both are explained here: https://github.com/SigmaHQ/sigma-specification/blob/version_2/Sigma_meta_rules.md

Event Count sample:

title: Many failed logins to the same computer
id: 0e95725d-7320-415d-80f7-004da920fc11
correlation:
  type: event_count
  rules:
    - e87bd730-df45-4ae9-85de-6c75369c5d29 # Logon Failure (Wrong Password)
    - 8afa97ce-a217-4f7c-aced-3e320a57756d # Logon Failure (User Does Not Exist)
  group-by:
    - Computer
  timespan: 5m
  condition:
    gte: 3

This is example uses multiple rules but at first we can just support one rule if that is easier.
Or you could create a generic rule with a new ID and the following logic to test:

logsource:
    product: windows
    service: security
detection:
    selection:
        Channel: Security
        EventID: 4625

This just detects any failed logon.

I think this should be the same as the following count rule:

logsource:
    product: windows
    service: security
detection:
    selection:
        Channel: Security
        EventID: 4625
    condition: selection | count() by Computer >= 3 
    timeframe: 5m

If there a 3 or more failed logons to the same Computer, then there will be an alert.

Things to consider:

• There may be multiple rules... If it is difficult to implement checking multiple conditions from multiple rules then we might want to just start off by supporting one rule
• Rules may be defined by name instead of ID so we need a way to look this up internally. Info: https://github.com/SigmaHQ/sigma-specification/blob/version_2/Sigma_meta_rules.md#related-rules
• There may be multiple fields in group-by. I believe this means that, for example if Computer and IpAddress were defined in group-by then if the combination of the same ComputerName AND the same IpAddress reaches 3 or more, then we should give an alert.

[fukusuket]

Sounds very difficult :) But I would love to implement it!!💪

[fukusuket]

Current impl memo:

Related Struct

• rule/mode.rs:RuleNode#L29
  • rule/mode.rs:DetectionNode#L144
    • rule/selectionnodes.rs:SelectionNode#L11
    • rule/aggregation_parser.rs:AggregationParseInfo#L122
      • pub _field_name: Option<String>
      • pub _by_field_name: Option<String>
      • pub _cmp_op: AggregationConditionToken
      • pub _cmp_num: i64
    • count.rs#TimeFrameInfo

Related Sequense

• main.rs#L1405
  • detection.rs#parse_rule_files
    • yaml.rs#read_dir
    • mode.rs#RuleNode.init
      • mod.rs#DetectionNode.init#ConditionCompiler
      • mod.rs#DetectionNode.init#AggegationConditionCompiler

[fukusuket]

New impl memo:

Related Sequence

rule parse

• parse_rule_files
  • skip correlation rule init
    • mode.rs#RuleNode.init
• parse_correlation_rule_files(Vec<RuleNode>) -> Vec<RuleNode>
  • Vec<RuleNode>
  • ↓ partition(correlation)
  • Vec<RuleNode>,Vec<RuleNode>
    • RuleNode
    • ↓ map (RuleNode.yaml)
    • RuleNode
      • OrSelectionNode?
      • AggregationParseInfo
      • TimeFrameInfo
• same sequence as is ?

func

• compile_correlation_rule(Yaml, Vec<RuleNode>) -> DetectionNode
  • merge_related_rules(Vec<RuleNode>) -> DetectionNode

Error condition

• Related rules does not exists in rule directory
• Related rules support Only List
• Correlation type except for event_count
• Grouping support Only Map(not List) ... maybe
• Condition support Only Map(not List)
• does not support (in first PR)
  • Recursive Correlation
  • Multiple yaml in one file