The Wazuh Enterprise Guide

Modern cybersecurity, hybrid & multi-cloud architecture, the full data source integration catalog, and how to run a SOC on top of it, all in one place.

The recent cybersecurity portfolios became strong enough to save organizations from the iron-weighted loss as the hyperscale platforms equipped with a great level of security at every layer. Architecting the modern cybersecurity landscape across cloud environments, our architect delves into the Wazuh Enterprise Editiion that becomes a compass for your organizational security. From managing data assets to protecting your environments at scale, this guide is an architectural overview of how Wazuh tightens the security in the evolving threat landscape.   

Ensure that this guide becomes a bookmark as we dwell into what Wazuh is and why we standardized it, how we architect it across our data center and every cloud we run in, how every layer of our stack from Windows server to a GKE cluster reports back to it, and how our SOC operates on top of all of it in day-to -day operations.  

Explore every aspect of Wazuh and enable it for your enterprise by following Digi edZe approach for enhanced cybersecurity.  

  • Operating Systems & Endpoints 
  • Databases 
  • Containers & Kubernetes
  • Network & Firewall Logs 
  • Application Logs 
  • Amazon Web Services (AWS) 
  • Microsoft Azure 
  • Google Cloud Platform 
  • Integration Matrix (Quick Reference) 
  • Operating a SOC with Wazuh 
  • Recommended Rollout Roadmap 
  • Glossary of Terms 
  • Further Reading & Resources 

Jump to a section 

FUNDAMENTALS

Modern Cybersecurity & Wazuh Fundamentals

Why visibility is the foundation of modern defence, and how Wazuh gives us one platform to see across all of it.

In the reign of technological footprint expansion and how well we deep dive across it, we have a widening gap between them. New services emerge in the cloud, new containers get scheduled, new SaaS tools integrate, and each one is an opportunity for an attacker to get a foothold. This is why modern security demands beyond a firewall and antivirus, and what Wazuh, an open-source platform delivers, is what we, Digi edZe standardized on, with enterprise-grade implementations across the hyperscale environments.

44%

of breaches now involve ransomware, up from 32%

$4.88M

average global cost of a data breach

70+

active ransomware groups tracked in Q1 2026

Modern Threat Landscape

The old model of security assumed a defensible perimeter, having a corporate network with a firewall at the edge, and everything trustworthy on the inside. That model is effectively gone. Our workloads now span on-premises servers, multiple public clouds, containers that live for minutes, and a long list of SaaS platforms, each with its own login, its own logs, and its own blind spots. Remote and hybrid work means identity, not network location, is now the real perimeter.

Industry research puts ransomware in roughly 44% of breaches, up sharply from the year before, and double-extortion attacks, where data is both encrypted and stolen for leverage which now accounts for around 70% of ransomware cases. Supply chain compromises have nearly quadrupled since 2020, and more than 70 active ransomware groups are being tracked at any given time, with no single group dominating. The practical takeaway is that attackers only need to find one gap, while defenders need visibility across everything, all the time.

Magic of Unified Platforms: SIEM and XDR

For years, organizations bolted together separate tools for logging, antivirus, network monitoring, and compliance reporting. Two acronyms describe where that approach has consolidated. SIEM (Security Information and Event Management) centralizes log and event data from across the environment, correlates it, and generates alerts and compliance reports from a single place. XDR (Extended Detection and Response) extends detection beyond a single endpoint agent to correlate signals across endpoints, networks, and cloud workloads, and typically adds automated response on top of detection. The current generation of platforms, Wazuh among them, combines both into one system, without needing to approach five different vendors’ tools and licenses.

Introducing Wazuh

Wazuh is a free, open-source security platform that unifies SIEM and XDR capabilities for endpoints and cloud workloads. It grew out of OSSEC, an established open-source host intrusion detection project, and has since expanded into a full monitoring, detection, and compliance platform with one of the largest open-source security communities in the world, north of 15 million downloads a year. As of mid-2026 the platform is in its 4.14.x release line, with a 5.0 release in beta.

Two things make it worth standardizing on internally. First, it’s genuinely unified with log analysis, file integrity monitoring, vulnerability detection, configuration auditing, and compliance reporting all live in one platform instead of five. Second, being open source means no per-agent licensing fee, full visibility into how detections work, and the ability to customize rules and decoders for anything we run that a generic vendor rule set wouldn’t cover.

Working Mechanism of Wazuh

The architecture has four core parts. The Wazuh agent is a lightweight process installed on servers, workstations, virtual machines, and cloud instances that collects security telemetry and forwards it onward. Devices that can’t run an agent, like network switches and firewalls, can send data in without involving the agents over syslog or an API instead.

The Wazuh manager (server) is the analysis engine. It decodes raw log data into structured fields, evaluates it against thousands of built-in and custom rules, enriches it with threat intelligence, and generates alerts. The Wazuh indexer is a horizontally scalable search and analytics engine, built on OpenSearch, that stores every alert and event for fast full-text search and long-term retention. The Wazuh dashboard is the web interface analysts live in day-to-day, turning both into searchable views, alert queues, and compliance reports.

Core Capabilities at Glance

Capability

What it does

Log analysis

Ingests and normalizes log data from endpoints, network devices, and cloud platforms in real time.

File integrity monitoring

Flags unauthorized changes to critical files, directories, and configurations.

Vulnerability detection

Cross-references installed software inventories against known CVEs.

Security configuration assessment

Audits system hardening against CIS-style benchmarks.

Intrusion & malware detection

Applies rules and threat intel feeds to catch known indicators of compromise.

MITRE ATT&CK mapping

Tags alerts with the attacker tactics and techniques they match.

Automated active response

Can automatically block an IP, kill a process, or isolate a compromised host.

Regulatory compliance

Ships with rule mappings to PCI DSS, HIPAA, GDPR, NIST 800-53, and more.

WHY IT MATTERS TO US

We generate telemetry across on-premises systems, several public clouds, and a growing container footprint. A single platform that all that data flows into shortens the distance between “something happened” and “we know what to do about it” which is the subject of the rest of this guide.

KEY TAKEAWAYS

  • Modern attack surfaces span on-premises systems, multi-cloud, containers, and SaaS — perimeter-only defense is no longer sufficient on its own.
  • SIEM contributes centralized visibility and compliance reporting; XDR contributes cross-layer detection and response; Wazuh unifies both in one open-source platform.
  • The architecture — agent, manager, indexer, dashboard — scales from a single lab machine up to enterprise fleets of thousands of endpoints.
  • Wazuh ships with prebuilt detection rules, compliance mappings, and MITRE ATT&CK context out of the box, which shortens time-to-value

ARCHITECTURE

Enterprise Architecture for Hybrid & Multi-Cloud Environments

From a single all-in-one box to a resilient cluster that spans our data center and every cloud we run in.

Above, we covered what Wazuh is and the four components it’s built from. That’s enough to run a proof of concept on a laptop. Running it as the monitoring backbone for a real environment, one that spans our on-premises data center plus multiple public clouds is a different exercise. This section covers how we design, how the components cluster, how to size them, and how to keep the whole thing available when a node, an availability zone, or an entire region has a bad day.

Design Principles for Enterprise Deployments

Four principles drive every decision below:

  • Scalability: Both the manager and the indexer need to scale horizontally, independently of each other, since event volume and query load grow at different rates.
  • High availability: No single node failure should cause data loss or an analyst-facing outage.
  • Data residency and segmentation: Some data has to stay in-region for compliance reasons, which shapes where indexer nodes physically live.
  • Least privilege: Every component talks to a specific set of other components on specific ports.

Core Components at Scale

A single all-in-one node with server, indexer, and dashboard together is genuinely fine for a pilot. Wazuh’s own guidance suggests 4 vCPUs, 8 GB of RAM, and 50 GB of SSD comfortably covers around 25 agents with 90 days of searchable history and scales up to roughly 100 endpoints on one host before it’s worth splitting out.

The Wazuh server cluster splits into a single master node and one or more worker nodes. The master holds the authoritative configuration and agent registry; workers cache that data locally and handle the actual event processing load. Adding workers multiplies capacity and gives agents automatic failover. The Wazuh indexer cluster scales the same way OpenSearch clusters generally do, assuming roughly 5 events per second (EPS) per agent, a 2,500-agent fleet is in the neighborhood of 12,500 EPS, which typically calls for 3 to 4 indexer nodes.

Reference Architecture for Hybrid and Multi-Cloud

The pattern that scales well is hub-and-spoke. Every environment forwards data into one central, highly available Wazuh cluster rather than each environment running its own isolated stack. On-premises servers, databases, and network devices reach the cluster through agents and syslog. Cloud workloads reach it two ways at once: Wazuh agents installed on VMs and container hosts for OS-level telemetry, plus direct API integration with each provider’s native security signal for the cloud-control-plane activity an agent can’t see from inside a VM. That combination matters as agents give deep host-level visibility, while the cloud provider APIs give visibility into the control plane itself. The next section covers exactly how each of these connects in detail.

Sizing the Deployment

Environment size

Wazuh server

Indexer cluster

Small — under 100 endpoints

Single all-in-one node (4 vCPU / 8 GB RAM)

Included on the same node

Medium — 100 to 1,000 endpoints

1 master + 2 worker nodes (8 vCPU / 16 GB each)

3-node cluster (8 vCPU / 16 GB each)

Large — 1,000 to 2,500 endpoints

1 master + 3+ worker nodes (up to 32 vCPU / 64 GB)

3-4 node cluster, sized to ~12,500 EPS

Very large — 2,500+ endpoints

Multiple worker pools, dedicated ingest workers

5+ node cluster, sharded; consider per-region clusters

A NOTE ON THESE NUMBERS

These figures are planning guidance, not a guarantee — actual EPS varies a lot by log source and rule tuning. Validate with a proof-of-concept against real traffic before committing to hardware, and re-check sizing whenever agent count grows materially.

High Availability and Disaster Recovery

Availability is largely built into the cluster model already described. Agents’ failover to a healthy worker node automatically, and the load-balanced dashboard means no single UI instance is a dependency. Two things still need explicit design work. First, indexer replicas that configure at least one replica shard per index, ideally spread across availability zones. Second, configuration as code to treat rules, decoders, and the manager’s ossec.conf as version-controlled artifacts rather than hand-edited files, so a bad change can be rolled back in minutes.

For organizations spanning multiple regions, the next step up is a per-region indexer cluster, keeping data resident where it’s generated for latency and compliance reasons and is federated through cross-cluster search, so analysts still get one unified view. A warm-standby manager cluster in a secondary region covers the case where an entire primary region becomes unavailable.

Network and Security Considerations

Port

Protocol

Purpose

1514

TCP / UDP

Agent-to-manager event traffic

1515

TCP

Agent enrollment

55000

TCP

Manager REST API (dashboard, automation, integrations)

9200

TCP

Indexer API (receives alerts from the manager via Filebeat)

Agent-to-manager traffic is encrypted by default (AES, 256-bit keys). Everything else should run over TLS as a standing requirement, and access to 1514, 1515, 55000, and 9200 should be restricted to monitored subnets only.  The Wazuh management plane should sit in its own network segment.

KEY DESIGN DECISION

Default to agents everywhere one can be installed including servers, VMs, container hosts. Reserve agentless collection (syslog or API) for devices that genuinely can’t run one. Agentless sources typically carry less context and lower detection fidelity than an agent, so they should be the exception, not the default.

KEY TAKEAWAYS

  • Split the server and indexer into independent clusters once you outgrow a single all-in-one node — they scale at different rates.
  • A hub-and-spoke model, with every environment feeding one central cluster, beats running isolated stacks per cloud.
  • Combine agents (host-level depth) with each cloud provider’s native APIs (control-plane visibility) rather than relying on either alone.
  • Treat rules, decoders, and manager configuration as version-controlled code, and configure indexer replicas across availability zones.
  • Lock the management plane down to its four core ports, all encrypted, reachable only from monitored subnets.

INTEGRATIONS

Complete Data Source Integration Catalog

One agent, one API, or one syslog stream at a time — how every layer of our stack reports back to a single platform.

Above, we laid out the cluster that receives and processes everything. Now for the other end of that pipeline are the actual sources. Wazuh reaches into every category of infrastructure we run that include operating systems, databases, containers, network devices, application logs, and every major cloud platform, and each connects a little differently. Getting the collection method right for each source is what determines whether the alerts that come out the other end are useful.

Operating Systems & Endpoints

This is the most direct integration where the Wazuh agent runs natively on Linux, Windows, and macOS. Once installed and enrolled, it handles log collection, file integrity monitoring, security configuration assessment against CIS-style benchmarks, root check scans for hidden processes and rootkits, vulnerability detection against the host’s installed software inventory, and active response, all from one lightweight process.

Platform

Native source Wazuh reads

Notable extras

Windows

Windows Event Log (Security, System, Application)

Sysmon integration for deep process/network telemetry

Linux

syslog, journald, auditd

Rootcheck and SCA benchmarks per distribution

macOS

Unified logging (log show), FSEvents

FIM via FSEvents for near-real-time file change detection

 

At fleet scale, agents are typically rolled out through whatever configuration management tooling already manages the servers, rather than installed by hand one host at a time.

Databases

Database activity monitoring works by turning on the database’s own native audit logging, the MySQL audit plugin, PostgreSQL’s pgaudit, SQL Server audit, or Oracle’s unified audit, and having the Wazuh agent on that host collect the resulting log file, or receive it over syslog or journald. Custom decoders then parse the raw log lines into structured fields — database user, database name, source IP, query type, authentication result — so rules can alert on privileged queries, failed authentication attempts, or schema changes outside a maintenance window, rather than every routine query.

Containers & Kubernetes

Docker hosts use a listener module on the agent installed on the host itself, capturing container lifecycle events such as starts, stops, and execs alongside the usual host telemetry. Kubernetes has two deployment patterns for the agent: a DaemonSet, which runs one agent per node to monitor that node and every container scheduled on it, or a sidecar, which runs an agent alongside one specific pod. DaemonSet is the more common choice for full-cluster coverage.

A webhook listener on the Wazuh server can receive the Kubernetes API server’s audit logs directly, which is how resource creation and destruction across the cluster gets tracked. It is useful for catching a workload or role binding that shouldn’t exist. Container image scanning for known vulnerabilities plugs into the same vulnerability detection capability used for server packages.

Network & Firewall Logs

Firewalls, switches, routers, and access points generally can’t run an agent, so they’re integrated without the agents. The device forwards syslog directly to the Wazuh manager, or in some cases is polled over SSH. Typical signals worth alerting on include failed device logins, a port going down, a VLAN change, or device-reported errors.

UDP syslog is simpler and lower overhead and is fine for most environments; TCP is worth the extra overhead when delivery has to be guaranteed, and it’s also what enables TLS encryption, which matters whenever syslog traffic crosses a segment you don’t fully trust.

CAPACITY NOTE

A single manager on modest hardware (around 4 vCPUs, 8 GB RAM) handles roughly 1,000 to 3,000 events per second, comfortably covering a campus network’s worth of switches at informational log levels. For high-volume firewalls in a busy data center, route that traffic to a dedicated syslog-ingest worker node — see the architecture section above for the cluster pattern this fits into.

Application Logs

Application logs include web servers, reverse proxies, and custom in-house applications are among the highest-signal, most under-monitored sources in most environments. The Wazuh agent tails log files directly (access logs, error logs, custom application logs in JSON or plain text), or applications can write to syslog or call the API directly for centralized shipping.

Because formats vary widely, this is where custom decoders earn their keep: a decoder maps each log format’s fields — client IP, HTTP status, endpoint, user, latency — into Wazuh’s structured schema so rules can alert on patterns that matter rather than raw noise.

Log source

Fields typically decoded

Example detection

Nginx / Apache access logs

Status code, URI, client IP

Repeated 401/403 responses — credential stuffing or path scanning

IIS logs

cs-uri-stem, sc-status

Directory traversal attempt

Custom app logs (JSON)

user_id, action, result

Privilege escalation or impossible-travel login pattern

 

Cloud Platforms

Each major cloud is integrated primarily through its own API rather than an agent watching from outside, layered on top of agents running on the compute instances themselves. The cloud APIs see control-plane activity like who changed a security group or disabled logging, while the agent sees what’s happening inside the instance. The design principal worth repeating: lean on each provider’s native detection engine rather than re-building equivalent logic from scratch as Wazuh’s job is to correlate all of those findings with everything else.  

Amazon Web Services (AWS)

AWS integrates via CloudTrail for API activity, GuardDuty for managed threat findings, S3 access logs, and VPC Flow Logs for network-level visibility, polled through Wazuh’s AWS module plus agents on EC2 instances and EKS nodes for host-level depth.

Microsoft Azure

Azure integrates via Activity Log for control-plane events, Microsoft Defender for Cloud for managed threat findings, NSG Flow Logs for network visibility, and Storage Logs alongside agents on VMs and AKS nodes.

Google Cloud Platform (GCP)

GCP integrates via Cloud Audit Logs for control-plane activity, Security Command Center for managed findings, VPC Flow Logs, and Cloud Storage Logs alongside agents on Compute Engine instances and GKE nodes.

Integration Matrix — Quick Reference

Source

Collection method

Example detections

OS & endpoints

Agent — FIM, log collection, SCA

Unauthorized file change, brute-force login, config drift

Databases

Agent + native audit logging

Privileged query, failed auth, off-hours schema change

Containers / Kubernetes

Agent (DaemonSet) + Docker/K8s listener

Unauthorized pod creation, image with a known CVE

Network & firewalls

Agentless — syslog / SSH

Port flapping, ACL change, repeated failed device login

Application logs

Agent (log tail) / syslog / API

Credential stuffing, injection pattern, privilege escalation

AWS

Agentless API (CloudTrail, GuardDuty) + agent on EC2/EKS

Exposed S3 bucket, disabled CloudTrail, anomalous IAM use

Azure

Agentless API (Activity Log, Defender) + agent on VMs/AKS

Suspicious sign-in, NSG rule change, exposed storage

GCP

Agentless API (Audit Logs, SCC) + agent on Compute/GKE

IAM privilege grant, public bucket, anomalous API call

 

BEST PRACTICE

Tag every custom decoder and rule with the source it belongs to, and document which integration owns which data type before turning on a second path for the same source — a cloud VM’s OS logs arriving through both the agent and the cloud provider’s log export is a common way to quietly double alert volume without adding any real coverage.

KEY TAKEAWAYS

  • Servers, containers, and applications get the deepest visibility because they can run an agent directly; databases layer an agent on top of native audit logging.
  • Network devices and cloud control planes are integrated agentlessly — syslog for the former, provider APIs for the latter.
  • All three major clouds follow the same agent-plus-API pattern, which keeps operations consistent across AWS, Azure, and GCP.
  • Tag and document every custom decoder by source to avoid double-ingesting the same event through two different paths.

SOC OPERATIONS

Operating a SOC with Wazuh

The platform is wired up and receiving data from everywhere — here’s how an analyst actually works inside it, day to day.

Everything above covers what Wazuh is, how to architect it across a hybrid and multi-cloud environment, and how to connect every layer of infrastructure to it. None of that matters unless a SOC analyst can turn the resulting data into decisions faster than an attacker can act. This section is about that operational layer.

Detection Lifecycle from Alert to Action

Every alert moves through the same six stages:

  • Telemetry is collected from agents and integrations across the environment covered above.
  • Manager correlates that telemetry against rules and decoders, tagging matches with MITRE ATT&CK tactics and techniques where relevant.
  • When a match clears its rule’s severity threshold, an alert is generated.
  • An analyst triages it before moving to investigation and response, which might be manual or automated.
  • Finally, a post-incident review feeds lessons back into the rule set itself, tightening or adding detections.

Alert Severity and Triage

Wazuh rules carry a severity level from 0 to 15, and the single highest-leverage tuning decision a SOC makes is what to do with each band. A common, workable pattern: treat level 7 and above as real-time, same-day triage, and route levels 4 through 6 into a queue for weekly review. Capacity matters here with a team of one or two analysts can realistically triage somewhere in the range of 20 to 50 meaningful alerts a day. If a deployment is generating 500 or more, that’s almost always a tuning problem.

Level range

Typical meaning

Typical SOC action

0 – 3

Informational, low value on its own

Log for context; no direct action

4 – 6

Notable, but not urgent in isolation

Weekly review queue

7 – 11

Suspicious or actionable

Real-time triage, same-day investigation

12 – 15

Critical, high-confidence

Immediate escalation, active response

Threat Hunting with MITRE ATT&CK

Wazuh’s MITRE ATT&CK module tags matching alerts with the attacker tactic and technique they resemble, turning a flat alert queue into something closer to a map of attacker behavior. One published research evaluation of Wazuh against the ATT&CK framework found strong detection coverage for command-and-control and impact techniques, only partial coverage for collection and exfiltration, and roughly 85% overall coverage across the tested tactics, a useful data point, though actual coverage depends heavily on what’s been configured and tuned in a given environment.

The practical approach to closing gaps is a continuous loop through weight techniques by how relevant they are to the environment and its likely adversaries, use threat intelligence to focus effort, engineer and tag new detections for the highest-priority gaps, and re-measure coverage before picking the next gap to close.

Automating Response and Reducing Noise

Wazuh agents support active response out of the box by automatically blocking an IP, killing a process, or isolating a host when a high-confidence rule fires, and the manager integrates with open threat intelligence feeds like VirusTotal, AlienVault OTX, URLHaus, and MISP to enrich indicators before an analyst ever sees them. For case management, community-built playbooks commonly connect Wazuh to SOAR-style tools such as Shuffle and TheHive or DFIR-IRIS, turning a raw alert into a tracked case with the enrichment already attached.

BEST PRACTICE
Suppression rules quietly rot. A rule that correctly filtered noise three months ago can end up hiding a real attack path today, especially after infrastructure changes. Put suppression and noise-filtering rules on a quarterly audit cycle, not a set-and-forget one.

Compliance and Reporting

Wazuh’s default ruleset ships with pre-built mappings to PCI DSS, HIPAA, GDPR, NIST 800-53, TSC (SOC 2), GPG13, and ISO 27001, a single rule firing can carry compliance tags for several standards at once. The Security Configuration Assessment module runs on a schedule to catch configuration drift automatically, and the dashboard turns both alert history and SCA results into reports, meaningfully cutting down the manual evidence-gathering audits usually require.

KEY TAKEAWAYS

  • Every alert follows the same lifecycle — collect, correlate, alert, triage, respond, review — and the review stage feeding back into correlation is what keeps the system improving.
  • Tune severity thresholds deliberately: real-time triage above a set level, a weekly queue below it. 500+ alerts a day is a tuning problem, not a capacity one.
  • Treat MITRE ATT&CK coverage-building as a continuous measure-gap-build-remeasure loop, not a one-time project.
  • Active response and threat-intel enrichment reduce analyst load automatically; suppression rules need a standing quarterly audit.
  • Compliance mapping and SCA reporting are close to free once the platform is deployed correctly — let them absorb audit prep work.

Share:

Recent Posts

Categories: