What Is Database Activity Monitoring?
Database activity monitoring (DAM) is a series of tools that can identify and report on illegal, fraudulent, or undesirable data access in a database, with limited impact on user productivity and daily operations. It provides capabilities like vulnerability management, identification and classification, intrusion prevention, application-level analysis, identity and access management (IAM) integration, support for unstructured data security, and risk management support.
In this article:
Database Activity Monitoring Use Cases
Database activity monitoring is flexible and can be used for multiple use cases. Database monitoring systems can:
- Ensure separation of duties (SoD) on database administrators for SOX compliance. This is done by producing SOX-specific documents that can be used to audit and oversee database administrator activity.
- In databases with payment data, alert on any abnormal access to a payment card field, in organizations complying with PCI DSS. Encryption can be used to protect the data against theft of the entire dataset, while DAM safeguards against insider threats and other types of external threat.
- Ensure that service accounts only connect to a database via a specific source IP, and that it only uses a finite set of permitted queries. This type of monitoring can prevent compromised accounts.
- Perform closed-loop integration with external change management tools, to monitor any changes to database configuration or SQL queries. This makes it possible to monitor administrator activity and produce change management documents for compliance purposes.
Common DAM Architectures
Three common architectures used to implement database activity monitoring are interception-based, memory-based, and log-based.
Interception-based
Today, most DAM systems monitor the database by intercepting communications between the database server and the database client. DAM systems locate communication streams and receive the requests and responses without needing any input from the database.
A Database Security Proxy is a non-intrusive technique for implementing DAM. The interception can be performed at several points, including:
- At the network level, via a network SPAN or TAP port, if the information is not encrypted
- At the database memory level, for example the System Global Area (SGA)
- At the operating system level
- At the database library level
If network traffic is not encrypted, then you can use a packet sniffer. The benefit is that no processing is executed on the host. The primary downside is that both complex intra-database attacks and local traffic will not be identified.
To achieve deeper access to the database, some vendors run a probe on the host. This probe can intercept all networked or local access attempts. This can be useful if the database information is encrypted or if you don’t wish to use network gear.
However, in this architecture, the DAM appliance does the processing of the data rather than the agent, and so network performance may be impacted. Specifically, real-time session termination and local traffic could be too slow to catch unauthorized queries.
Memory-based
Certain DAM systems use a lightweight sensor that connects to secure databases. The sensor continuously polls the system global area (SGA) to gather SQL statements as they are executed. A comparable architecture is used by performance optimization tools that read from the SGA and other shared information structures.
In later generations of this technology, a lightweight sensor runs on the host and connects to the process at the operating system level to examine sensitive data structures. There are two main benefits to this approach:
- Comprehensive coverage of all database transactions—the sensor intercepts data coming from the host, the network, and from mechanisms like triggers, views, and stored procedures.
- A generalized approach that works with any IT infrastructure—it is not necessary to re-architect the network, deal with key management, or open SPAN ports if the network is encrypted. Furthermore, it can be used to safeguard databases whether they are deployed on bare metal, in the cloud, or in a virtualized environment.
Log-based
Certain DAM systems examine and extract the data from the transaction logs—commonly the redo log. By scraping redo logs, they can obtain much valuable data.
However, not all of the data needed for DAM is stored in redo logs—for example, there is no data on SELECT statements. Thus, the system needs to augment the information they collect from the redo logs with the information they gather from native audit trails.
These types of systems are a combination of a “pure” DAM system (entirely separate from the database) and a SIEM, which is dependent on information produced and logged by the database. These architectures generally require greater overhead on the database server.
Key Features of Database Activity Monitoring Systems
The core features that differentiate database activity monitoring tools are their capacity to:
- Audit and monitor all database activity separately, such as privileged user activities and SELECT transactions, without a loss of performance.
- Safely store database activity outside the observed database.
- Produce alerts when a policy violation is identified.
- Correlate and aggregate database activities from heterogeneous database control systems.
- Ensure separation of duties of database administrators, oversee their activity, and prevent tampering or manipulation of database logs.
- Offer insight into how information is seen and by whom.
Database Activity Monitoring: An Evaluation Checklist
All organizations need a database activity monitoring tool that has minimal effect on their databases. The following is a checklist that stakeholders and DBAs can use when considering solutions.
Here are things to seek from a database security monitoring tool:
- Should consume up to 1-3% of disk resources and CPU, using an agent-only method of collection. By using an agent-only collection system, as opposed to a non-inline packet sniffer, you can cluster gateways together, which guarantees high availability and improves database performance.
- Should offer ongoing, real-time monitoring of all SQL traffic, including network-based SQL traffic, Bequeath traffic (connections that do not leverage a network listener) and inter-process communication (IPC).
- Should initiate a TCP reset when blocking a session. This ensures that nothing is modified in the database, and database client connection cleanup takes place as usual. To the user, this will appear as if they lost their network connection.
- Should use minimal network bandwidth when examining incoming SQL statements to the gateway.
- Should dispatch alerts over multiple channels—a graphical user interface, emails or other alert channels, and SIEM.
Here are things to avoid in a database security monitoring tool:
- Should not require adding any new objects, scripts, or credentials to the database.
- Should not alter or require alteration of the database, database parameters, or database configuration files.
- Should not require a host reboot, except in exceptional cases.
- Should not require a database user account for monitoring, installation, or blocking traffic.
- Should not write to the file system, except when communication with the gateway is lost
- Should avoid outbound network traffic, because it can create security issues and overload the network.
Database Activity Monitoring with Satori
Satori provides smart context-rich audit and monitoring across your data stores. The audit logs are universally available for reporting and analytics, and include a lot of additional metadata added from the IdP and from Satori’s continuous data classification engine.
Learn more:
