Common Mistakes and How to Avoid Them

Even experienced Wazuh administrators can encounter issues when building hierarchical rule sets.

Most problems stem from incorrect rule relationships, missing decoded fields, or overly broad matching criteria.

Understanding these common pitfalls will help you build more reliable and maintainable Wazuh parent child rules.

Incorrect Parent Rule IDs

One of the most common mistakes is referencing the wrong parent rule ID in a child rule.

For example:

<if_sid>100100</if_sid>

If rule 100100 does not exist or the ID is incorrect, the child rule will never be evaluated.

How to avoid it:

• Verify every <if_sid> references an existing parent rule.
• Keep custom rule IDs organized within a dedicated range.
• Document parent-child relationships as your ruleset grows.
• Use consistent naming conventions alongside rule IDs.

Child Rules Never Trigger

Sometimes a parent rule matches successfully, but none of the child rules generate alerts.

Common causes include:

• Incorrect field names
• Typographical errors
• Field values that don’t match decoded output
• Decoder parsing failures
• Incorrect regular expressions

Always remember that child rules evaluate the decoded fields, not the original raw log.

How to avoid it:

• Test each rule with wazuh-logtest.
• Compare child rule conditions against the decoder output.
• Validate every extracted field before writing child rules.

Related Guide: Troubleshooting wazuh-logtest: Why Alerts Are Missing from JSON Output

Overlapping Rule Conditions

Two or more child rules may unintentionally match the same event.

For example:

• Rule A matches all failed logins.
• Rule B matches all administrator logins.
• An administrator login failure satisfies both rules.

Without careful planning, this can produce multiple alerts for a single event.

How to avoid it:

• Make child rule conditions as specific as possible.
• Design mutually exclusive rule logic where appropriate.
• Test edge cases that may satisfy multiple conditions.

Missing Field Extraction

Rules cannot evaluate fields that were never extracted by the decoder.

For example, attempting to match:

<field name="username">administrator</field>

will always fail if the decoder never extracted the username field.

How to avoid it:

• Validate decoder output before writing rules.
• Ensure every required field is available.
• Update custom decoders whenever log formats change.

Related Guide: Wazuh Decoder Guide

Rule Evaluation Order Problems

Some administrators assume child rules execute independently.

In reality:

• Decoder runs first.
• Parent rule matches.
• Child rules execute afterward.

If the parent never matches, every dependent child rule is skipped.

How to avoid it:

• Verify the parent rule first.
• Build and test hierarchies incrementally.
• Confirm the evaluation flow using wazuh-logtest.

Duplicate Alerts

Poorly designed hierarchies can generate multiple alerts for the same security event.

For example:

• Generic failed login rule
• Generic authentication failure rule
• Brute-force rule

If all three match simultaneously, analysts receive unnecessary duplicate alerts.

Duplicate alerts contribute to alert fatigue and make investigations more difficult.

How to avoid it:

• Design a clear hierarchy.
• Keep parent rules informational whenever possible.
• Reserve alert generation for the most specific child rules.
• Review alerts after deployment to identify unnecessary duplication.

Excessively Broad Parent Rules

Parent rules should classify related events, not match nearly everything.

An overly broad parent may unintentionally trigger hundreds of child rules for unrelated logs, reducing performance and increasing false positives.

For example, matching every JSON log regardless of source is rarely a good design.

How to avoid it:

Good parent rules should identify:

• One application
• One device category
• One event family
• One log source

Keeping parent rules focused produces cleaner, faster, and more scalable rule hierarchies.

Best Practices for Wazuh Parent Child Rules

As your Wazuh deployment grows, thoughtful rule design becomes increasingly important.

Following established best practices results in cleaner XML, easier maintenance, fewer false positives, and a ruleset that can evolve alongside your infrastructure.

Keep Parent Rules Generic

Parent rules should identify broad event categories rather than individual security events.

Examples include:

• Authentication events
• Firewall traffic
• VPN activity
• Cloud audit logs
• Endpoint process events

Avoid embedding highly specific conditions into the parent.

Make Child Rules Highly Specific

Child rules should contain the detailed detection logic.

Examples include:

• Administrator login
• Failed authentication
• Account lockout
• Privilege escalation
• Suspicious PowerShell execution

The more focused the child rule, the easier it is to understand, troubleshoot, and extend.

Use Meaningful Descriptions

Rule descriptions should clearly explain the detected activity.

Good examples include:

• Administrator account login detected
• Multiple failed authentication attempts
• Suspicious PowerShell launched from Office
• Firewall blocked inbound SSH connection

Clear descriptions help analysts quickly understand the alert without opening the rule definition.

Reuse Parent Rules Whenever Possible

Before creating a new parent rule, determine whether an existing one can support additional child rules.

Reusing parents:

• Reduces duplicated logic
• Simplifies maintenance
• Improves consistency
• Makes future expansion easier

Group Related Detections Logically

Use meaningful rule groups to organize alerts.

Examples include:

• authentication
• endpoint
• firewall
• malware
• cloud
• privilege_access
• compliance

Consistent grouping improves filtering, dashboards, and reporting.

Test with Diverse Log Samples

Do not rely on a single sample log.

Test:

• Expected events
• Invalid events
• Malformed logs
• Missing fields
• Unexpected values
• Boundary conditions

Comprehensive testing significantly reduces production issues.

Assign Consistent Severity Levels

Severity should reflect the actual security risk.

For example:

Using consistent severity ranges makes alerts easier to prioritize across your environment.

Document Custom Rule Relationships

As rule libraries expand, documenting parent-child relationships becomes increasingly valuable.

Maintain documentation that includes:

• Rule IDs
• Parent dependencies
• Decoder requirements
• Expected fields
• Alert descriptions
• MITRE mappings

This makes onboarding new team members and troubleshooting significantly easier.

Version-Control Custom Rule Files

Store custom decoders and rules in a version control system such as Git.

Benefits include:

• Change history
• Rollback capability
• Code reviews
• Team collaboration
• Audit trails

Version control also makes it easier to test new detections before deploying them to production.

Review Rule Performance After Deployment

Rule development doesn’t end after deployment.

Monitor:

• Alert volume
• False positives
• False negatives
• Processing performance
• Rule execution frequency

Periodic reviews help identify opportunities to simplify rules, improve specificity, and retire obsolete detections.

The Center for Internet Security (CIS) recommends regularly reviewing and tuning detection content as part of continuous security monitoring to improve effectiveness and reduce alert fatigue.

Real-World Example

A multinational organization’s security operations center (SOC) is responsible for monitoring a custom identity management platform used by employees, contractors, and third-party vendors.

The platform generates proprietary authentication logs that are not supported by Wazuh’s built-in ruleset.

Each log contains shared metadata, including the application name, event category, timestamp, and session identifier, as well as event-specific fields such as event_type, result, username, source_ip, multi-factor authentication (MFA) status, password reset actions, and account lockout information.

Initially, the SOC created individual standalone rules for every authentication event.

Each rule repeated the same application matching conditions, resulting in hundreds of lines of duplicated XML.

As the platform evolved and new event types were introduced, maintaining the rules became increasingly time-consuming, and inconsistencies began appearing between similar detections.

Solution:

To simplify the ruleset, the analysts redesign it using Wazuh parent child rules.

First, they create a generic parent rule that matches every authentication event produced by the custom application after the decoder extracts the relevant fields.

The parent rule performs only broad event classification and does not generate alerts.

Next, they build multiple child rules that reference the parent using <if_sid>.

Each child evaluates specific decoded fields, including:

• event_type
• result
• username
• source_ip
• role
• mfa_status

This allows them to create specialized detections for scenarios such as:

• Successful user logins
• Failed password attempts
• Repeated authentication failures indicating possible brute-force activity
• Administrator account logins
• Account lockouts
• Password resets
• Failed multi-factor authentication challenges

Each child rule assigns an appropriate severity level, places the alert into logical groups, and maps relevant activity to MITRE ATT&CK techniques where applicable.

For example, repeated failed login attempts are mapped to T1110 (Brute Force), while successful administrator logins are associated with T1078 (Valid Accounts).

Before deployment, the SOC validates every rule using wazuh-logtest to confirm that:

• The custom decoder extracts the expected fields.
• The parent rule matches all authentication events.
• Each child rule triggers only for its intended scenario.
• Alert descriptions, severity levels, and MITRE mappings are applied correctly.

After testing, the rules are deployed to production.

Result:

Within weeks, the team observes several measurable improvements:

• Duplicate rule definitions are virtually eliminated.
• New authentication event types can be added by creating additional child rules instead of rewriting existing logic.
• Rule maintenance becomes significantly faster because shared matching conditions exist in only one location.
• Alert consistency improves across all authentication-related detections.
• Analysts identify suspicious authentication behavior, including repeated failed logins, privilege escalation attempts, and account lockouts, more quickly because alerts are clearer, more specific, and consistently categorized.

The result is a scalable detection framework that is easier to maintain, adapts to changes in the application’s logging format, and provides higher-quality alerts for the SOC without increasing administrative overhead.

Related Guides:

•  How to Test Wazuh Rules
• How to Create Custom Detection Rules in Wazuh (With Examples)
• Wazuh Decoder Guide

Frequently Asked Questions (FAQ)

Question: What are Wazuh parent child rules?

Wazuh parent child rules are a hierarchical rule design method that allows security teams to organize detection logic into multiple levels.

A parent rule identifies a broad category of events, while child rules evaluate more specific conditions based on the information inherited from the parent.

For example, a parent rule may identify all authentication events from an identity management platform, while child rules detect:

• Successful logins
• Failed authentication attempts
• Administrator access
• Account lockouts
• MFA failures

This approach prevents duplicate logic and makes complex detection rules easier to manage.

Question: How do parent rules differ from child rules?

Parent and child rules have different responsibilities within the Wazuh detection engine.

Parent rules provide the initial classification layer by identifying the general type of event. They typically contain shared conditions and often do not generate alerts themselves.

Child rules perform the detailed analysis by evaluating specific fields and generating the final security alert.

A well-designed ruleset uses parent rules for classification and child rules for actionable detection.

Question: Can one parent rule have multiple child rules?

Yes. A single parent rule can support multiple child rules.

This is one of the primary advantages of hierarchical rule design.

For example, a firewall parent rule could have child rules for:

• Blocked inbound traffic
• Allowed administrative connections
• Port scanning activity
• Suspicious outbound communication

Similarly, an authentication parent rule could support child rules for:

• Successful login
• Failed login
• Privileged login
• Password reset
• Account lockout

Multiple child rules allow security teams to expand detection coverage without rewriting common logic.

Question: Do child rules inherit all conditions from the parent?

Child rules inherit the matching context established by the parent rule, but they do not automatically inherit every rule attribute.

The child rule depends on the parent matching first through:

<if_sid>parent_rule_id</if_sid>

The child can then add additional conditions, such as:

• Field matching
• Regular expressions
• Event values
• Usernames
• IP addresses
• Process names

However, child rules usually define their own:

• Severity level
• Description
• Groups
• MITRE ATT&CK mappings
• Compliance references

The parent provides the foundation, while the child provides the final detection logic.

Question: Can parent child rules improve performance?

Yes, properly designed parent-child rules can improve rule processing efficiency.

Instead of evaluating every detailed condition against every incoming event, Wazuh can first determine whether an event belongs to a specific category.

For example:

1. Parent rule checks whether a log is an authentication event.
2. Only matching authentication logs are evaluated against authentication child rules.
3. Unrelated events skip those child rules.

This reduces unnecessary processing and makes large rulesets easier to scale.

However, poorly designed parent rules can have the opposite effect. Extremely broad parent rules may cause many unnecessary child evaluations, so parents should remain focused on specific event categories.

Question: How do I test parent child rules?

The recommended way to test parent-child rules is by using wazuh-logtest.

The testing workflow should include:

1. Submit a sample log.
2. Verify the correct decoder processes the event.
3. Confirm extracted fields are available.
4. Verify the parent rule matches.
5. Confirm the expected child rule executes.
6. Review the generated alert details.

Testing should include multiple scenarios, including:

• Expected successful events
• Failed events
• Edge cases
• Missing fields
• Unexpected values

This ensures the hierarchy behaves correctly before deployment.

Question: Can parent child rules work with custom decoders?

Yes. Parent-child rules work especially well with custom decoders.

Custom decoders extract structured information from unsupported or proprietary log formats, while parent-child rules use those extracted fields to create detection logic.

A typical workflow looks like this:

1. Custom decoder parses the raw log.
2. Decoder extracts fields such as username, IP address, event type, or action.
3. Parent rule identifies the general event category.
4. Child rules evaluate specific security conditions.
5. Wazuh generates the appropriate alert.

This combination is commonly used for:

• Custom enterprise applications
• Internal authentication platforms
• Proprietary security tools
• Custom API logs
• Specialized infrastructure devices

Question: What happens if a parent rule does not match?

If the parent rule does not match, none of its child rules will be evaluated.

The child rule dependency chain is broken because the <if_sid> condition requires the parent rule to successfully match first.

For example:

<rule id="100200" level="8">
    <if_sid>100100</if_sid>
    <field name="result">failure</field>
    <description>Failed authentication detected</description>
</rule>

If rule 100100 never matches:

• Rule 100200 is skipped.
• No alert is generated.
• The event continues through the remaining Wazuh ruleset.

When child rules fail unexpectedly, always troubleshoot the parent rule first.

Conclusion

Complex log environments often require more than simple standalone detection rules.

Modern organizations collect events from custom applications, cloud platforms, authentication systems, firewalls, and endpoint technologies, each producing different log structures and security signals.

Wazuh parent child rules provide a scalable way to manage this complexity by separating broad event classification from detailed detection logic.

Parent rules establish shared conditions, while child rules focus on specific behaviors such as failed authentication attempts, privilege changes, suspicious processes, or malicious network activity.

This hierarchical approach delivers several benefits:

• Reduces duplicated rule logic
• Simplifies long-term maintenance
• Improves rule organization
• Supports complex log formats
• Makes detection logic easier to expand
• Produces more consistent alerts

When combined with custom decoders, parent-child rules create a powerful framework for detecting security events from virtually any log source.

Instead of creating isolated rules for every possible scenario, security teams can build reusable detection structures that grow alongside their environments.

Before deploying new rules into production, always validate them using wazuh-logtest.

Testing ensures that decoders extract the expected fields, parent rules match correctly, and child rules generate accurate alerts with appropriate severity levels.

A well-designed parent-child rule hierarchy reduces administrative overhead while improving detection quality.

\By organizing security logic into reusable layers, Wazuh administrators can build more reliable monitoring capabilities and maintain effective threat detection across increasingly complex logging environments.

Related Guides:

• The Ultimate Wazuh Indexer Guide
• The Complete Wazuh Cluster Architecture Guide
• How to Test Wazuh Rules