Wazuh Decoder Priority and Rule Validation Issues for Imperva SecureSphere Logs

[Duc Tong Anh]

Dear Wazuh Support Team,

I am writing to seek your technical expertise in resolving two critical issues we are currently experiencing with our Wazuh configuration regarding Imperva SecureSphere logs.

1. Rule Validation Error (Invalid Field/Action Tag) We are encountering errors in rule 100031 concerning the <field> and <action> tags. The system indicates that these tags must be static and independent.

• Current state: <field name="action">Block</field>

• Proposed fix: We intend to change this to <action type="pcre2">^Block(ed)?|None$</action> to ensure comprehensive capture of all relevant values. Could you confirm if this is the correct approach to resolve the tag validation error?
  
  

2. Decoder Priority and Conflict Resolution We are facing a persistent issue where Imperva logs are being incorrectly parsed by the Trend Micro decoder instead of our custom Imperva decoder.

• The Problem: Our system incorrectly defaults to the cef_trend_micro decoder because it matches any log containing the "CEF" string, effectively preempting our custom Imperva decoder regardless of other settings.

• Proposed Custom Decoder Structure: We have attempted to implement the following structure:

  • imperva-securesphere (using <prematch> for CEF: 0|Imperva Inc.|SecureSphere|)

  • Followed by child decoders using parent tags to extract specific fields via PCRE2 regex.
    

    <decoder name="imperva-securesphere">

      <prematch>CEF:\s*0\|Imperva Inc\.\|SecureSphere\|</prematch>

    </decoder>

     

    <decoder name="imperva-securesphere-fields">

      <parent>imperva-securesphere</parent>

      <regex type="pcre2">^13\.5\.0\|([^|]+)\|([^|]+)\|([^|]+)\|</regex>

      <order>imperva.version, imperva.signature_type, imperva.event_name, imperva.severity</order>

    </decoder>

     

    <decoder name="imperva-securesphere-fields">

      <parent>imperva-securesphere</parent>

      <regex type="pcre2">act=(\S+).*?dst=(\d{1,3}(?:\.\d{1,3}){3})\s+dpt=(\d+)\s+duser=\S+\s+src=(\d{1,3}(?:\.\d{1,3}){3})\s+spt=(\d+)\s+proto=(\S+)</regex>

      <order>action, dstip, dstport, srcip, srcport, protocol</order>

    </decoder>

• The Obstacle: Even after configuring this, the system continues to hit the Trend Micro decoder first. Even with the allow_override parameter, we are unable to force the system to prioritize our Imperva-specific decoder.

Could you provide guidance on how to correctly prioritize the Imperva decoder over the generic Trend Micro decoder when both encounter "CEF" logs? Furthermore, we are concerned that our current approach to splitting decoders by header, network, and policy may lead to data loss due to Wazuh's sequential decoding logic. What is the recommended best practice for defining hierarchical decoders to ensure data integrity without triggering premature matches?

Thank you for your time and assistance in resolving these configuration challenges. We look forward to your expert advice.

Best regards,

Richard

[Olamilekan Abdullateef Ajani]

Hello Tonga,

As you have rightly said, "action" can not be used/interpreted within the "field" tag, as it is a static field and should be implemented separately. The usage should be,  <action type="PCRE2">^(?:Block(?:ed)?|None)$</action>

Secondly, your decoders seem duplicated, as you have 2 decoders named: <decoder name="imperva-securesphere-fields">, you should use unique names tags for your decoders for identification purposes.
Then, if the Trend Micro decoder is matching just because the log contains CEF, then it is too broad. The Imperva decoder needs a more specific pre-match unique to the expected logs only, but if the Trend Micro decoder loads first and matches first, then it will stop there and not proceed, so the decoders need to be strict.
One way we can fix this is if you share a sample of both decoders with me, then I can tell you how to make the decoders strict.

One example will be this can match Trend Micro: CEF:0|Trend Micro|

And this can then pick the imperva. <prematch type="pcre2">CEF:\s*0\|Imperva Inc\.\|SecureSphere\|</prematch>

I know this based on some reference decoders I have worked on before. But in order not to speculate, I will advise you to share those samples, but I believe you get the idea of the picture I just painted.

Please let me know what you find and if you require further assistance on this.

[Olamilekan Abdullateef Ajani]

You can find use case references here: https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html#action

[Duc Tong Anh]

  Hello Ajani, 

Thank you for responding to my question so quickly. I would like to share the Imperva log file as an attachment, so that you can better assist me in this case.  

Error 1: tag field in rule

Rule error 100031 with the field tag: the action tag must be static – independent. Resolution approach:

xml

<field name="action">Block</field>

Change to:

xml

<action type="pcre2">^Block(ed)?|None$</action>

to capture all possible values.

Error 2: The system does not prioritize reading the Imperva decoder file first, so the CEF log format is by default read as a Trend Micro log. 

 

In addition, dividing the decoder into header, network, and policy carries the risk of data loss after decoding, which renders the written rules useless. This is due to the principle of how Wazuh scans decoders: once a decoder has been scanned and matched, the subsequent decoders are automatically skipped.

Resolution approach:

xml

<decoder name="imperva-securesphere"> <prematch>CEF:\s*0\|Imperva Inc\.\|SecureSphere\|</prematch> </decoder> <decoder name="imperva-securesphere-fields"> <parent>imperva-securesphere</parent> <regex type="pcre2">^13\.5\.0\|([^|]+)\|([^|]+)\|([^|]+)\|</regex> <order>imperva.version, imperva.signature_type, imperva.event_name, imperva.severity</order> </decoder> <decoder name="imperva-securesphere-fields"> <parent>imperva-securesphere</parent> <regex type="pcre2">act=(\S+).*?dst=(\d{1,3}(?:\.\d{1,3}){3})\s+dpt=(\d+)\s+duser=\S+\s+src=(\d{1,3}(?:\.\d{1,3}){3})\s+spt=(\d+)\s+proto=(\S+)</regex> <order>action, dstip, dstport, srcip, srcport, protocol</order> </decoder>

However, after replacing the code and even adding the allow_override field, the system still encounters the error — it continues to hit the Trend Micro decoder before hitting the Imperva decoder. Reason: In the Trend Micro decoder, as long as the log contains the word CEF, the regex is considered matched. The system then automatically returns the Trend Micro decoder and rule stream every time.

Reason: In the Trend Micro decoder, as long as the log contains the word CEF, the regex is considered matched. The system then automatically returns the Trend Micro decoder and rule stream every time.

  I don’t know how to proceed further yet.  

Brgds
Richard

Vào lúc 20:00:50 UTC+7 ngày Thứ Ba, 16 tháng 6, 2026, Olamilekan Abdullateef Ajani đã viết:

[Olamilekan Abdullateef Ajani]

Hello Tonga,

Apologies for the late feedback.

The screenshots you shared show that the issue is occurring before your Imperva decoder is evaluated. The log is being assigned to cef_trend_micro, whose prematch appears to be only ^CEF:. Since your Imperva logs are also CEF-formatted, the generic decoder is matching first. To confirm this, could you temporarily disable the Trend Micro decoder and rerun wazuh-logtest with the same sample? If the Imperva decoder starts matching, then we have confirmed a decoder precedence issue rather than a problem with the Imperva regex itself. Also, please share the Trend Micro sample log too so I can adjust the decoders to have to be stricter.

The Trend Micro decoder should not use only: <prematch>^CEF:</prematch> because that will catch all CEF logs, including Imperva. It should be vendor-specific.

Depending on the Trend Micro log you have, it should be stricter, like

<decoder name="cef_trend_micro">
  <prematch type="pcre2">^CEF:\d+\|Trend Micro\|</prematch>
</decoder>

With that, the Imperva log should also evaluate as well.

Please share a sample Trend Micro decoder as earlier mentioned.

Thank you