Transform Wazuh to Google SecOps Rules

Moving from Wazuh SIEM to Google Security Operations (SecOps)? Here is how my new rule translation workbench helps you transform your custom Wazuh XML detections into production-ready YARA-L 2.0 rules.

Try the tool directly at jorgeliauw.nl/wazuh-to-secops.

---

High-Precision Rule Translation, Not Blind Mass Migration

When organizations transition from Wazuh to Google SecOps, one of the first questions that comes up is: “How do we move our existing detection rules over?”

To help customers bridge that gap, I built SecOpsBridge (Wazuh to Google SecOps Rule Translator):

This is not a mass migration tool, but a high-precision rule translation tool — combined with our knowledge, we will help you to transform your SecOps detection.

We use syntax and rule checkers, Gemini, and Human-on-the-Loop (HOTL) to help you produce and validate production-ready detection rules. Our tool is thoroughly tested and validated with live Wazuh instances and Google SecOps.

---

The 95% Rule: Start with Curated Detections First

Before translating a single XML file, there is one architectural principle I always share with customers: don’t lift-and-shift everything.

Google SecOps includes Curated Detection rules developed and managed by Google and Mandiant, which already cover 95% of common threat detection use cases out of the box. Because those detections are continuously tuned against frontline threat intelligence, we strongly recommend enabling Curated Detections first and only creating custom YARA-L 2.0 rules for the remaining 5%—your organization-specific business logic, bespoke applications, or specialized compliance workflows.

When you do need to bring over those critical custom Wazuh detections, translating them by hand into YARA-L 2.0 and mapping every field to Google’s Unified Data Model (UDM) takes time. That is exactly where this workbench comes in.

---

How the Translator Works

Wazuh and Google SecOps think about detection differently. Wazuh relies on XML <rule> hierarchies, parent-child if_sid / if_matched_sid chains, and custom decoders (<decoded_as>). Google SecOps uses YARA-L 2.0 over normalized UDM events.

SecOpsBridge combines three layers to make sure your translated rules actually work in production:

1. AST & UDM Schema Validation: The client-side Abstract Syntax Tree (AST) parser checks your Wazuh XML structure and maps Wazuh fields (win.eventid, srcip, dstuser, url, etc.) directly to canonical Google SecOps UDM fields (metadata.product_event_type, principal.ip, target.user.userid).
   • Clean Pipe (UDM Verified): Every predicate maps cleanly to standard UDM fields.
   • Clogged Pipe (Custom Parser / Unmapped UDM): If your Wazuh rule depends on a custom <decoded_as> decoder or a non-standard field, the linter flags it immediately, routes unmapped fields to additional.fields, and advises where a Chronicle Ingestion Parser (CBN) or Bindplane transform is needed.
2. Gemini Flash Stateful Synthesis: When a Wazuh rule uses stateful correlation (if_matched_sid, frequency, timeframe, same_source_ip) or PCRE2 regular expressions, Gemini synthesizes the parent-child chain into a clean YARA-L 2.0 match window (for example, match: $principal_ip over 2m) and condition block (#e >= 5).
3. Human-on-the-Loop (HOTL) Review: AI and AST parsers get you 90% of the way there in seconds, but detection engineering requires human judgment. You can use the Feedback button directly on the YARA-L 2.0 code block to flag a rule for architectural review and re-architect existing Wazuh logic for Google SecOps.

---

Example: From Wazuh XML to YARA-L 2.0

Paste a stateful Wazuh XML rule chain—such as an SSH brute-force correlation rule (if_matched_sid with frequency and timeframe)—into the left pane:

<rule id="100100" level="5">
  <decoded_as>sshd</decoded_as>
  <field name="win.eventid">4625</field>
  <description>Failed authentication attempt</description>
</rule>

<rule id="100101" level="10" frequency="5" timeframe="120">
  <if_matched_sid>100100</if_matched_sid>
  <same_source_ip />
  <description>Multiple failed logins from same source IP</description>
  <mitre>
    <id>T1110</id>
  </mitre>
</rule>

And the translator outputs a structured YARA-L 2.0 rule mapped to UDM, complete with MITRE ATT&CK metadata, risk scoring, and a multi-event match window:

rule wazuh_100101_multiple_failed_logins_from_same_source {
  meta:
    author = "SecOpsBridge Hybrid Engine"
    description = "Multiple failed logins from same source IP"
    wazuh_rule_ids = "100100, 100101"
    wazuh_level = "10"
    severity = "HIGH"
    mitre_attack_technique = "T1110"
    pipeline_status = "CLEAN_PIPE"

  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.security_result.action = "BLOCK"
    $e.metadata.product_event_type = "4625"
    $e.principal.ip = $principal_ip

  match:
    $principal_ip over 2m

  outcome:
    $risk_score = max(80)
    $attempt_count = count_distinct($e.metadata.id)
    $affected_targets = array_distinct($e.target.user.userid)

  condition:
    #e >= 5
}

---

Try It Out & Let’s Connect

Ready to test your own Wazuh XML detections or re-architect your custom rules for Google SecOps?

1. Head over to https://jorgeliauw.nl/wazuh-to-secops and sign in with your Google account.
2. Paste your Wazuh <rule> XML or load a sample template to inspect the generated YARA-L 2.0 code, UDM schema JSON mapping, and linter advisories.
3. Use the Feedback button on the YARA-L 2.0 code block—or reach out directly—if you would like to consult with me on re-architecting your detection strategy in Google SecOps.