Wazuh for public sector

The Wazuh dashboard includes a prebuilt NIST SP 800-53 view, so an agency can see alerts grouped under control references from the first day of operation. That view is a starting point, and it is only as accurate as the mapping behind it. Each agency must decide which controls its system is accountable for, based on the baseline it selects. SP 800-53B defines the low, moderate and high baselines as selecting 149, 287 and 370 controls and enhancements respectively. Every rule and alert category that feeds the view must then be tied to the control IDs that baseline selects, including any tailoring the authorizing official approved. Confirm each mapping against the chosen baseline profile in OSCAL, using the catalog release the agency has adopted. NIST's current release is Release 5.2.0 of 27 August 2025.

Audit records start on the endpoints and servers. Wazuh agents on Linux, Windows and other supported operating systems collect the logs the agency designates, and the Wazuh server decodes and evaluates them against rules. For control families such as AU-2 (event logging) and AU-3 (content of audit records), the team should document which event sources are enabled on each class of system, which fields are captured, and which systems cannot run an agent. Network devices and appliances that cannot host an agent can send syslog, which Wazuh also supports for agentless monitoring. Build a register of every in-boundary system and its collection method before onboarding begins, because a system missing from that register is a gap an assessor will find.

Alerts and the events behind them are stored in the Wazuh indexer, the search and analytics engine that backs the dashboard. How long those records stay available is an agency decision, tied to the retention expectations in AU-11 and to the records schedule that applies to the system. Decide the retention period, index lifecycle and snapshot policy together, then size storage for the volume the chosen log sources actually produce. Measure that volume during a pilot before committing to hardware or cloud capacity. Restrict who can delete or modify indices, and confirm that indexer access controls and backups meet the protection expectations for audit records in AU-9. Check the exact settings against the documentation for the version you run.

Treat the dashboard view as technical evidence. It shows that collection and rules are running, and it gives an assessor traceable alerts linked to controls. It does not authorize the system. The authorizing official decides on risk acceptance, and under FISMA, Inspectors General assess agency security independently and report to OMB. Before the assessment, agree with the assessor which artifacts they will accept: the OSCAL profile with the mapping, rule configuration under version control, retention settings, and sample alert records tied to specific controls. Ask the assessor to confirm the mapping approach in writing so the evidence package does not depend on a screenshot.

Some devices in an agency network cannot run a Wazuh agent, including many firewalls, switches, load balancers and appliances that do not allow third-party software on the operating system. Wazuh covers these devices agentlessly through two paths: syslog collection, where the device pushes events to the Wazuh server, and periodic API probing, where the server connects to the device's management interface and pulls data on a schedule. The first decision is which device sends syslog, which is polled through its API, and which needs both. Syslog gives near-continuous event flow but depends on the device's logging configuration. API probing captures state, such as configuration or interface status, but only at the polling interval you set. Record each device, its path and its owner before any configuration starts.

The Wazuh server holds the credentials it needs to query each device's API, so those accounts become part of your trust boundary. Create a dedicated read-only account per device or per device family, scoped to the views the probes need, and avoid reusing administrator logins. Confirm with the device vendor which endpoints expose the data you want and whether the account can read them without write permissions. Decide who issues and rotates these credentials, where they are stored on the server, and how a rotation is coordinated with the polling schedule so probes do not fail silently. Document each account in the same inventory as the devices it serves.

Syslog and API responses arrive in vendor-specific formats, and Wazuh turns them into structured fields through decoders, then assigns severity through rules. Decoders and rules are therefore built per device family, not once for the whole estate. A firewall that sends a different syslog format, facility or timestamp style than the one your decoder expects will produce events that are stored but not properly classified. Confirm that each device's clock is synchronized, that the source address in the event identifies the device correctly, and that the decoded fields include the values your alert logic depends on, such as source, destination, action and user.

Firewalls can generate very large volumes of permit and deny events, and an unfiltered feed can bury the alerts that matter and inflate indexer storage. Decide which event categories are forwarded at all, which are stored for investigation only, and which raise alerts. Use rule level thresholds, suppression of known benign patterns and documented rule overrides, and review each change so that tuning does not remove detections the agency needs for audit evidence. Estimate storage from observed event rates in your own environment during a pilot, and record the retention period each device family requires under agency policy.

Each device family needs its own decoder and rule work, and that work must be tested against real samples captured from your devices running the firmware or software version you actually operate. Build a sample library per family with sensitive values removed under your data handling rules, then run the decoders against it and record which fields and alerts pass. Repeat these tests after every device firmware upgrade, because vendors can change log formats between versions. Treat a passing test set as the acceptance criterion for each device family, and keep the samples and results with the change records so that auditors and operators can see how each detection was verified.

Keeping an offline Wazuh deployment current means running two update tracks, the software and the vulnerability data, and moving both across the boundary as verified media. The Wazuh release notes show 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, roughly one every one to two months. The most recent in that list is 4.14.9, released 14 October 2026. Plan a recurring intake window that can absorb this rhythm, and decide in advance who reviews each release note, which patches count as security fixes, and which ones wait for a full test cycle. Confirm with the release notes whether a given patch changes indexer mappings, agent behavior or default configuration, because those changes determine how much testing it needs before production.

Upgrade order matters because the components depend on each other. The Wazuh indexer stores alerts, the Wazuh server analyzes agent data and manages agent configuration and upgrades remotely, the Wazuh dashboard presents data from the indexer, and agents on endpoints report to the server. A typical sequence upgrades the indexer first, then the server (one cluster node at a time if you run a cluster), then the dashboard, and finally the agents. Treat that sequence as a starting point and confirm it against the upgrade guide and compatibility information for your target version before you begin. Take a tested snapshot of indexer data and a backup of server configuration first. Agents are usually the largest rollout, so stage them in groups and keep a rollback path for the first wave.

Verify every package and vulnerability feed on a staging system outside the enclave before it enters the isolated network. Record the file hash and any publisher signature, compare them with values obtained from the vendor through a separate channel, and keep the verification output with the transfer record. Scan the media with the agency's approved malware tools and document the result. Vulnerability detection correlates the software inventory that agents collect with vulnerability data from either the Wazuh Cyber Threat Intelligence platform or an offline repository, so the offline repository is the feed you must refresh. Before promoting it, load it on a test server and confirm that a known vulnerable package still produces a finding. This catches a failed or empty transfer that would otherwise leave the environment with stale vulnerability data and no visible error.

Treat these verification steps as audit evidence. NERC CIP-013-2, an energy sector standard, requires supply chain procurement processes to address verification of software integrity and authenticity for vendor software and patches. It is one example of the control pattern: a defined check, applied to every intake, with a record. A public sector agency should identify its own applicable requirement, which may come from its authorizing framework, its selected NIST SP 800-53 baseline, or state and local rules, and then map each intake step to the control identifiers it has chosen. Ask your compliance lead which requirement applies and what record format the assessor expects. Keep hash records, approvals and scan results together so an assessor can trace each change in the isolated environment to a package that was checked before it crossed the boundary.