AI-Powered SIEM & Security Operations

How the Wazuh Integration Works

The Wazuh collector authenticates against the Wazuh Manager REST API (default port 55000) using token-based auth. Once connected, it has read access to the full Wazuh dataset: active alerts, agent inventory, FIM events, vulnerability scans, SCA policy results, and syscollector hardware/software inventories. The collector does not require direct Elasticsearch access or Kibana — it operates entirely through the documented Wazuh API endpoints.

API calls are structured and scoped. When you ask "show me critical alerts from the last 24 hours," the collector translates that into a filtered request against GET /alerts with the appropriate time range and severity parameters. The raw JSON response is parsed, tagged with its source endpoint and timestamp, and passed to the AI for analysis. The AI never generates alert data — it only interprets what the Wazuh API returns.

Security Event Correlation

Raw SIEM alerts are noisy. A single authentication failure is routine. Forty authentication failures from the same source IP against three different agents within ten minutes is a lateral movement attempt. The AI performs this correlation automatically. It reads the full alert context — source IP, destination agent, rule ID, rule group, timestamp — and clusters related events into coherent narratives.

This is not pattern matching against a static rule set. The AI understands your network topology because it has access to the same device inventory used by the firewall and network collectors. It knows that 10.0.50.12 is your domain controller, that 10.0.60.0/24 is your DMZ, and that SSH traffic from the DMZ to the internal VLAN should never happen. When a Wazuh alert shows exactly that, the AI flags it as anomalous with the specific context of why it matters in your environment.

FortiGate Log Forwarding to Wazuh

A common deployment pattern: FortiGate firewalls forward syslog to the Wazuh manager over UDP 514 or TCP 1514. Wazuh ingests these logs through its ossec.conf remote syslog configuration, decodes them using FortiGate-specific decoders, and generates alerts based on FortiGate rule sets. The platform then reads those FortiGate-sourced alerts through the same Wazuh API.

This creates a centralized analysis pipeline. Firewall deny logs, IPS events, web filter blocks, and VPN authentication failures all land in Wazuh and become queryable through natural language. You can ask "show me all traffic the firewall blocked from external sources today" and get a structured breakdown that includes the FortiGate policy ID, source geo-IP, destination, and the Wazuh rule that matched.

File Integrity Monitoring

Wazuh FIM tracks file creation, modification, deletion, and permission changes across monitored agents. The platform pulls FIM events through the API and applies contextual analysis. Not all file changes are equal. A modified /etc/passwd on a production server at 3 AM is fundamentally different from an updated log rotation config during a scheduled maintenance window.

The AI evaluates FIM events against several factors: the file path (system-critical vs. application data), the time of change (inside or outside maintenance windows), the agent role (domain controller vs. development workstation), and whether a corresponding change request exists. It assigns a risk assessment to each FIM event and groups related changes — if five system files changed on the same host within the same minute, that is one incident, not five independent alerts.

Vulnerability Scanning and Agent Health

Wazuh agents run vulnerability detection by comparing installed packages against CVE databases. The platform pulls this data through GET /vulnerability/{agent_id} and presents it in context. Rather than a flat list of 200 CVEs sorted by ID, the AI prioritizes by actual exploitability in your environment.

A critical CVE in OpenSSL matters more on your internet-facing web server than on an isolated management VM that only accepts connections from a single jump host. The AI knows which agents face the internet (from your FortiGate NAT policies and Wazuh agent network data) and weights the vulnerability severity accordingly. It also tracks agent connectivity status — if an agent has not checked in for 24 hours, that is surfaced as its own finding, because a silent agent might be a compromised agent.

Real-Time Alerting vs. Batch Analysis

The Wazuh collector operates in two modes. The first is on-demand query mode: you ask a question, the collector hits the API, and the AI analyzes the response. This is the interactive workflow for investigations, incident response, and ad-hoc security reviews.

The second is continuous monitoring mode. The collector polls the Wazuh alerts endpoint on a configurable interval (default: 60 seconds) and watches for alerts above a severity threshold (default: level 12+). When a new critical alert appears, it is evaluated immediately. If the AI determines it requires attention — a rootkit detection, a hosts file modification on a domain controller, or a brute force exceeding the threshold — a notification is pushed to the operations dashboard with the full correlated analysis already complete.

This means your first interaction with a critical security event is not "there is an alert, go investigate." It is "here is the alert, here is what it means, here are the related events, and here is what you should do about it." The investigation is front-loaded.

How the AI Prioritizes Threats

Not every level-15 Wazuh alert deserves the same urgency. The AI applies a multi-factor severity model that goes beyond the rule level number:

• Asset criticality — An alert on a domain controller or database server ranks higher than the same alert on a test VM. Asset roles are pulled from the device inventory.
• Network exposure — Alerts on agents behind NAT rules (internet-facing) are weighted higher. This data comes from the FortiGate collector, not from Wazuh alone.
• Alert velocity — A single authentication failure is noise. Forty failures in ten minutes is an active attack. The AI looks at event clustering, not just individual alerts.
• Cross-source correlation — An IP that appears in both FortiGate deny logs and Wazuh endpoint alerts gets elevated. Multi-vector indicators are treated as higher confidence.
• Temporal context — System changes at 3 AM outside a maintenance window rank higher than changes at 2 PM during a scheduled patching cycle.

Plain English Security Queries

The Wazuh API is powerful but requires you to know the endpoint structure, query syntax, and field names. The platform abstracts this entirely. Natural language queries are translated into scoped API calls with the correct parameters. Here are examples of what maps to what:

• "Are all my agents connected?" → GET /agents?status=active,disconnected,never_connected
• "Show FIM changes on dc01 this week" → GET /syscheck/{agent_id}?q=date>{7_days_ago}
• "Any rootkit detections?" → GET /rootcheck/{agent_id}/last_scan across all agents
• "Which agents failed their CIS benchmark?" → GET /sca/{agent_id} with pass/fail filtering
• "Show me the vulnerability report for the web servers" → GET /vulnerability/{agent_id} filtered by agent group

You do not need to know any of this. You ask the question. The collector builds the correct API call. The AI interprets the response. Every answer includes the API endpoint that produced it, so you can verify independently if needed.

CMMC and HIPAA Compliance Mapping

Wazuh ships with built-in SCA (Security Configuration Assessment) policies aligned to CIS benchmarks, PCI DSS, and HIPAA. The platform extends this by mapping Wazuh findings directly to CMMC Level 2 practices and HIPAA administrative/technical safeguards.

When you ask "how do we stand on CMMC AC.L2-3.1.1?" the AI pulls the relevant Wazuh SCA results, FIM status, and authentication alert history to build a compliance posture for that specific practice (Limit information system access to authorized users). It does not just tell you pass or fail — it shows you the evidence: which agents pass the corresponding CIS checks, which have FIM enabled on the required paths, and whether there are any unauthorized access alerts that indicate a control failure.

This maps Wazuh telemetry to compliance evidence in a format that auditors can follow. Every finding links back to a specific Wazuh rule, agent, and timestamp. The AI generates the narrative; the data comes from the SIEM.

Agent Status Monitoring

The platform continuously tracks the status of every Wazuh agent. Active, disconnected, never connected, and pending agents are all visible through a single query. When an agent disconnects, the AI evaluates whether this is expected (a laptop that went offline) or concerning (a production server that stopped reporting at 2 AM).

Agent group membership is also tracked. If you have agents organized into groups like linux-servers, windows-dc, or dmz-hosts, the AI uses these groupings for scoped queries and to understand asset criticality. A disconnected agent in the windows-dc group triggers a different response than one in the dev-workstations group.

What This Replaces

Without the platform, the security review workflow looks like this: open Kibana, write a Lucene query, scan a table of results, mentally cross-reference with other data sources, write up your findings in a document. This takes 30 minutes for a routine review and hours for incident investigation.

With the platform, you type a question. The AI runs the queries, correlates across sources, prioritizes by real-world risk, and delivers a structured analysis with specific remediation steps. The Wazuh data is the same. The FortiGate logs are the same. The difference is how fast you get from raw events to actionable intelligence.

The AI does not replace the analyst. It replaces the manual query-building, tab-switching, and context-assembly work that sits between a security question and its answer. You still decide what to do. You just get to that decision in seconds instead of minutes.