Why Native Database Auditing is Insufficient
MS SQL, Oracle, DB2, and mainframe databases all have built-in utilities that can capture audit activity. Enabling these built-in utilities (i.e. MS SQL’s Trace) typically is the first method that organizations try, because these logging utilities are included as part of the operating system. As the impracticality of using these utilities for monitoring comes to light, alternatives must be considered. Every experienced DBA will say that the built-in auditing utilities are not designed for live production environments.
All of the database logging tools, seriously degrade the database performance and increase the CPU usage. For this reason alone, DBAs don’t want to enable logging on their databases unless there is a dire emergency. This is definitely not the ideal scenario for trying to monitor database activity or protect data assets. Database auditing utilities are meant to be used to profile and debug the database during development, not to use them to perform real-time database activity monitoring.
Database SQL queries can reach in the millions of transactions per day on a heavily accessed business database. The majority of the logs that are generated by native logging utilities are not easily readable. Roughly 90% of the event logs are unrelated to the critical tables that security teams or DBAs are interested in monitoring. Collecting and monitoring every SQL query transaction, on a given database, can be a huge waste of company resources. Compound that problem by the number of databases within the organization and you have a real serious dilemma. Hard drive space can fill up very quickly, not to mention the time and effort to review the output. It can be an overwhelming and discouraging task to wade through all that data manually.
Native Database Auditing Lacks Incident Management
In addition, to the performance issues of native database auditing, those utilities also don’t provide ways to alert key stake holders of abuse of data within the database. They also don’t have built-in security response protocols. Database activity monitoring solutions need to be able to automatically respond to particular actions made towards customer private data. There are many reasons why employees (i.e. insiders) may try to abuse or steal customer data. Hackers, of course, are looking to resell the data on the open market. The key is to identify abusive actions and prevent further attempts. Real-time alerting can be extremely valuable to detect unauthorized behavior and, automatically launch security protocols based on the suspicious activity. Protocol violations and security breaches can go on undiscovered for days, weeks, or even longer. Any unauthorized action made towards critical tables, inside the database, must be monitored and responded to by security personnel.
Other database activity monitoring (DAM) solutions sniff database traffic at the network layer. This can limit their ability to track direct access to the database from internal users (i.e. insider threats). Other solutions also have problems monitoring encrypted tables. Either of these limitations can defeat the purpose of monitoring the database activity in the first place. LogClarity tracks all activity, without any limitations.
LogClarity® Database Edition provides a complete, unobstructed view of database activity, including tracking privileged users. Security personnel, in charge of ensuring security of the data, can easily discern unauthorized use or abuse at-a-glance.