Native Auditing Tools – Performance, Cost, and Compliance Issues

As we covered in a previous post, data-centric security measures need to be implemented to meet compliance requirements and protect against complex, ever-evolving attacks.
There are two primary approaches to implementing these measures:

• Native auditing, which uses a database server’s built-in tools to record activity at the database, database object, and user level. The log may be fed into SIEM tools to find issues.
• Database activity monitoring, which is a suite of tools that, at a minimum, identifies and reports on fraudulent, illegal, or other undesirable behavior, with minimal impact on database operations and productivity.

Due to concerns about cost and destabilization of the existing database environment, many enterprises decide to use the native audit tools provided by their database vendors. The obvious benefit of this approach is that the tool is already part of the database server and does not require additional cost for third-party appliances or software. However, depending on organizational needs, native audit might not be the optimal tool or even an adequate one.
In this post we look at the potential performance, hidden costs, and compliance issues associated with using native auditing tools.

Also, check out the whitepaper from the Ovum research team, “A Buydown for Risk: Why Data Security is a Must,” where you can learn how to deploy a data security strategy that better protects your most vital asset than core or edge security will.)

Performance Issues

Native auditing, which uses the same hardware resources as the production system being audited, is known to heavily consume CPU, disk I/O, and memory resources. This often results in a 20 percent performance degradation in environments. There are a number of reasons for this:

• An audit-trail entry is generated each time an audited trigger or event occurs at the database, object, or user level, resulting in increased disk I/O consumption and response time, with lower transactions-per-second (TPS).
• Each row of audit-trail data is placed in an in-memory buffer before being written to the audit log, resulting in increased session memory consumption.
• Each row of audit-trail data is written to the SYSTEM tablespace, resulting in increased storage consumption. In addition, there is the potential for tablespace fragmentation.

Below is an example of the performance costs incurred when running a SQL query with native auditing.

Figure 1: Performance Comparison of No Audit and Native Audit

Hidden Costs

Native auditing incurs hidden costs for hardware, software, storage, and labor. Let’s review each in detail.

Hardware & Software

Due to the approximately 20 percent performance degradation issue, you will need to add one physical or virtual server, and an appropriate number of database licenses, for every five database servers. That means, for example, in an environment with 20 database servers, each with 12 cores, you will need 4 additional servers, each with a 12 core database license, to implement native database auditing. As a result of this additional cost and overhead, many organizations scale back or eliminate auditing all together.

Figure 2: Additional servers needed with native auditing

Storage

To meet compliance requirements most native audit tools are configured to capture all database traffic and user activity, even though the predominant use case is privileged user monitoring, which accounts for only 1- 3 percent of total database activity.
Besides being inefficient, auditing all activity results in massive amounts of captured data. For example, auditing 500 databases could store more than 26 terabytes of compressed data per day. This may cause log rollovers, unless you write a script to capture and retain log events before they rollover.
If your organization requires log retention, which it will for compliance purposes, then you’ll need additional secure storage to hold the retained logs.

Labor

Since native auditing tools are unique to each database platform, such as Oracle Database, Microsoft SQL Server, or IBM DB2, you need to configure the tool on each server environment. This means manually picking the tables, events, and types of objects to be audited — which can be difficult if the location of your sensitive data is unknown — and then building the appropriate SQL scripts. You then need to maintain the scripts and, during an internal or external audit, manually sift through each platform’s logs to create reports.
To summarize, there is the initial cost of building the scripts, the ongoing cost of updating scripts to account for even small changes in the environment (users, network, databases, etc.), the cost for correlating change events across multiple databases, and the cost of preparing reports for an audit.
For organizations with heterogeneous database environments, this imposes a significant obstacle to implementing a uniform, scalable audit process.

Non-Compliance

Native auditing also does not conform to several compliance regulations, including:

Change Management

Privileged users with administrative access to the database, whether legitimately or maliciously obtained, can disable native auditing activities or delete native logs to hide fraudulent activity. This defeats the requirement of being able to trace changes to an approved requisition.

Separation of Duties

Since privileged users can access both the database and the native auditing tool, there is no separation of duties. This could result in potential compliance liabilities, including financial penalties.

Forensic Auditing

Native auditing logs do not record the details necessary to support a thorough forensic investigation. For example, if someone accesses the database via a service account or web application, the log will only indicate an action taken by the service account or web application. Tracing these pooled connections to a specific user is not possible.
As a result, reporting, visibility, and forensic analysis are hampered because there is no link to the responsible user.

Data Protection

Sensitive information may end up in the native log files, which means that information is now stored in two places — the database and the log files. And the log files often lack security controls.
Nor does the native audit system have a meaningful concept of security monitoring and audit. All security requirements would need to be addressed via custom scripts and time consuming SIEM integrations and work processes. Companies utilizing this process typically investigate less than one percent of the priority one alerts.

Summary

At first glance, native database auditing tools seem like a great deal — it’s a free part of the database. But closer inspection demonstrates that this ‘free’ tool actually generates numerous hidden costs in the form of performance degradation and extra hardware/software, storage, and labor costs. In addition, native auditing fails to meet either data-centric security or compliance requirements — for example, it doesn’t provide enough ‘who, what, when, where’ details, doesn’t prevent deliberate or accidental attacks, and doesn’t provide tamper-proof audit-trails.
The alternative is database activity monitoring, which provides robust compliance and security coverage without the hidden costs associated with native database auditing.
Learn more about data protection and compliance solutions from Imperva.