A custom Wazuh rule should never be tested first by restarting the production manager. Malformed XML, an invalid field, a duplicate rule ID, or a mistaken parent rule can stop analysis or create a flood of low-value alerts.
The production-safe sequence is: classify the source event, preserve the current configuration, edit only the supported local path, validate the complete ruleset, test representative log samples, restart once, and verify ingestion plus alert delivery.
Separate Operational Errors From Security Detections
Windows Event ID 264 from Microsoft-Windows-Defrag can report that slab consolidation was aborted because too few slabs could be reclaimed. It is an optimizer/storage event, not evidence of an attack by itself. Preserve the exact provider, channel, event ID, error code, volume type, and recurrence before assigning a severity.
An isolated optimizer failure might belong in an operational dashboard at low severity. Repeated storage errors combined with filesystem, disk, or availability symptoms may warrant escalation to infrastructure staff. A SOC rule should not label every Windows error-level event as malicious.
Define three outcomes before writing XML:
- Collect only, with no alert.
- Low/medium operational visibility.
- High security alert with a documented response action.
Severity should express response priority supported by evidence, not the Windows log level alone.
Use Supported Local Files and IDs
Wazuh’s custom-rule documentation reserves IDs from 100000 through 120000 for custom rules. Small changes can go in /var/ossec/etc/rules/local_rules.xml; larger sets should use separate files under /var/ossec/etc/rules/.
Do not edit /var/ossec/ruleset/rules/. Wazuh documents that packaged rules there can be overwritten during upgrades. Do not replace the entire local file with an unreviewed “SOC ruleset” generated for a different version or decoder set.
Before editing:
install -d -m 0700 /root/wazuh-rule-backups
cp -a /var/ossec/etc/rules \
/root/wazuh-rule-backups/rules-before-change
Use a timestamped directory in an actual change procedure; the example deliberately avoids an inline command substitution that could hide a typo. Record file ownership and permissions as well as content.
Validate Before Restarting
Wazuh’s wazuh-analysisd reference documents -t as the configuration-test option. Run:
/var/ossec/bin/wazuh-analysisd -t
Treat any error as a stop condition. Note the first file and line reported, restore the last known-good file if necessary, and rerun the test. A clean XML parser alone is insufficient because Wazuh also validates rule semantics.
Then use the officially documented wazuh-logtest tool. Feed sanitized one-line samples representing:
- The event that must match.
- A close benign event that must not match.
- A different provider with the same numeric event ID.
- Missing or differently typed fields.
- Repeated events if correlation is used.
Record decoder phases, extracted fields, the matched parent, custom rule ID, and final level. Logtest loads saved rule changes without requiring a production restart, making it the correct first test surface.
Deploy One Change and Prove the Pipeline
After both validation layers pass, restart the manager once through the supported service command. Immediately check service status and manager logs. If startup fails, restore the backed-up local rule directory, validate again, and restart; do not keep modifying a broken file in place without a known-good reference.
A logtest match does not prove that endpoint events reach the index. Verify the whole path:
Windows audit policy and event channel
-> Wazuh agent collection
-> manager decoding and rule match
-> alerts.json
-> shipper/indexer
-> dashboard time range and filter
Wazuh documents alerts in /var/ossec/logs/alerts/alerts.json and the Security Events view after indexing. Check the server-side alert first, then the dashboard. A missing dashboard result may be ingestion, index, time-zone, role, or filter trouble rather than a failed rule.
Collect Commands With Windows Audit Policy, Not a Dangerous Demo
PowerShell Script Block Logging can provide Event ID 4104 when enabled through an approved Windows policy. Process-creation auditing and command-line inclusion cover cmd.exe and other process launches, subject to Windows edition, policy, and privacy requirements. Wazuh must collect the corresponding Windows channels.
Do not execute a downloader, credential-dumping pattern, or other attack command on a production endpoint merely to generate an alert. Use a benign script-block string, a dedicated test endpoint, or sanitized historical event passed to logtest. Command-line logs can contain passwords, tokens, file paths, and personal data, so restrict access, retention, and export.
Expose the Dashboard as an Administrative System
Wazuh is not “safer than WordPress” by category. Its dashboard, API, enrollment, and event-ingestion ports are privileged management surfaces. Bind internal services narrowly, publish only the necessary HTTPS entry through a controlled VPN or reverse proxy, use trusted certificates, MFA/SSO where supported, RBAC, source restrictions, patching, and monitoring. Do not expose indexer port 9200 or the server API merely because they listen on all interfaces.
Production Wazuh engineering rewards restraint: one documented detection, supported syntax, a positive and negative test set, configuration validation, a reversible deployment, and end-to-end evidence. A large copy-paste rules file is not a SOC maturity shortcut.
