Wazuh Database Activity Monitoring

Why Database Activity Monitoring Matters

Most breaches that make the news end at a database. Attackers move laterally, escalate privilege and ultimately query the tables holding customer records, card data, health records or intellectual property. Yet in many environments the database tier produces no security telemetry at all. Application logs show requests, network logs show connections, but the actual queries against sensitive data are invisible.

Database Activity Monitoring (DAM) closes that gap. The goal is a clean, searchable record of who accessed which data, through what query, from where and when, plus alerting on the patterns that indicate abuse. Wazuh provides the collection, parsing, storage and alerting layers; the database itself provides the raw audit events.

DAM also carries direct compliance weight. PCI DSS Requirement 10 expects access to cardholder data to be logged, which in practice means database access. HIPAA audit controls expect the same for ePHI. ISO 27001 logging and monitoring controls apply to the data tier as much as the host tier. So DAM is both a detection capability and an evidence source.

Enabling Database Audit Logging

Wazuh cannot monitor what the database does not record, so the first step is always native audit logging. The mechanism differs per engine. For MySQL and MariaDB, enable the audit plugin (MariaDB Audit Plugin or the MySQL Enterprise Audit plugin) to log connections and queries to a file. For PostgreSQL, deploy the pgaudit extension and configure logging of the statement classes you care about (DDL, role changes, and read or write on sensitive objects).

For Microsoft SQL Server, configure SQL Server Audit to write audit specifications to the file system or the security log. For Oracle, enable Unified Auditing and define audit policies for privileged actions and sensitive object access. In every case the output is a log file (or an OS event channel) that the Wazuh agent can read.

Be deliberate about what you audit. Logging every SELECT on a busy OLTP database will overwhelm storage and bury signal in noise. Audit the events that matter: authentication, privilege and role changes, schema changes, and access to specifically sensitive tables or schemas. This targeted approach keeps volume manageable and detections meaningful.

Forwarding and Parsing With Wazuh

Once the database writes audit logs, point the Wazuh agent at the log file using a localfile configuration block in the agent's ossec.conf, specifying the path and the log format. The agent ships each new line to the manager. For databases that log to the OS event channel rather than a file, use the appropriate Windows eventchannel or syslog collection instead.

Raw database logs are unstructured from Wazuh's point of view until you parse them. This is where decoders come in. A decoder uses regular expressions to extract fields from the log line, the database user, the client host, the query text, the affected object, so that downstream rules and dashboards can operate on structured data rather than raw strings. The default Wazuh ruleset includes decoders for common database log formats, but bespoke audit configurations usually need custom decoders.

After decoding, write rules that match on the extracted fields and assign a severity and compliance tags. A rule might fire when the query contains GRANT or when a SELECT targets a sensitive table from an unexpected host. Because rules see structured fields, you can be precise rather than matching crude substrings, which keeps false positives down.

High-Value Database Detections

Not all database activity deserves an alert. Focus detection engineering on the actions an attacker or a malicious insider takes that a normal application never does. These are the detections that earn their place in the queue.

• Privilege escalation: GRANT, role membership changes, creation of new privileged accounts.
• Schema tampering: DROP, ALTER or CREATE on production tables outside a change window.
• Bulk extraction: large result sets, SELECT * on sensitive tables, mysqldump or pg_dump style activity.
• Out-of-hours access: privileged queries at times no legitimate process runs.
• Direct database access: queries from a host or account that bypasses the application service account, a classic insider or compromised-credential signal.
• Authentication anomalies: repeated failed logins, logins from new source hosts, use of default or service accounts interactively.

Detecting Data Exfiltration Patterns

Single events rarely prove exfiltration; patterns do. A lone SELECT is normal. A single account running sequential scans across many sensitive tables, returning unusually large result sets, over a short window, is not. The art of DAM is correlating events into a pattern that crosses a threshold of concern.

Wazuh supports this through rule correlation and frequency-based rules. You can define a rule that fires only when a base event repeats a certain number of times within a time window from the same source, which catches the volume signature of a dump. You can also chain rules so that, for example, a privilege grant followed by bulk reads followed by an unusual egress event raises the composite severity.

The strongest exfiltration detection correlates the database tier with the network tier. A large database read is suspicious; a large database read immediately followed by a large outbound transfer to an unfamiliar destination is a likely exfiltration in progress. Because Wazuh ingests firewall and network logs alongside database logs, you can build cross-source correlation that neither tier could produce alone. Feed confirmed cases into your case management and SOAR layer for rapid, consistent response.

Operational Considerations

DAM is only valuable if it runs reliably and the alerts get triaged. Plan for log volume: even targeted database auditing can be substantial on busy systems, so size indexer storage and retention to match, and apply tiered retention so verbose data ages off while security-relevant events persist for the compliance window.

Protect the audit trail itself. An attacker who reaches a database may try to disable auditing or delete logs, so forward logs off the database host promptly (the Wazuh agent does this) and alert on any attempt to stop the audit subsystem or clear logs. The integrity of the monitoring is part of the control.

Finally, tune against the baseline. Every database has legitimate batch jobs, reporting users and maintenance windows that look alarming until you understand them. Spend the first weeks after deployment learning normal behaviour and suppressing known-good patterns so the alerts that remain are genuinely worth an analyst's time. Codesecure handles this tuning as part of managed SOC onboarding.