Wazuh log management explained for security monitoring and retention

a[data-rs-seo-link]{text-decoration:underline!important;color:#1a56db!important;cursor:pointer!important;}a[data-rs-seo-link]{text-decoration:underline!important;color:#1a56db!important;cursor:pointer!important;}

What Wazuh log management does

Wazuh log management covers the collection, analysis, indexing, and retention of security-relevant events from endpoints, applications, servers, cloud services, and network devices. In Wazuh, that workflow depends on log collection, decoding, rule matching, alerting, indexing, and, when required, full-event archiving.

The main planning point is that alerts and complete log archives are not the same operational asset. Alerts help analysts respond quickly to suspicious activity. Archives preserve a broader evidence trail, including events that may not appear important until a later investigation. For organizations running video management systems, access control platforms, NVRs, switches, firewalls, and Windows or Linux servers, Wazuh can centralize much of the security telemetry around those systems. It still needs to be designed with storage capacity, source quality, privacy, and response workflows in mind.

For readers following security operations and Video Management trends, the important distinction is that Wazuh does not manage video streams. It manages logs and security events from the infrastructure that supports video and physical security operations.

How logs move through Wazuh

Wazuh documentation describes a pipeline in which monitored systems send event data to the Wazuh server, where events are decoded, checked against rules, and written as alerts when they meet configured criteria. The Wazuh agent can collect local logs from endpoints and servers. For devices that cannot run an agent, such as many network appliances, cameras, or embedded systems, syslog can be used when the device supports it. Wazuh also supports agentless monitoring for certain assets where installing an agent is not practical.

After logs reach the Wazuh server, decoders extract fields from raw events so rules can evaluate them consistently. The Analysisd component evaluates decoded events against the ruleset. Events that trigger rules at the configured level are written to alert files and can be forwarded for indexing. In common deployments, Filebeat forwards Wazuh alert data to the Wazuh indexer, which stores JSON documents and makes them searchable in the Wazuh dashboard.

• Collection: Logs are gathered from agents, syslog sources, application log files, and supported integrations.
• Normalization: Decoders parse raw events into useful fields such as source, user, action, status, and event type.
• Detection: Rules evaluate events for suspicious activity, policy violations, and operational conditions.
• Storage: Alerts are stored and indexed for investigation; full archives can be enabled when broader retention is required.
• Review: Analysts use dashboards, searches, rules, and reports to investigate activity and tune detections.

Alerts, archives, and indices are not the same thing

A common mistake in Wazuh log management is assuming that every collected event is automatically searchable in the same way as an alert. Wazuh separates alerting from full-event archiving. According to current Wazuh documentation, the default configuration values for logall and logall_json are set to no. Organizations that want to preserve or index all events, including events that do not trigger alerts, need to configure that behavior deliberately and plan for the additional storage.

Wazuh documentation also notes that enabling archive indexing can increase storage requirements. This is a material design issue, not a small configuration detail. Full log retention can be valuable during investigations, but it can also create performance, cost, privacy, and governance problems if noisy sources are indexed without filtering or a clear retention policy.

Retention planning should come before broad collection

Security log retention is not just a technical setting. NIST guidance on computer security log management frames log programs around generation, transmission, storage, analysis, and disposal. That sequence matters: a team cannot responsibly decide what to store until it knows why the logs are needed, who will review them, how long they must be retained, and what risks exist if sensitive data appears in them.

CISA ransomware guidance has also emphasized centralized log management and SIEM-style monitoring as part of defensive visibility. In practice, Wazuh should not be treated as a passive archive. It should support a defined operating model: which events require immediate review, which events support investigations, which logs are retained for compliance, and which sources should be reduced or excluded because they add noise without useful evidence.

Before enabling broad archive collection, security teams should answer several practical questions:

• Which systems are critical enough to justify full-event retention?
• Which logs are needed for authentication, administrator activity, service changes, device configuration changes, and data access?
• How long must searchable alert data remain available for daily investigations?
• How long must archive data be preserved for legal, insurance, contractual, or regulatory reasons?
• Which fields may contain personal data, credentials, tokens, camera names, badgeholder identifiers, or sensitive facility information?
• Who can search archived logs, and how are those searches audited?

OWASP logging guidance is especially relevant for application logs because it stresses consistent security event logging while warning against unsafe or excessive logging of sensitive data. For Wazuh deployments, log quality often matters more than log volume. A smaller set of well-structured authentication, privilege, configuration, and security events is usually more useful than a massive stream of poorly parsed noise.

Where Wazuh helps in video and physical security environments

In a video security environment, the most useful Wazuh data often comes from the systems around the cameras, not from the video itself. Video management software, recording servers, storage arrays, Windows domain services, network switches, firewalls, VPNs, and access control systems all produce operational or security logs that can help explain whether a camera outage, unauthorized login, service failure, or configuration change was accidental or suspicious.

Useful log sources may include Windows security events from VMS servers, Linux syslog from supporting servers, firewall denies and administrator logins, VPN access events, switch port changes, storage warnings, and application logs from systems that support export or file-based collection. Some cameras and NVRs can send syslog events, but support varies by vendor and model. Teams should verify each device’s logging capability instead of assuming that every camera can produce useful, structured events. See also: Access Control.

Wazuh can also support investigation timelines. If a recording server stops writing video, analysts may need to correlate operating system events, storage errors, authentication logs, remote access sessions, and network device changes. If only video application alerts are monitored, the root cause may remain unclear. When surrounding infrastructure logs are centrally collected and time-synchronized, the incident timeline is easier to reconstruct.

Operational limits and common mistakes

Wazuh is powerful, but log management programs often fail when the tool is expected to compensate for weak planning. One common error is enabling all archive logging before sizing indexer capacity. Another is treating default rules as complete coverage for a unique environment. Wazuh rules provide a starting point, but custom applications, physical security systems, and facility-specific workflows often need custom decoders, rules, or filtering to become useful.

• Indexing everything without a retention model: Full archive indexing can become expensive and difficult to search if noisy sources are not controlled.
• Ignoring time synchronization: Incident timelines depend on reliable timestamps across servers, cameras, controllers, firewalls, and identity systems.
• Collecting logs without ownership: Alerts need review procedures, escalation paths, and documented response actions.
• Missing application logs: Infrastructure logs are valuable, but VMS, access control, and business application logs often contain the event context investigators need.
• Logging sensitive data unnecessarily: Logs can expose usernames, badge identifiers, IP addresses, file paths, access tokens, or facility details if not governed properly.
• Assuming syslog equals visibility: A device may send syslog but still omit the security events that matter most.

The practical lesson is to start with use cases, not sources. A use case might be detecting repeated failed administrator logins to a recording server, identifying after-hours configuration changes on a switch, or preserving evidence after a camera outage. Once the use case is clear, the team can identify the required event fields, source systems, retention period, and alert logic.

A practical checklist for evaluating Wazuh log management

Use the following checklist before expanding a Wazuh deployment or relying on it for compliance evidence:

1. Inventory log sources: List endpoints, servers, VMS platforms, NVRs, network devices, identity providers, cloud services, and physical security systems.
2. Classify collection methods: Identify whether each source uses an agent, syslog, file monitoring, an integration, or manual export.
3. Define alert use cases: Document the events that should trigger review, such as privileged login failures, service stops, policy changes, malware detections, and device configuration changes.
4. Separate alert retention from archive retention: Decide how long alerts need to remain searchable and how long full-event archives must be preserved.
5. Test parsing quality: Confirm that important fields are decoded correctly before relying on searches, dashboards, or rules.
6. Size storage before enabling archives: Estimate daily event volume, index growth, compression, retention, and backup needs.
7. Protect log access: Restrict who can view, export, delete, or reconfigure log data.
8. Validate incident timelines: Run a tabletop test using sample events from several systems to confirm that investigators can reconstruct what happened.

For many organizations, the best starting point is not maximum collection. It is a controlled pilot covering the highest-value assets, followed by measured expansion as parsing, alert quality, and storage assumptions are validated.

Frequently asked questions

Is Wazuh a log manager or a SIEM?

Wazuh provides log collection, analysis, alerting, indexing, dashboarding, and security monitoring capabilities, so it is often used in SIEM-like workflows. It is also broader than basic log storage because it includes rules, decoders, endpoint security features, vulnerability-related data, and integrations. Whether it replaces or feeds another SIEM depends on the organization’s scale, reporting needs, and existing security stack.

Does Wazuh store every log by default?

Not in the same way it stores alerts. Wazuh alert output is part of the standard monitoring workflow, while full archive logging for events that do not trigger alerts requires configuration such as enabling logall or logall_json. Current Wazuh documentation identifies default values for these archive options as no, so teams should verify their own ossec.conf settings before assuming complete event retention.

Should every archived event be indexed?

No. Indexing every event can make retrospective search easier, but it also increases storage and operational requirements. A better approach is to decide which sources need hot searchable retention, which can be compressed or stored for compliance, and which are too noisy or low-value to justify full indexing.

How does Wazuh apply to camera and video systems?

Wazuh does not analyze video footage as a video management platform. Its role is to monitor the security and operational logs around the video environment, such as server authentication, service status, storage issues, network changes, firewall activity, and syslog-capable device events. That context can be valuable when investigating outages, unauthorized access, or configuration changes.