Glossary

Database activity monitoring (DAM)

Also called DAM, database auditing, database activity monitoring and protection

Database activity monitoring (DAM) is the practice of capturing, analysing and alerting on who does what inside a database, including queries, schema changes, privilege grants and sign-ins, so that misuse is detected and every action is attributable.

Rudratic glossary

Databases hold the records attackers want most, and the accounts that can read them in bulk are often application or administrator accounts that nobody watches closely. Database activity monitoring gives security teams a running account of what happens inside each database: which identity ran which statement, from where, and whether that was normal. It turns raw audit records into alerts, investigations and audit evidence.

How it works

Every major engine can audit itself. Oracle describes auditing as the monitoring and recording of database activity, with unified auditing collecting records from many sources into one trail. PostgreSQL’s log_statement setting can record DDL, data-modifying statements or all statements, and its documentation warns that logged statements may contain sensitive data. A DAM platform builds on these sources:

  1. Collect audit events from each engine, by network inspection, host agents or reading native audit trails.
  2. Normalise them into one format so Oracle, SQL Server, PostgreSQL and MySQL events can be searched together.
  3. Analyse activity against rules and per-identity baselines.
  4. Alert on schema changes, privilege escalation, failed sign-in bursts or unusual reads of sensitive tables.
  5. Report with filtered, exportable evidence for auditors.

Why it matters

Auditors ask for it directly. NIST SP 800-53 Rev. 5 control AU-6 requires reviewing and analysing audit records for signs of inappropriate or unusual activity, and AC-6(9) requires logging the use of privileged functions. The HIPAA Security Rule at 45 CFR 164.312(b) requires mechanisms that record and examine activity in systems containing electronic protected health information. Native logs alone rarely meet these needs: they are scattered across engines, hard to correlate and easy to ignore.

DAM vs PAM

DAM PAM
Question it answers What did each identity do in the database? Who may get privileged access, and how?
Covers All database identities, including application accounts Human and machine privileged sessions
Typical output Risk scores, alerts, forensic audit log Approvals, brokered sessions, recordings

The two complement each other: PAM controls the door, DAM watches what happens inside, including activity that never passed through the PAM proxy.

Examples

  • A reporting account runs SELECT * on a salary table at 3 am from an unfamiliar workstation and is flagged.
  • DROP TABLE runs on a production schema outside the maintenance window and raises an alert.
  • An auditor receives a signed export of every privileged action on cardholder databases for a quarter.

How SWOT supports it

SWOT DAM is self-hosted DAM for Oracle, PostgreSQL, SQL Server, MySQL and managed cloud databases. Collectors sign in with read-only credentials and poll each native audit trail, with no inline proxy, and each identity gets a risk score from 0 to 100 against its own 30-day baseline. It also finds sensitive columns and exports signed CSV or PDF evidence. See database security.

Questions

How does DAM collect database activity?
There are two broad approaches. Some tools sit in the network path or on the host and inspect traffic as it passes. Others read the audit trail the database engine already writes, such as Oracle unified auditing or PostgreSQL pgAudit, through read-only collectors. The second approach avoids changing how transactions run, but depends on native auditing being switched on.
What is the difference between DAM and database logging?
Database logging records events; DAM turns them into security information. It normalises records from different engines, attributes them to identities, compares behaviour with a baseline, raises alerts on rules such as privilege escalation or mass reads, and exports evidence for auditors. Logging alone leaves that analysis to whoever reads the logs.

In SWOT

Sources

  1. Oracle Database 19c Security Guide: Introduction to Auditing
  2. PostgreSQL documentation: Error Reporting and Logging
  3. NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations
  4. Legal Information Institute: 45 CFR 164.312, Technical safeguards

Related terms