CIS Benchmark Extract -- Wazuh Deployment
These benchmark items are relevant to a Wazuh deployment in a Docker environment. This is not the full CIS benchmark -- it is an extract of items applicable to this engagement. Your job is to assess which items matter for the Bhutan Tourism Council's deployment and which are lower priority given the context.
Items
WZ-01: Default Administrative Credentials
Description: Change default administrative credentials for the Wazuh dashboard and API. Rationale: Default credentials are publicly documented. Anyone who discovers the dashboard URL can access the SIEM with full administrative privileges. Expected configuration: Unique, strong passwords for dashboard admin, API user, and indexer admin. How to check: Attempt login with documented defaults (admin/SecretPassword for dashboard, wazuh-wui/MyS3cr3tPassword for API). Relevance: Critical for any deployment. The SIEM stores security event data -- an attacker who accesses the SIEM can view all detection rules and modify them.
WZ-02: API Access Controls
Description: Restrict Wazuh API access to authorised management hosts only. Rationale: The Wazuh API (port 55000) allows remote management of agents, rules, and configuration. Unrestricted access means anyone on the network can modify the SIEM. Expected configuration: API access limited to specific IP addresses or authentication required for all API calls. How to check: Attempt API access from a non-management container (e.g., from the tourism-portal container). Relevance: High for this engagement. The three portal containers should not have API access to the SIEM manager.
WZ-03: TLS Configuration for Agent Communication
Description: Enable TLS for agent-to-manager communication. Rationale: Without TLS, agent registration tokens and event data travel in cleartext on the Docker network. Expected configuration: TLS enabled with valid certificates for agent registration (port 1515) and event forwarding (port 1514). How to check: Inspect the Wazuh manager's ossec.conf for TLS configuration. Check agent connection using openssl s_client. Relevance: Moderate for a lab environment (all traffic is on a Docker bridge network). Higher for a production deployment.
WZ-04: Dashboard Authentication
Description: Enforce authentication for the Wazuh dashboard with session timeout. Rationale: The dashboard exposes all security events, detection rules, and agent status. Unauthenticated access means anyone who reaches port 5601 sees everything. Expected configuration: Authentication required, session timeout configured (e.g., 30 minutes of inactivity). How to check: Access the dashboard URL without credentials. Check session timeout by waiting after authentication. Relevance: Critical. The dashboard is the primary interface for monitoring -- it must be protected.
WZ-05: Agent Registration Security
Description: Require authentication for agent registration. Rationale: Without registration authentication, any system on the network can register as an agent, potentially flooding the SIEM with false data or registering a rogue agent that sends misleading events. Expected configuration: Agent registration requires an authentication key or uses certificate-based enrollment. How to check: Attempt to register a new agent from an unauthorised container without credentials. Relevance: Moderate. In a lab environment, the network is controlled. In production, this is critical.
WZ-06: Log Retention and Storage
Description: Configure log retention policies for the Wazuh indexer. Rationale: Without retention policies, the indexer grows indefinitely, consuming disk space. More importantly for security, old events may contain sensitive information that should be purged after the assessment. Expected configuration: Index lifecycle management configured with retention period appropriate to the engagement. How to check: Review the indexer's ISM (Index State Management) policy. Relevance: Lower priority for a short-term assessment lab. Higher priority for a production deployment the client will maintain.
WZ-07: Rule Tuning Documentation
Description: Document which default rules have been disabled or modified and why. Rationale: Wazuh ships with hundreds of rules. During tuning, rules are disabled or modified to reduce noise. Without documentation, the next analyst cannot distinguish intentionally disabled rules from accidentally missed coverage. Expected configuration: A changelog or documentation file listing modified rules, the reason for modification, and the date. How to check: Review the local rule overrides and compare against documentation. Relevance: High for this engagement. The compliance report must demonstrate what the monitoring system detects and what it intentionally does not.
WZ-08: Network Exposure
Description: Limit Wazuh service ports to necessary interfaces only. Rationale: The Wazuh stack exposes multiple ports (1514, 1515, 9200, 5601, 55000). Each open port is an attack surface. Expected configuration: Ports bound to specific interfaces (not 0.0.0.0). Dashboard and API accessible only from management network. How to check: Run Nmap against the Wazuh containers to identify exposed ports and their binding addresses. Relevance: Moderate for a Docker lab. The Docker network provides some isolation, but the principle applies to the client's production deployment recommendation.