Reference to other rules in the condition of a detection

[Res260]

Hello (again), I'm (still) building a custom backend for QRadar and I sometimes get roadblocks related to limitations in the Sigma specification. Now I know my usecase stretches a bit what Sigma was built for, my use case being to use Sigma as part of a complete detection-as-code pipeline, where rules are versionned in a git repo, reviewed, then automatically converted to the target SIEM and deployed automatically. So, this is only a suggestion that, I think, could help with this use-case, I understand if you think this would not fit within the Sigma spec.

I'd like to be able to reference another rule in the condition section of a sigma detection, such as:

title: Test rule2
status: stable
logsource:
  product: Something
detection:
  selection:
    somefield: somevalue
  condition: selection and ($rule:Some Other Rule Name)

Where the rule Some other rule name would be in a different file, possibly.

I'm aware that Rule Collections exist, but there are two limitations that prevent me from using this:

1. They need to be in the same yaml document
2. They create an independant rule (in the parsed SigmaRule, there is no reference that this rule was built from another rule part ), which can't be used to re-use parts of detections in the SIEM.

My use case is QRadar's Building Blocks (BBs), a detection rule that is meant to be reused with other rules. For performance reasons, I'd like to reproduce this behavior with sigma, but right now, my solution is to break the specification with something like:

title: Test rule2
status: stable
logsource:
  product: Something
detection:
  selection:
    somefield: somevalue
  selection2:
    BB: NameOfTheRule
  condition: selection and (selection2)

I'll keep my solution if my idea is not a good fit for Sigma, but I'd like to stay as close as the specification as possible :)

[frack113]

Can you check https://github.com/SigmaHQ/sigma-specification ?

https://github.com/SigmaHQ/sigma-specification/blob/main/wip/Sigma_Correlations.md

[Neo23x0]

@frack113 He already mentioned that he has checked the specifications and the correlations and couldn't find coverage for his use case

@Res260 We don't want references from one rule to another because it's a PITA when handling the rules. The advantages of not having rules referencing to each other in conditions clearly outweigh the few disadvantages and rare corner cases like yours.

[Res260]

I understand, thanks for your reply!

[Neo23x0]

I wonder if you could do what you want to do with an additional field, because the specification allows for additional custom fields on the root level of the rules.

e.g.

title: Test rule2
status: stable
logsource:
  product: Something
detection:
  selection:
    somefield: somevalue
  condition: selection and (selection2)
import_rules:
   rules: 
      - NameOfTheRule
   append_condition: 'and NameOfTheRule'

[Res260]

That could be a solution, but I think I would have to modify code in pysigma related to the parsing of a SigmaDetection so the backend can properly parse the added stuff, unless I'm missing something...

[Neo23x0]

Don't you have to do that anyways with your solution?

[Res260]

No, I need to modify my backend, not pysigma itself. Right now, my backend uses the official pysigma, I don't have to maintain a fork of it for the backend to work. I only have to add conditions in the backend for the edge cases. I'm not sure I'd be able to do that if the way SigmaDetection is parsed would change.

[Neo23x0]

@thomaspatzke

[thomaspatzke]

Hi! There could be a solution path in pySigma that doesn't requires to modify it directly, just build some code around it. I've not verified if this works, but the idea is:

1. Introducing an additional field with the reference to a rule.
2. The detections of the referenced rule are merged into the detections of the consolidated rule by throwing them together into the detections dict of the rules SigmaDetections object located in SigmaRule.detection.
3. The rule condition then doesn't refers to the rule, but to detection items or does some generic ... and not 1 of filter* that then includes arbitrary detections that start with filter in their identifier. Condition parts can also be added with the AddConditionTransformation from a processing pipeline. An additional processing pipeline condition could also make this dependend on a custom Sigma attribute value etc.
4. The remaining stuff is then done by the standard pySigma conversion logic.

@Res260 We don't want references from one rule to another because it's a PITA when handling the rules. The advantages of not having rules referencing to each other in conditions clearly outweigh the few disadvantages and rare corner cases like yours.

@Neo23x0 correlations will have this PITA anyways 😉 Correlation rules will reference other rules (that must not necessarily reside in the same file) in a rule set and a rule can also be referenced multiple times. I've added this intentionally to the correlations spec to keep core Sigma as simple as it is. This means also that they will also overcome the limitation @Res260 mentioned with rule collections. I'm considering to add the idea from @Res260 as additional correlation type. It's relative simple compared to the other stuff contained in the spec and I think it could get an elegant way to solve the false positive problem at least partially.

[Res260]

Would the proposal allow to express a condition like the normal sigma does? Like (rule1 or rule2) and not exclusion_rule?

[thomaspatzke]

Because it fits more appropriately in it I move this discussion as an enhancement issue to the Sigma specification repository and make a proposal to the next iteration of the correlations specification.