Skip to main content

Wazuh Integration

Wazuh gives you agents on the machines a scanner cannot log into — servers, workstations, on-premises hosts — and a SIEM's worth of detections, configuration checks and file-integrity events about them. Connecting it to Offload Security does two things: the parts that belong next to your other findings are synced in (agents, alerts, host CVEs), and the rest is browsed live from an in-platform dashboard so nobody has to keep a second console open.

Where: connect under Integrations → Wazuh; browse under Infra Command Center → Endpoint Security (the tab appears once Wazuh is connected for the team).

What syncs, and where it lands​

Every 30 minutes (and on Sync now) the platform reads the Wazuh Manager API and the Indexer (OpenSearch):

Wazuh dataBecomesNotes
AgentsAssets in Asset Inventory — name, IP, OS, agent status — and nodes in the security graph behind Attack PathsAn agent on a cloud VM is correlated with that VM (by hostname, then IP) so it appears as the EC2 instance / Compute Engine instance / Azure VM the cloud scanner already knows, not as a second "endpoint"
Alerts with rule level ≥ 7Entries in the unified Alerts stream, source integration, de-duplicated per rule and agent with an occurrence countSeverity from the rule level: 7–11 medium · 12–14 high · ≥ 15 critical; MITRE technique ids carried through
Vulnerability state (per agent, package, CVE)Vulnerability occurrences in Vulnerability Management, de-duplicated per (agent, package, CVE)The same CVE on a container image and on a host is triaged side by side
Active responsesSnapshot for the dashboard

Sync needs the Indexer: a Manager-only connection syncs agents and nothing else, and the wizard says so as a warning you must accept.

The Endpoint Security dashboard​

Overview counts (agents, alerts, vulnerabilities, last sync), then:

TabContentSource
AgentsThe fleet: name, IP, OS, version, status (active / disconnected / never connected), last keep-alive; browsable beyond the snapshotManager, live
AlertsDetections with rule, level, agent, ATT&CK technique; browsableIndexer, live
VulnerabilitiesHost CVEs by agent and package with severityIndexer, live
ComplianceSecurity Configuration Assessment (CIS-style) results per agent — policy, pass / fail counts, failed checksManager, live per agent
File IntegrityFIM events per agent — path, change type, timeManager, live per agent
MITRE ATT&CKTechniques and tactics seen in the alertsIndexer

A dataset the Indexer refused (wrong credentials, index missing) is flagged on the page rather than shown as empty.

Not copied into the platform: SCA and FIM results are browsed, not imported as compliance evidence or findings; alerts below rule level 7 are not synced; Wazuh's own dashboards, rules and agent management remain in Wazuh.

Connect Wazuh​

Integrations → Wazuh → Connect — fields, the Manager + Indexer test and the private-address rule are on Wazuh in the Integrations section. In short: wazuh_host / wazuh_port (55000) and a read-only API user; Indexer host, port (9200) and credentials for split deployments; verify_ssl with your CA certificate; and, because a Wazuh Manager is almost always on a private address, ALLOW_PRIVATE_SCAN_TARGETS=true on the platform host.

Why it matters on-premises​

  • The host layer, joined up. A public S3 bucket, a vulnerable container image and a server with a KEV-listed package look like three tools' problems; here they are three findings on one queue, with the server's exposure known because its VM is the same asset the cloud scan saw.
  • Detections next to posture. A Wazuh alert about a brute-force on an internal host lands in the same alert stream — with the same Slack routing and SLA rules — as a critical cloud finding.
  • Evidence you already generate. Agent coverage, SCA pass rates and FIM activity are the operational evidence behind endpoint-hardening controls; the dashboard is where an auditor can be shown them.
Last updated on