Deploying Wazuh

Step 1: Examine the Wazuh configuration

Open materials/wazuh/docker-compose.wazuh.yml. This is the Docker Compose overlay that adds Wazuh to the existing environment.

Wazuh has three components. The Wazuh manager is the rule engine -- it receives events from agents, applies detection rules, correlates alerts, and maps findings to MITRE ATT&CK. The Wazuh indexer is OpenSearch-based storage -- it stores the events and makes them searchable. The Wazuh dashboard is the web interface for viewing alerts, managing rules, and reviewing compliance data.

This is a categorically different system from Loki. Loki is a log aggregation system: it stores logs, indexes them by labels, and makes them queryable with LogQL. Wazuh is a SIEM: it collects logs AND applies rules, correlates events, and generates structured alerts. Having both is not redundant -- they serve different purposes and answer different questions.

Step 2: Deploy Wazuh

Direct AI to deploy Wazuh by adding the overlay to the existing Docker environment. The compose file joins the same network as your existing services.

docker compose -f docker-compose.yml -f ../wazuh/docker-compose.wazuh.yml up -d

Once the containers start, verify the Wazuh dashboard is accessible at http://localhost:5601. The default credentials are in the compose file comments. Log in and confirm the manager is running and the indexer is connected.

AI commonly deploys Wazuh with default settings and reports it as complete. Deployment is the starting point, not the finish line. What matters is what happens next.

Step 3: Install Wazuh agents

Open materials/wazuh/wazuh-agent-config.md. This guide explains what agents do and how to install them.

Wazuh agents change the data collection model. Without agents, Alloy scrapes container stdout -- it sees what the application writes to its logs. With agents installed inside the containers, Wazuh sees system-level events: file integrity changes, process execution, authentication events, kernel messages. These are events the application logs never capture.

Direct AI to install agents on all three portal containers -- tourism-portal, guide-system, and operations-platform. Configure the agents to report to the Wazuh manager. AI may configure agents with default settings that miss relevant log collection channels. Verify that each agent is reporting by checking the manager's agent list in the dashboard.

Step 4: Observe the alert volume

Open the Wazuh dashboard's Security Events module. Within minutes of deployment, alerts begin accumulating. File integrity monitoring fires on package updates. Authentication rules fire on sudo commands. Network rules flag DNS queries. System service rules trigger on container lifecycle events.

This is the alert volume problem. Wazuh ships with hundreds of built-in rules. Many fire on normal system activity. A SIEM in its default configuration is a noise generator, not a detection system. AI reports the rule count as "detection coverage" without testing whether any of these rules fire on actual attacks versus routine operations. The professional task is not deploying a SIEM -- it is tuning one.

Step 5: Compare Loki and Wazuh

Open Grafana Explore alongside the Wazuh dashboard. Look at the same time period in both systems.

Loki shows application-level events: HTTP requests hitting the tourism portal, API calls between services, Flask request logs from the guide system. These are what the applications chose to log.

Wazuh shows system-level events: file modifications inside the containers, authentication attempts, process execution, network connections. These are what the operating system reported through the agents.

The overlap is minimal. For the same minute of activity, Loki and Wazuh show almost entirely different events. This is the architectural distinction: Loki tells you what the applications did, Wazuh tells you what the systems experienced. A complete monitoring strategy uses both because each sees what the other cannot.

Step 6: Begin tuning

Identify the noisiest default rules -- the ones firing dozens of times on routine container operations. These are not wrong rules; they are rules that do not matter for this engagement. File integrity alerts on package manager activity in a Docker container are expected behavior, not security events.

Direct AI to suppress the irrelevant rules. AI tends to apply tuning decisions without considering why a rule exists in the first place. Before suppressing a rule, understand what it detects and whether suppressing it creates a blind spot. Some noisy rules are noisy because the environment is misconfigured, not because the rule is wrong.

The goal is not zero alerts. The goal is that every alert that remains represents something worth investigating.