Wazuh for NIST SP 800-53 audit and accountability

AU-12 requires three things from the system: audit record generation capability on defined system components, the ability for defined personnel to select which event types each component logs, and records for the selected event types that carry the content AU-3 defines. Wazuh does not make these decisions for you. The event types themselves come from the organization's AU-2 selection, and the team must map each of them to a component and to a Wazuh collection path before the deployment is designed. Start with an inventory of the components in scope, then record which event types each one is expected to produce. Without that list, the Wazuh deployment can collect a lot of data while still leaving gaps an assessor will find.

Wazuh agents installed on endpoints are the primary collection path for host-based events. The Wazuh documentation lists agents for Linux, Windows, macOS, Solaris, AIX and HP-UX. Agents forward endpoint events to the Wazuh server, which decodes them and applies rules before alerts are stored in the Wazuh indexer. Coverage differs by operating system and by how each host is configured, so the team should confirm, for each platform in scope, which log sources the agent reads and which event types it actually produces in the team's own environment. A test host per operating system, checked against the selected event list, is a practical way to find gaps before go-live.

Devices that cannot run an agent, such as firewalls, are covered through agentless collection. Wazuh documents syslog collection and periodic API probing for these devices. Wazuh can only record what the device emits, so the event types selected for each device must be enabled on the device itself, and the destination and transport must point to the Wazuh server. The team should confirm the logging level on each device, the syslog format it sends, and whether the device's clock is synchronized with the rest of the environment, since mismatched timestamps weaken later review under AU-6. Record which device configuration is owned by the network team and which is owned by the security team.

The organization must document three things: which components are in scope, which event types are selected for each component and why, and how each selection was approved. The rationale matters because an assessor will check that the selection reflects the risk the organization has identified. Every change to scope or event selection, including adding a new firewall, dropping an event type to reduce volume or enabling a new agent policy, needs a change record that names the requester, the approver, the date, the reason and the expected effect on collection. Confirm with the team who owns this record before the build starts, and keep it in the same system as the Wazuh configuration so the two can be compared during assessment.

AU-6(3) asks the organization to correlate audit record repositories so that review can see patterns across systems, not just within one log store. In the SP 800-53B baselines, AU-6(3) is selected for moderate and high systems, alongside AU-6(1) on automated process integration. AU-6(5) and AU-6(6) are selected only for high systems. Before you design anything, confirm your system's impact level and baseline in its system security plan, because that decides which of these enhancements you must address. For a Wazuh deployment, the practical starting point is an inventory of every audit repository that holds records relevant to the system: host and agent logs, identity provider logs, network and firewall syslog, cloud control plane logs and any existing SIEM. Each one is a candidate correlation input.

In Wazuh, the server decodes and analyzes incoming data with its decoders and rules, and the Wazuh indexer stores the resulting alerts in a searchable form that the dashboard queries. Agents on endpoints, agentless devices reached through syslog collection and periodic API probing, and a clustered Wazuh server can all feed that single alert store. This gives you one place to correlate events from several sources, but it does not correlate every repository automatically. Sources outside the agent and syslog paths depend on the connectors and log sources your organization configures, and each connector needs its own field mapping, timestamp handling and retention check. Confirm with each source owner which events arrive, how long they are kept at origin, and whether the Wazuh rules can tie an identity event to a host event through a shared user or session identifier.

AU-6(5) asks for integrated analysis of audit records across the organization's systems, and it needs a documented design before the technical work starts. The design should name the sources analyzed together, the correlation logic, the owner of each rule, the review frequency and how findings are reported under AU-6. Assessors examining AU-6 under SP 800-53A look for reports of audit findings and for records of the actions taken in response, so the design should state where those records are kept and for how long. Document the rule tuning history as well, because a correlation rule changed after an incident becomes part of the evidence trail. Plan a test in which a known event passes through each source, is correlated and produces a recorded finding. Keep that test in your evidence set so you can rerun it after each Wazuh upgrade or connector change.

AU-6(6) asks for correlation of audit record review with information from physical monitoring. Wazuh is not designed to correlate with physical monitoring on its own, so this enhancement needs a physical security system whose records reach the analysis through a route you design, document and test. Ownership matters here. Facilities or a physical security team usually controls badge and camera systems, so agree in writing on the event fields, the delivery method and who reviews the combined results. If the system is not a high baseline system, AU-6(5) and AU-6(6) do not apply, but the correlation required under AU-6(3) still does. Record that decision in the system security plan so an assessor can see why each enhancement was or was not implemented.

Before you write the Wazuh evidence into a system security plan, establish what it cannot prove. The Wazuh indexer, server, dashboard and agents can generate, store and display alerts for AU-6 and AU-12, but both controls depend on decisions and records outside the product. AU-12 requires defined personnel to select which event types each component logs, and those event types come from AU-2. The other AU controls, including AU-3 record content, audit storage capacity, protection of audit information and time stamps, need their own mapping in your documentation. A dashboard view labeled for NIST SP 800-53 supports those mappings but does not satisfy them.

The review procedure for AU-6 is organizational. You must define how often audit records are reviewed, which kinds of inappropriate or unusual activity count, who performs the review, who receives the findings and how review depth changes when credible information indicates a change in risk. Wazuh can raise alerts and provide a triage workflow, but the roles, escalation paths, on-call duties and records of actions taken must come from your own process. Confirm that the named personnel in the procedure match the people who actually triage alerts, and that your ticketing or case records show the outcomes an assessor will examine.

AU-6(6) correlates audit records with physical monitoring, and Wazuh does not perform that correlation. If your system falls in the high baseline, you need a separate process or system for physical monitoring data and a documented method for reviewing it alongside logical records. The same discipline applies to the other AU-6 enhancements. Do not claim an enhancement such as AU-6(3) or AU-6(5) on the strength of a component name alone. Confirm with your Wazuh version's documentation and your own configuration that the feature exists, how it is enabled and what it does with your data before you cite it.

Wazuh only collects what its agents, syslog listeners or configured API probes can reach. Cloud control plane logs, SaaS audit trails, network devices and business applications may not produce records in a form Wazuh can ingest without a separate connector, export job or forwarding process. Agentless monitoring relies on syslog collection and periodic API probing, which may not capture every event type your AU-2 selection requires. Build a source inventory that lists each audited system, its collection method, the event types it sends and any gap that needs a connector or a manual review process.

Wazuh does not produce an assessment, an audit report or a certification. Independent assessors examine documentation, sampled records and the actions taken in response to reviews, and they interview the personnel responsible, following the procedures in SP 800-53A. Your authorizing official decides what evidence is sufficient. Also confirm which features your Wazuh version provides, because this page does not verify capabilities beyond the documented components. Ask your assessor early which artifacts they expect for AU-6 and AU-12, and plan the collection of those artifacts before the assessment begins.