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

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.

Start by tracing how the security analytics plugin converts Sigma rule logsource data, using zeek_rdp_public_listener.yml and its service property as the example. Compare application to Zeek rdp.log and files.log sources, then verify that the rule is restricted to the relevant service and no longer produces cross-source false positives.