Wazuh Alerts & Watchers
Use this guide to configure alerts in Wazuh for Cloudaware Intrusion Detection (IDS), using Watchers and Cloudaware integrations to turn detections into actionable incidents.
Overview
In Cloudaware, Wazuh provides the host‑based IDS engine and dashboards; alerts are typically raised when:
- A Wazuh rule matches an event (for example, file integrity change, authentication anomaly, or policy violation).
- A Watcher periodically evaluates a saved search and finds events that meet specified conditions.
- Cloudaware integrations convert those detections into incidents, tickets, or notifications in downstream tools.
Use Wazuh alerts when you want to:
- Detect specific patterns in logs or IDS events (for example, the creation of new security groups or suspicious logons).
- Raise Cloudaware Incidents automatically when those patterns occur.
- Notify owners via email, chat, or ITSM systems using Cloudaware workflows and webhooks.
Prerequisites
Before configuring alerts:
- Ensure Breeze Agent is installed on the hosts you want to monitor and that IDS is enabled.
- Confirm access to Wazuh via Cloudaware Control Hub (Launcher).
- Set up a generic incident webhook or API integration as described in Webhooks & API so Wazuh can send incidents into Cloudaware.
- Optionally, connect ITSM and collaboration tools such as ServiceNow, Jira, PagerDuty, or Slack.
Designing Wazuh Alerts
When planning alerts in Wazuh:
- Define the use case – for example, “alert when new AWS EC2 Security Groups are created” or “alert on repeated failed admin logins”.
- Identify the data source – Windows Event Log, Linux syslog, cloud audit logs, or other telemetry collected by Wazuh agents.
- Choose the trigger mechanism:
- A rule‑based alert driven directly by the Wazuh ruleset.
- A Watcher that periodically evaluates a saved query and triggers when conditions are met.
- Map the response path – decide whether alerts should create Cloudaware Incidents only, open tickets through ITSM integrations, or send email/chat notifications.
Coordinate with Cloudaware Support if you need help translating requirements into Wazuh rules and Watchers at scale.
Using Watchers for Alerting
Watchers let you run scheduled queries against indexed Wazuh data and trigger actions when matches are found. At a high level:
- Create a Watcher search.
- In Wazuh, define an advanced search or saved query that captures the events you care about (for example, a specific event ID, rule ID, or field pattern).
- Test the query interactively in dashboards until it reliably returns only relevant events.
- Define conditions.
- Configure thresholds for when the Watcher should fire (for example, “any match”, “more than N events in M minutes”, or specific field values).
- Configure actions.
- Send matches to a Cloudaware incident webhook.
- Optionally, include summary fields (host, rule, severity, timestamps) in the payload so Incidents and downstream tickets are easy to triage.
- Schedule evaluation.
- Run the Watcher frequently enough for timely alerts without overloading Wazuh (for example, every few minutes for security‑sensitive patterns).
Use Watchers when you want more flexible, query‑driven alerting on top of the standard Wazuh ruleset.
Integrating with Cloudaware Incidents
To treat a Watcher firing as an incident in Cloudaware:
- Point the Watcher action at the Cloudaware Incident webhook URL configured in Cloudaware Incident Webhook integration.
- Map key fields from the Wazuh event into the incident payload, such as:
- Affected CI or host identifier.
- Rule ID or category.
- Severity/level.
- Short description and timestamps.
- In Cloudaware, use incident routing, workflows, or Monitoring alerting policies to:
- Assign incidents to the right team.
- Send emails or chat notifications.
- Open or update tickets in ITSM tools, if integrated.
This pattern lets you keep Wazuh focused on detection while Cloudaware owns routing, enrichment, and reporting.
Example Use Cases
Common examples where Wazuh alerts are useful include:
- Cloud configuration changes.
- Alerts on creation or modification of security groups, firewall rules, or IAM roles as observed in Windows or Linux logs.
- Suspicious authentication activity.
- Repeated failed admin logins, unusual
sudousage, or logins from unexpected locations.
- Repeated failed admin logins, unusual
- File integrity monitoring.
- Unauthorized changes to critical configuration files or registry paths.
- Policy violations.
- Detected by Wazuh rules aligned with frameworks such as PCI DSS, HIPAA, or CIS benchmarks.
For each use case, pair Wazuh detection logic with Cloudaware Incident routing rules and CMDB context so alerts land with the correct owners and priority.