Database Activity Monitoring: A Do’s and Don’ts Checklist for DBAs

In a previous post, we looked at the limitations of native audit, the free tool often used by database administrators (DBAs) for logging database activity. While it has its appeal—it’s already part of the database server and does not require additional cost for third-party appliances or software—native audit has issues when it comes to performance at scale, carries hidden costs, and fails to meet several compliance requirements.

In this post, we look at the benefits of database activity monitoring as another approach to implementing data-centric security measures.

(Also, check out our Ovum whitepaper, “How Modern Database Security Complements Other Tools to Mitigate Risk,” where you’ll learn how to integrate data protection features such as DAM, data discovery, security analytics and data masking with your IAM, DLP and SIEM tools for the strongest protection possible.)

Database Activity Monitoring, Defined

Gartner states that database activity monitoring (DAM) “refers to a suite of tools that… support the ability to identify and report on fraudulent, illegal or other undesirable behavior, with minimal impact on user operations and productivity.” These tools have evolved from basic user activity analysis to include robust data-centric security measures, such as data discovery and classification, user rights management, privileged user monitoring, data protection and loss prevention, etc.
According to the Securosis white paper, “Understanding and Selecting a Database Activity Monitoring Solution,” a database activity monitoring solution, at a minimum, is able to:

• Independently monitor and audit all database activity, including administrator activity and SELECT query transactions. Tools can record all SQL transactions: DML, DDL, DCL (and sometimes TCL). It can do this without relying on local database logs, thus reducing performance degradation to 0% – 2%, depending on the data collection method.
• Securely store the audit logs to a central server outside the audited database.
• Monitor, aggregate, and correlate activity from multiple heterogeneous Database Management Systems (DBMSs). Tools can work with multiple DBMSs (e.g., Oracle Database, Microsoft SQL Server, and IBM DB2) and normalize transactions from different DBMSs, despite differences between SQL flavors.
• Ensure that a service account only accesses a database from a defined source IP, and only runs a narrow group of authorized queries. This can alert you to compromises of a service account either from the system that normally uses it, or if the account credentials show up in a connection from an unexpected system.
• Enforce separation of duties, by monitoring and logging database administrator activities.
• Generate alerts for rule-based or heuristic-based policy violations. For example, you might create a rule to generate an alert each time a privileged user performs a SELECT query that returns more than 5 results from a credit card column. The trigger alerts you to the possibility that the application has been compromised via SQL injection or other attack.

Some DAM tools also:

• Discover and provide visibility into the location, volume, and context of data on premises, in the cloud, and in legacy databases.
• Classify the discovered data according to its personal information data type (credit card number, email address, medical records, etc.) and its security risk level.
• Provide pre-defined policies for PCI, SOX, and other generic compliance requirements.
• Offer closed-loop integration with external change management tools to track approved database changes implemented in SQL. Other tools can then track administrator activity and provide change management reports for manual reconciliation.

Build Your Evaluation Checklist

Every organization wants a database activity monitoring solution designed for minimal impact on their databases. With that in mind, we’ve developed a checklist that DBAs and other stakeholders can use when evaluating solutions.
Here are five things you want a database security monitoring solution to do and five things you don’t:

The Do’s

• Consumes 1- 3 percent of CPU and disk resources, using an agent-only collection method. (You can cap the resource consumption, if needed.) Using an agent-only collection method, rather than a non-inline ‘sniffer’ or an inline bridge deployment, allows you to cluster gateways. And that helps ensure high-availability performance of your database.
  • Note: This consumption is significantly lower than the approximately 20 percent associated with native database auditing.
• Provides continuous, real-time monitoring of local SQL traffic, such as IPC and Bequeth. It can also optionally monitor all incoming network-based SQL traffic to the database.
• Issues a TCP reset on a blocked session, which appears as if the client lost a network connection. As a result, nothing changes in the database and normal database client connection cleanup occurs as usual.
• Consumes minimal network bandwidth for monitoring incoming SQL statements to the gateway, plus some metadata such as response time or number of rows returned.
  • Note: You can also monitor outbound network traffic via a separate interface, but that may create security issues if you trap sensitive data. It also creates a high volume of network traffic data.
• Provides a single, graphical interface for troubleshooting. You can quickly see what resources the agent is currently consuming, as well as view a history of resource consumption. If blocking is enabled, you can specify sending an email to the database activity monitoring tool, Security Information and Event Manager (SIEM), or other notification system.

The Don’ts

• Won’t require installation of any objects in your database. No script to install. No credentials to install, other than operating credentials.
• Won’t alter or require altering of your database, database configuration files or database parameters. The agent is not touching your databases or doing anything to your databases.
• Won’t require a host reboot, except in rare use cases such as a DB2 on AIX database bounce.
• Won’t require a new or existing database user account for installation, monitoring, or blocking.
• Won’t write to the file system, except in the case of communication loss to gateway due to a block. And that can be curtailed as soon as the communication is re-established.

Summary

Given today’s ever-evolving security threats, combined with the exponential growth in both volume and use of sensitive data, it’s critical that data-centric security measures be deployed. These measures, which focus on safeguarding data as it moves across networks, servers, applications, or endpoints, come in two flavors: native database auditing tools and database activity monitoring.
Native database auditing tools, although a free part of the database, generate numerous hidden costs — performance degradation and extra hardware, software, storage, and labor expenses — while failing to meet either compliance or security requirements. Your data is still at risk.
Database activity monitoring provides the robust compliance and security coverage necessary for protecting your data, without the costs associated with native database auditing.
Learn more about Imperva’s database activity monitoring and audit and protection solutions.