[BUG] Security analytics plugin ignores service property of logsource and generates false positives for service-specific Sigma rules

[belendax]

What is the bug?
The security analytics plugin is converting the logsource input into pre-defined categories and ignoring the service property of the logsource, resulting in a high number of false positives when applying service-specific Sigma rules.

How can one reproduce the bug?
Steps to reproduce the behavior:
Apply a Sigma rule that is service-specific and should only apply to a particular log source. For example, the zeek_rdp_public_listener.yml rule that should check the "id.orig_h" field in the zeek rdp.log file.
You can see the same rule applies to the other zeek log sources such as files.log that share the same filed defined in the rule condition as the targeted log source. (in this case, the "id.orig_h" field).

What is the expected behavior?
The plugin should support service-specific rules and only apply them to the relevant log source of that service in a specific product.

What is your host/environment?

• OS: Ubuntu 22.04
• Version 2.6.0
• Plugins

Do you have any screenshots?
No

Do you have any additional context?
The zeek_rdp_public_listener.yml rule is provided as an example of a service-specific rule that is affected by the bug. False positives generated by the incorrect application of service-specific rules can cause a significant amount of noise for security analysts and impact the overall effectiveness of the security analytics plugin.

[petardz]

UX improvement would make sense here to make selection of service specific rules easier. @getsaurabh02

[getsaurabh02]

@belendax Do we think that providing a sub category within the log sources, for every client or service would simplify the selection and application of rules?
cc: @amsiglan

[jimishs]

This is a valid concern especially if users want to create or use existing rules that should be run only on specific services. Im sharing this with the team. We want to balance the simplicity of the rules with ability to use relevant features of Sigma. If you have any ideas on how to solve this without adding more rule creation complexity, i would love to hear that. Thanks