IBM Security Guardium

 View Only

Database Activity Monitoring: Agent-based vs. Native Logging

By Walid RJAIBI posted Thu July 09, 2020 11:36 AM

  
Guardium.jpg

Introduction

The emergence of cloud database services has driven several Database Activity Monitoring (DAM) solutions to enable and consume native database auditing in order to provide visibility into user activities. Traditionally, DAM solutions have provided this visibility independently of the database system by deploying a software agent on the database server. Unfortunately, this traditional approach did not carry over to cloud database services because clients do not have access to the underlying operating system in order to deploy such agents. Thus, DAM solutions turned to native database auditing as an alternative to acquire the data they need for compliance reporting, analytics and other capabilities. While native database auditing may be a reasonable alternative when deploying an agent is not feasible, adopting this approach otherwise requires careful considerations. The goal of this paper is to describe and contrast both approaches to help clients make well-informed decisions when adopting one approach or another.

Agent-based Approaches

In the agent-based approach, a software agent is deployed on the database server. This is typically a kernel module which extends the host operating system. As such, the agent is able to see all requests coming into the database as well as all responses going out of the database. In other words, the agent-based approach enables database activity monitoring independently of the database system and the database administrator (DBA). Figure 1 gives a high-level overview of the agent-based approach (labeled as STAP) in IBM Security Guardium.


Figure 1: Agent-based approach in IBM Security Guardium

An agent-based approach ensures Separation of Duties (SoD) between the DAM administrator and the DBA. This SoD is critical for adhering to zero-trust security because it does not rely on the database system and the DBA to monitor themselves. Additionally, an agent-based approach provides the opportunity to extend the SoD property to enforcement as well. For example, a policy can be specified to have the agent block the DBA from retrieving data from a sensitive table. Similarly, a policy can be specified to have the agent redact sensitive data in a query result set that is destined to an unauthorized user.

Additionally, an agent-based approach is not affected by the type of workload running on the database (e.g., OLTP, Warehousing) because it operates within the operating system and independently of the database system. This property keeps the monitoring overhead on database performance to a minimum, typically in the low single digits.

Native Logging Approaches

In native logging approaches, the DAM solution would first enable the native auditing capability of the database system. This causes the audit processing component of the database system to start generating audit records for database activities. These audit records are then written to storage either synchronously or asynchronously depending on the audit policy enabled. Then, the DAM solution typically leverages a set of APIs to retrieve those audit records from the location where the database system has stored them. Typically, the database system would store these logs in a set of files on the database server. Figure 2 gives a high-level overview of the native logging approach in IBM Security Guardium.

Figure 2: Native Logging approach in IBM Security Guardium

 

Unlike agent-based approaches, native logging does not ensure SoD because the audit capability is still within the full control of the DBA. This lack of SoD makes it harder to adhere to zero-trust security. Additionally, native logging approaches do not permit the DAM solution to do any kind of enforcement whether on the database access side or the database response side. In this case, the DAM solution is simply an after the fact consumer of the audit records.

While the diminished security of native loggings may be acceptable to some clients depending on their risk tolerance, the impact on performance requires careful consideration. In fact, since it is the database system that is generating and writing audit records to storage, this extra processing interferes directly with core database processing such as query execution. The actual impact is known to depend on three key factors. First, it is the audit policy itself. For example, auditing a specific user would have less impact than auditing all activities by all users. Second, it is whether audit records are written to storage synchronously or asynchronously. Synchronous writing is best from a security perspective, but not advantageous from a performance perspective as it results in a larger number of disk I/O. Asynchronous writing is best from a performance perspective, but not advantageous from a security perspective because if a problem occurs a whole buffer of audit records would be lost. Last, but not least, it is the nature of the database workload. Data Warehousing workloads would see a lesser impact because this type of queries typically runs longer. On the other hand, On-Line Transactional Processing (OLTP) workload would see the highest performance impact because these are typically short-lived queries.   

Summary

For cloud database services, agent-based DAM is not possible. So native logging makes sense in this context. Otherwise, the decision to use native logging in lieu of an agent needs to be considered carefully. There are both security and performance considerations. Security is diminished with native logging. For example, SoD cannot be established. This makes it harder to adhere to zero-trust security. Additionally, the DAM solution would not be able to do any enforcement of any kind whether on the database access side or on the database response side. Besides the reduction in security, database performance would also be affected. The degree to which performance would be affected would vary depending on the native database audit configuration. OLTP workloads are the ones that are most affected with native logging.






#Guardium
#Highlights
#Highlights-home
0 comments
423 views

Permalink