DATA MASKING IN WAZUH

[m mun]

Hi Wazuh community,

I would like to ask for opinion in data masking for logs inside Wazuh. currently i have applied the masking for the specific field, however it is not sufficient since the value of sensitive data still visible in full logs. Appreciate any advice from anyone with data masking experience especially in Wazuh.

[Nikhil Gurjar]

Hi Team,

Could you please clarify the masking configuration? Specifically, have you configured the pipeline setting in Filebeat on the Wazuh manager side, or is it configured on the endpoint side?

If you have already configured masking for specific values and do not want the full logs to be displayed for those alerts, you can add the following option inside your rule: <options>no_full_log</options>

If the rule you are modifying is a default rule, you can override it by using the overwrite="yes" attribute. For example (reference: Wazuh rules XML syntax documentation):

<rule id="87100" level="0" overwrite="yes">
<decoded_as>json</decoded_as>
<field name="integration">virustotal</field>
<description>VirusTotal integration messages.</description>
<options>no_full_log</options>
</rule>

This will prevent the full log from being displayed in the alert while still allowing the rule to trigger.

Looking forward to your update.

Best regards,
Nikhil

[Nikhil Gurjar]

Hi Team,

Yes, your understanding is correct. If the  <options>no_full_log</options>   configuration is applied, it only affects the wazuh-alerts-* indices. If you enable the wazuh-archives-* indices, this option will not prevent the full_log field from being stored there.

However, your requirement to hide this field can still be achieved by updating the pipeline configuration. Please follow the steps below:

1. Navigate to the archives pipeline configuration file and take a backup of the existing configuration before making any changes.

cd /usr/share/filebeat/module/wazuh/archives/ingest
cp pipeline.json pipeline.json.20260302.bkup

2. Open the file in edit mode and insert the configuration below under the processors array, and update the value of the   <YOUR_RULE_ID>  placeholder.

nano pipeline.json

,{  "remove": {
              "field": "full_log",
              "if": "ctx?.rule?.id == '<YOUR_RULE_ID>'",
              "ignore_missing": true,
              "ignore_failure": true
              }
     }

3. Save the changes and update the pipeline via the command below, and make sure it will successfully load:
filebeat setup --pipelines --modules wazuh.


4. Now for the `wazuh-archives` index, when this rule ID is triggered, the full log field will no longer exist.


Hope this information is helpful for you. Please let us know if you have any other queries here.

Best regards,
Nikhil

[Nikhil Gurjar]

Hi Team,

Your understanding is generally correct. When archives logging is enabled in the Wazuh manager, it stores all processed logs, regardless of whether they trigger a rule or not. This allows you to view the raw events that the Wazuh manager receives and analyzes.

If a log matches a rule, the following occurs:

• The original log is stored in the archives index (if archives are enabled).

• If the rule severity meets the configured alert threshold, the event is also stored in the alerts index.

By default, Wazuh only generates alerts for rules with a level equal to or greater than the value defined in log_alert_level in the manager configuration. The default value is typically 3, meaning only events with rule level 3 or higher are written to the wazuh-alerts index. (reference: https://documentation.wazuh.com/current/user-manual/ruleset/rules/rules-classification.html)

It is also important to note that when a log appears in the archives, it does not replace the original raw log. Instead, it stores the processed event as received by the Wazuh manager, including any rule information if a rule was matched.

In general, enabling archives is not recommended for long-term use in production environments because it stores all events, which can significantly increase storage usage. It is commonly enabled temporarily for troubleshooting purposes, such as verifying whether logs are being received and processed correctly by the Wazuh manager. (reference document: https://documentation.wazuh.com/current/user-manual/manager/event-logging.html#archiving-event-logs )

Hope this information clarifies your concern. Please let us know if you have any further queries or questions here.

Best regards,
Nikhil

[Nikhil Gurjar]

Hi Team,

Glad to hear that the information was helpful.

By default, the full_log field is stored in both the wazuh-alerts-* and wazuh-archives-* indices, so no additional configuration is required for it to appear.

The steps I shared earlier only apply to specific rule IDs where the configuration was modified. Therefore, the change will only affect logs that match those rules.

For logs that do not match those rule IDs, the full_log field will continue to appear normally, allowing you to maintain visibility of the raw logs while you continue working on decoding the remaining log sources.

I hope this clarifies your concern.

Best regards,
Nikhil