Why Native Database Audit Logs May Have Limits

The word “audit” is not exciting for most people. Database audits, while necessary to ensure that your organization is in compliance and private data is secure, can be tedious. Some data platforms have their own auditing capabilities, however, there may be some cases where these capabilities on their own are insufficient. 

In this post, we’ll examine what native database audits are, why auditing is important, and why relying solely on native auditing functions might not be the best idea for security and compliance.

A database audit is a log with details about the data access to the data stored within the database. The audit logs should answer questions about the data use – who accessed the data, when, what queries were they running and on what data. Different databases keep varying details about the database transactions, and keep them in different formats (sometimes they are stored as DB tables, sometimes they are exported to external logs).

Data access logs generated from audits are useful for various reasons. A few of the main ones are:

Depending on your industry, locality, and the types of data you process and store, various data privacy regulations require organizations to create and maintain data access logs. These regulations may also require logs to be held for a certain amount of time before being deleted. Not meeting such requirements may have consequences like having to go through additional tests or not being able to comply with necessary frameworks or regulations.

Regular auditing can help reduce data security risks. A few examples are:

• Being able to conduct incident response and other investigations on users’ access to data.
• Having the data to analyze and find anomalies in users’ access to data for data risk analytics.

As your organization and its database grow, the potential for the amount of data to grow out of control increases. Auditing and access log analysis can increase operational efficiency, allowing your organization to keep data collection and storage focused, accurate, and relevant.

Read more about Satori’s Auditing and Monitoring Capabilities

While database audits are necessary for any successful organization, native database auditing tools aren’t always the best choice. A few stumbling blocks associated with native database auditing include:

Many organizations rely on multiple databases, stores, and warehouses to perform their work and engage with clients. Each platform, in turn, requires its own setup and tools that perform the same tasks differently. This translates to extra time spent setting up, configuring, updating, and maintaining each database platform, all while ensuring they remain compatible with one another. The extra time and energy spent by the data engineering teams pull them away from their core responsibilities.

Committing to consistent auditing takes up plenty of time on its own with one database platform. This may include maintaining the storage and processing of the audit data, including housekeeping jobs like deleting old records, setting up storage buckets, and combining distributed audit logs.

Typically native audit logs lack metadata. If the audit log does not contain the relevant metadata then the data engineering or security teams will need to first ensure that the data is accurately described and classified before it can be audited. Further, the detection and classification of sensitive data are necessary on a continuous basis. This increases the time and resources necessary to complete a native audit.

Sometimes it’s necessary to have multiple database platforms to perform specialized tasks. However, this flexibility comes at the expense of inconsistent formats and storage systems. Different databases store data in different file formats and places, making it difficult to establish uniformity across your organization’s system. In turn, auditing across this network becomes a nightmare if you have to use native auditing tools.

If you cannot audit across your organization’s databases with uniformity, trying to analyze that information at scale becomes nearly impossible. When using native auditing tools across multiple database platforms, you’ll have to compile separate audits and then try to make sense of all the data despite format and storage inconsistencies. This is further complicated as auditing is an ongoing process.

With all the inconsistency, important elements can be left out of auditing reports, making their validity difficult to ascertain. For instance, one native database audit may contain a generic database user, not the true identity of the specific user. Another database might have a missing list of what data was pulled in the audit, and another might be missing sensitive data types retrieved. Therefore, after spending the time and energy to complete an audit, this chaotic piecemeal approach results in an incomplete audit.

Satori provides out-of-the-box auditing capabilities that are both extensive and simple to consume. This includes full information about the identity of the data consumers, what queries they sent, and what data types they were accessing. In addition, you have a complete report of the security policies that were applied on the data access, such as dynamic data masking. In Satori the audit log is consolidated across all your databases, data warehouses and data lakes.

To read more:

• Book a demo with one of our experts
• Auditing capabilities