Detection Engineering with Sigma + Wazuh — Seeking Industry Guidance on SOP, Automation, Testing and Normalisation

[HackRabbit]

I am currently building a detection engineering pipeline on top of Wazuh and I have a set of architectural and operational questions. I would greatly appreciate guidance from anyone who has implemented this at scale or in a production environment.

Environment details:
  Wazuh version : 4.12
  OS            : Ubuntu 22.04 LTS
  Hardware      : Physical machine, 32 GB RAM, 12 cores

a) My understanding of the Wazuh processing order is:
   Raw log → decoder → rule engine evaluates → alert generated → normalisation adds ECS fields

   Is this correct? Does the rule engine evaluate rules BEFORE or AFTER any normalisation layer?

b) If we add ECS normalisation (via Logstash or Filebeat) on top of Wazuh:
   - Do Wazuh default rules using <match> and <regex> tags continue to fire correctly?
   - Do custom rules using <field name="win.eventdata.commandLine"> break because the field no longer exists in the normalised schema?
   - Do we need to rewrite all field-based custom rules and defualt rules shipped by wazuh to use ECS field names?

c) Is there an official pySigma pipeline for ECS-normalised Wazuh environments? If so, where is it maintained?

d) If we change our normalisation schema in the future (for example moving from custom field names to ECS), is there a recommended approach for bulk-migrating all custom Wazuh rules to the new field names?

e) Has anyone implemented a self-discovering field mapping approach — where the pipeline reads live Wazuh alerts to determine the actual field schema and builds the pySigma pipeline configuration automatically? Any prior art or tooling for this?

f) How does pySigma map Sigma severity levels to Wazuh rule levels? Is there a standard mapping table, and is it configurable?

g) pySigma does not appear to set if_sid in the converted output. This means converted rules match against all events rather than being scoped to the correct log source. Is there a standard way to configure if_sid mapping in the Wazuh backend pipeline?

h) What is the standard method for testing that a converted Wazuh rule actually fires on the intended log?
   - Is wazuh-logtest the standard post-deploy test?
   - Are there pre-deploy simulation tools?
   -
i) What is the recommended approach for handling Sigma rules that pySigma cannot convert due to unsupported conditions (near, pipe) or unsupported log sources? Is there a maintained list of what the Wazuh backend supports?

Has anyone attempted a similar self-adapting approach? Are there known pitfalls or prior art we should be aware of before investing further in this direction?

Thank you for reading this far. Any guidance, pointers to documentation, or references to prior discussions on any of these points would be greatly appreciated. We are happy to share our findings back with the community once the accelerator is further developed.

Best regards,

[Stuti Gupta]

Hi,

Let me address each of your points one by one.

a) Processing order
You are close, but the normalization step does not occur before rule evaluation. The processing flow is:

Raw log → manager receives the event → decoder parses fields → rule engine evaluates rules → alert generated → alert written to alerts.json → Filebeat reads alerts.json or archives → ingest pipeline performs mappings (for example, adding Elastic Common Schema (ECS) fields) → alert indexed in Elasticsearch/OpenSearch → visualization in the Wazuh dashboard.

Because of this sequence, the rule engine evaluates rules before any ECS normalization. Wazuh rules work on fields extracted by the decoder, or they can use <match> and <regex> conditions that do not require decoded fields.

b) Adding ECS normalization with Logstash or Filebeat before Wazuh
Default rules using <match> or <regex> generally continue to work because they match the raw log text rather than specific decoded fields.

Custom rules that depend on specific fields (for example, <field name="win.eventdata.commandLine">) may stop working if the ECS pipeline renames or modifies those fields. Decoders may also need adjustments if the log format changes before reaching Wazuh.

Because of this, some custom rules or decoders may need to be updated to match the new field names or structure. If ECS normalization happens before the event reaches Wazuh, field-based rules can indeed be affected.

c) pySigma pipeline for Wazuh
Currently, there is no official PySigma pipeline specifically designed for ECS-normalized Wazuh environments maintained by Wazuh. Sigma support has been discussed but is not implemented as a built-in feature. This topic is tracked here: https://github.com/wazuh/wazuh/issues/15451

d) Migrating rules when the normalization schema changes
There is no built-in method to automatically migrate rules if field names change. If the normalization schema changes (for example moving to ECS field names), the common approach is to update rules manually or with scripts. steps are:

Maintain a field mapping table (old field → new field).
Back up the default rules and decoders.
Update the field names in the rules (manually or using scripts).
Test the updated rules using wazuh-logtest before restarting the manager.

Custom rules referencing renamed fields usually need to be updated.

e) Self-discovering field mapping
I’m not aware of any maintained tool that automatically discovers the field schema from live Wazuh alerts and generates a pySigma mapping pipeline. In most cases, the field mappings are defined manually. Some projects attempt Sigma-to-Wazuh conversion, such as the https://github.com/theflakes/sigma_to_wazuh repository, but these are not official and usually require manual adjustments.

These are not official and usually require manual adjustments.

f) Mapping Sigma severity to Wazuh rule levels
 There is no strict standard mapping between Sigma severity levels and Wazuh rule levels. When Sigma rules are converted, the severity is usually mapped to the Wazuh rule level (0–15) using a custom mapping defined in the conversion workflow. This mapping is usually configurable in the rule generation pipeline.

g) Handling if_sid in converted rules
Many Sigma conversions do not automatically include if_sid. In Wazuh, if_sid is a parent rule. If you want that behavior in generated rules, it usually needs to be added through customization in the backend pipeline. For example, the https://github.com/theflakes/sigma_to_wazuh/blob/main/get-wazuh_rule_info.py script in the sigma-to-Wazuh converter generates a report of rule IDs, fields, and rule dependencies to help determine where if_sid may be required.

h) Testing converted rules
Usually, the wazuh-logtest tool is used to test the rules and decoders in wazuh. This lets you send a sample log and see which decoder and rule will match before deploying the rule. In some unofficial setups, tools like Chainsaw are used to run Sigma detections on event logs and then send the results to Wazuh for alerting. https://socfortress.medium.com/wazuh-and-chainsaw-integration-for-near-real-time-sigma-detection-6f3e729e892

i) Sigma rules that cannot be converted
Sigma rules that cannot be converted: I’m not very familiar with the Sigma rule conversion limitations, so I cannot give a detailed list of which Sigma conditions are supported or unsupported when converting to Wazuh rules. In general, when a Sigma rule cannot be converted automatically (for example, due to unsupported conditions or log sources), it usually needs to be reviewed and adjusted manually. Some tools attempt to convert Sigma rules to Wazuh rules, but they may skip rules or require manual fixes depending on the detection logic.    

One thing to keep in mind is that the detection logic in Sigma can sometimes be more complex than what Wazuh rules support, so automatic conversion may still need some manual adjustments. You refer to the unofficial documents:
https://medium.com/@omvecg/step-by-step-guide-soc-home-lab-with-wazuh-sigma-rules-397a8936cc9e
https://socfortress.medium.com/wazuh-and-chainsaw-integration-for-near-real-time-sigma-detection-6f3e729e892
https://www.linkedin.com/posts/mariskarthickm_cybersecurity-threatdetection-sigmarules-activity-7299219519477104640-KDfR/

Let me know if you need any further help.