Connecting Wazuh

If you already run your own Wazuh deployment, connecting it here pulls Wazuh's own rule-engine alerts into the Qorionix SIEM incident queue, the same pre-triaged shape as a GuardDuty finding - Wazuh has already scored the event against its rule set before Qorionix ever sees it. This is a genuinely more complex connector than most in the catalog, because Wazuh is really two products behind one name.

The Wazuh Manager API (agent inventory)

1. 1

   Note your Manager API URL

   The Wazuh Manager API listens on port 55000 by default. Confirm the host and port for your deployment.

2. 2

   Use a dedicated integration account

   A manager account with read access to agents is enough. Use a dedicated account for this rather than the default wazuh-wui account, so you can see this connector's own activity separately in Wazuh's own logs and revoke it independently later.

The Wazuh Indexer API (alerts)

1. 1

   Note your Indexer URL

   The Wazuh Indexer listens on port 9200 by default - a different host or port from the Manager API in most deployments, even though both belong to the same Wazuh installation.

2. 2

   Use an account with read access to the alerts indices

   The account needs read access to the wazuh-alerts-* indices specifically. This is a separate credential from the Manager account above - Wazuh does not share one login across both APIs.

Connecting it in Qorionix

Under Integrations -> Catalog -> Wazuh, choose SIEM log sources, and enter all four values: the Manager URL and its username and password, then the Indexer URL and its username and password. Press Test and save - the test authenticates against both APIs separately and only saves the connection if both succeed. Agent inventory and recent alerts appear after the first poll.

Once connected, Wazuh alerts poll far more often than most cloud-alert sources - once a minute by default, rather than every five minutes the way GuardDuty and Defender for Cloud do - because alerts land in the Indexer close to real time rather than in periodic vendor-side batches. On the first poll, Qorionix looks back one hour; after that, each poll picks up only alerts newer than the last one it saw, tracked per connected instance rather than by re-fetching the whole alert history every cycle. A re-poll of an alert already imported does not open a duplicate incident - it is matched on Wazuh's own alert id, the same dedup approach GuardDuty and Defender for Cloud use for their own finding ids.

Severity is Qorionix's own three-band mapping of Wazuh's documented rule levels: levels 0-6 are treated as low, 7-11 as medium, and 12-16 as high, then collapsed onto Qorionix's five-band incident severity scale. This is the same shape decision GuardDuty's own three-band severity range gets mapped through.

What does not come across yet

This is a real, current gap rather than a design choice you should work around - the underlying data is already flowing into Qorionix from the Manager API, it simply is not yet turned into endpoint records the way the EDR connectors' device lists are. If this matters for your rollout, treat Wazuh today as a log source that generates incidents, not as a source of endpoint inventory.