All attacks have the same destination: the data in your database. However, 99% of database activity originates from a single application service account. So, how does database activity control compare to application activity control?

Data-centric security controls the activity that touches the data. This defense is deployed from the inside out, like putting together a matryoshka doll or adding onion layers. The starting point is the data, which means the database. It also makes sense since, regardless of its path, an attack will always end in the database with a compromised credential, abuse of privilege, a SQL injection, etc.

However, there’s a visibility gap. Despite seeing all the activity, the database doesn’t have the full context for most of it. To the database, the majority of the activity originates from one monolithic entity, the application, which encapsulates the hundreds or thousands of individual human users. Not only that, but the database is also unaware of what the end user did to trigger the data access. It only knows that someone did something that triggered a query.

So, while the database can see everything, the application adds another layer of visibility that is invaluable. Let’s compare Database Activity Control (DAC) and Application Activity Control (AAC) – two independent silos, each valuable in its own right. More powerful together, but how do they differ, and what defenses do they offer?

To compare DAC and AAC effectively, we’ll examine modern 3rd-gen capture methods that are the cutting edge of this technology. They use light-weight agents with extreme visibility and off-server processing capabilities.

A Question of Language & Risk

Databases talk in the language of data: tables and columns. By thinking in terms of data access, you can gain comprehensive protection for all your data. Applications talk the language of the business with end-users and URL pages, but they also speak the language of data with every SQL the application executes. Applications connect real people doing business transactions to the database language of data.

Operating at the application layer, you gain the advantage of using business terms, but you lose the ability to protect outside of the application. Going down to the database layer is the opposite – you gain control over all data access paths, but lose the application context.

If your security thinks in terms of data, database defense is the obvious choice. It is a comprehensive approach with a powerful, well-rounded defense. Your data exposure will be limited to a few application attacks that may not be detected at the database level, like scraping data through BOLA (Broken Object Level Authorization). However, that exposure is probably much smaller than the exposure of not having a database activity control (DAC). Only DAC can cover critical attack vectors such as abused or compromised DBA accounts, local connections inside the server, and more.

However, if your security requires the language of the business, you have a difficult choice between coverage and depth. AAC will deliver the capabilities you desire, but your data will be exposed to critical attack vectors that bypass the application. AAC can be your initial defense only if all your data accesses are through the application and you believe you have sufficient measures to secure the non-application data paths.

The question of language can be one of personnel and skills rather than what drives the results you need. If you have DBAs in your security team, you may favor database security, and a more application-conscious security team will opt to secure them. However, resources are also a matter of management choices: for database security, you’ll work with the DBA team, and for application security, with the application team.

Therefore, if you want to decide which is most vital for you, your first step is to decide what’s more important: the resources you have or your risk profile. If it’s your risk, you must then choose between more “tricky to capture” application vulnerabilities like BOLA and XSS, and direct database threats like DBA accounts and local database access.

The Database Perspective: The Ultimate Truth

Database Activity Control is the ultimate “Ground Truth”. It operates at the end of the execution chain, capturing the raw SQL hitting the engine. If there’s data access, you will always see it here, and there’s no place to hide.

The Full Visibility Advantage

Database activity control provides a 360-degree view of all accesses that application security cannot compete with. It detects:

• Administrative Abuse: The DBA’s activity always bypasses the application, and they can use their access to modify or steal any data.
• DBA Credential Theft: When a DBA account is compromised, it’s just as bad as if the DBA decided to abuse their privileges.
• Direct OS Access: An attacker who gains shell access to the DB server and connects via a local connection (a pipe, shared memory, or a socket). It’s a common attack vector that happens in every double extortion ransomware attack.
• Internal Engine Logic: When an application calls a stored procedure or a trigger, the table access isn’t visible. It’s code running inside the database. Only modern DAC technology sees the underlying layers, including table accesses that occur inside the engine.

The Missing Context

The weakness of pure database activity control (DAC) is the lack of context. If an application account starts retrieving records, DAC knows what is happening, but not who triggered it or what they did. Without that context, legitimate data retrieval and malicious data exfiltration can look very similar.

Depending on the attack, a malicious and a valid access are not always identical. That’s why DAC can detect a significant number of application vulnerabilities. However, there are limits to how far DAC can see inside the application.

Let’s take a couple of examples:

In the case of SQL injection, the application sends an unusual SQL to the database. It is a SQL that the application never sends natively, and in a good database activity anomaly engine, it sticks out like a sore thumb.

However, in a BOLA attack, the application sends the same SQLs it normally does. The only difference is that it sends significantly more of them. That “extra volume” of a particular SQL can stick out in an anomaly analysis, but only if it’s an unusual spike. If the application routinely queries 5,000 – 10,000 of these views in an hour, and a BOLA scraping adds 2,000, the attack will likely go undetected. However, if the application normally has 100 of these queries, those extra 2,000 will raise an alarm.

The Application Perspective: Real Users and Actions

Application Activity Control (AAC) isn’t really about the bottom-line SQL, but about the perspective of the end-user. Who they are, where they connected from, what page they are on, etc. It also sees the SQL, but it bridges the gap between what an individual did and the underlying SQL sent to the database.

To clarify, we are not discussing a WAF, which is a surface control tool observing from the outside. The Application Activity Control we’re discussing monitors what happens inside the application, from a user accessing a URL all the way down to the SQL sent to the database.

The Context Advantage

By sitting inside the application runtime (like the JVM), AAC captures information that the database layer never sees:

• User Context: the user who logged into the application and the IP address they are coming from.
• Application Context: the specific application pages and other application-level lingo that allows security teams to speak the language of the business rather than the language of the database (tables and columns).
• Business Meaning: identify, for example, “Scraping” or “Crawling” patterns (BOLA / IDOR). A user viewing one profile is normal, while a user viewing 5,000 profiles a minute is a breach. Even if every individual SQL query is perfectly valid, the user behavior isn’t.

Is it RASP?

Application Activity Control (AAC) and RASP both operate on the application at runtime. However, AAC is designed specifically for monitoring with negligible impact and easy deployment, while RASP is designed for real-time protection, with all the benefits and risks that it entails.

Here are some key differences:

• Goals & Architecture: RASP aims to enhance application security by blocking suspicious activity from the inside. AAC primarily aims to collect and analyze application activity. As a result, RASP must compose a clear picture of the activity and analyze it inside the application in-line (as part of the transaction). AAC only captures raw events and asynchronously offloads the correlation and analysis to another machine. AAC can provide simple blocking in the application, but complex analyses are delivered only as alerts in near real time.
• Performance & Stability: AAC is significantly lighter and faster. RASP must execute significantly more code inside the app to achieve its protection goals. That heavy RASP code slows things down and adds risk, while in AAC, the complex heavy lifting is not even on the same machine as the application.
• Risk & Deployment: While possible, AAC deployments don’t tend to alter the application behavior, whereas in RASP, that’s the primary objective. A false-positive in AAC translates to a false alert, but in RASP, it means an interruption to production activity. AAC is also deployed at the infrastructure level (e.g., JVM arguments), requiring no changes to the application source code or build logic. It doesn’t even need access to the source and works equally well on off-the-shelf software.

AAC provides deep visibility without the downsides of using RASP. However, RASP is a real-time, in-app prevention technology that AAC doesn’t attempt to compete with.

The Common Ground

Both the database and the application can agree on one thing – the SQLs. It’s what the application is sending to the database and what the database receives from the application. If what you care about is which table was accessed, you can see it in either DAC or AAC.

To be accurate, in the database, you’ll see all the SQLs, not just those from the application. So if you care about what data was accessed, the database is the definite winner. You’ll get a wider and more complete picture than just the application (e.g., DBA activity) and see deeper into the internal activity of stored procedures.

However, if you only care about the application activity, AAC can deliver full application context, showing you the real end-user, the URL, and more. Actually, in AAC, the SQLs are not the primary focal point. Since you can analyze user behavior from the business perspective, the actual data access is often seen as a mere side effect of conducting a business transaction.

AAC Expansion – The Client-Side

Application Control can extend to control what happens inside the end-user web browser. By injecting a small piece of JavaScript into the HTML pages, advanced application activity control solutions can “see” what the users are doing.

Web client security offers visibility into end-user activity and portions of the application running on the endpoint. It also mitigates client-side attacks, like XSS. While valuable, it steers away from the database and its SQLs, so it is somewhat outside the scope of this paper. However, we’ll mention a few types of capabilities to help explain other advantages of using AAC:

• AJAX – By monitoring or blocking client app interactions with other servers, you can detect and block Cross-Site Scripting (XSS).
• User Data Exfiltration – By detecting or preventing end-user actions such as copy and print, you can mitigate data extractions.
• Clicks – modern applications use client-side code to interact with the user. In these apps, monitoring the user interaction with the app can deliver key visibility into user behavior.
• Screen saver – you can enable an application-built-in screen saver or page timeout, which is valuable when you have no control over the endpoints.

Client-side control is a powerful expansion of AAC, allowing it reach all the way into the endpoint. That is the third and outermost layer in data-centric security, outside the application server (middle layer) and the database (inner-most layer).

Anomaly Detection: The Power Defense

Setting up declarative defenses against specific violations is effective for some attack vectors. However, with billions of activities in both the database and application, you often need a more powerful tool at your disposal.

Anomalies will detect when something is “off”. They will alert you when the behavioral profile changes and you need to pay attention.

Here are some examples and what they look like in the database and the application later:

Anomaly Type	Database Perspective	Application Perspective
New SQL Construct	A possible SQL Injection from the app1 account on server1 (only identify the app account)	A possible SQL Injection from user John.Doe from IP 10.2.1.117 (identify the end-user)
Unusual Connection	DBA1 connected from a different IP address 10.6.2.61 (direct database users)	User John.Doe connected from a different IP address 10.7.2.35 (end-user app connections)
Unusual Activity	DBA2 is accessing a table they haven’t accessed before. (based on the data)	John.Doe is accessing a URL they haven’t accessed before. (based on the URL page)
BOLA / IDOR	This SQL was executed more than usual. (SQL & row execution count)	John.Doe accessed this URL more often than usual. (API access count for end-user)

The Hybrid Approach

A common industry trend is to add application context to database activity. While it’s a clever adaptation, it’s more of a stopgap solution compared to a real AAC. Let’s explain:

A proper Application Activity Control solution can see what happens anywhere in the application. All the way from the user accessing a page down to the SQL statements sent to the database. In the context of a hybrid approach, you can also think of AAC as adding the application SQLs into a complete view of the application. That is in contrast to the hybrid approach of adding minimal app context to the SQLs. In other words, AAC gives you a lot more than just context with the SQLs.

DAC delivers complete coverage, reaching beyond the application. That is its strength. If you need to control the application, AAC is a much better choice.

So, where does the hybrid approach come from? It’s from vendors that don’t have AAC and try to offer a solution to the visibility gap that customers have. It is a patch that works for some applications by enriching the database information with a little context.

However, if you find value in pulling application context into DAC, an AAC can easily help you perform that enrichment. It’s a minor subset of its capabilities.

Performance & Visibility: Monitoring at Scale

Historically, deep activity control was impossible due to its performance impact. “We can’t turn on auditing because the overhead will kill the database/application”. That was true in the era of 1st-gen native auditing. Later, in the era of 2nd-gen packet capture, the argument became “It’s impossible to get that kind of visibility.” However, it is possible, and modern 3rd-gen capture technologies eliminated the performance vs. visibility tradeoff by tapping into the SQL engine.

Non-Intrusive Database Capture

Modern DAC solutions no longer rely on heavy native audit logs or massive packet captures (1st and 2nd generations). Instead, they get the data they need directly from the SQL engine. By leveraging the processing already done by the database, this capture can extract only the required data with less than 3% overhead. You won’t feel a significant impact even in high-volume OLTP environments that process tens of thousands of transactions per second.

Full capture with negligible impact is the reason we chose 3rd-gen capture technology to drive Core Audit. But how does the “magic” work?

First, let’s explain the visibility. The SQL engine resides below the database network stack and is indifferent to the transport mechanism (encryption, local connection, remote connections). It can equally see both external and internal activity. If the database executes a SQL statement, it goes through the SQL engine. It means that seeing what happens here gives you visibility into all database activity.

The SQL engine is also where native auditing resides (1st-gen). So how come the 3rd-gen is so light while the 1st-gen is so heavy? The trick is in the extra processing. Built-in database auditing is slow because the database must do additional work. It needs to gather more information for the audit records and store them. It needs to look up the user, the program, the SQL, and more. It also needs to write to a file or, worse, to a database table. 3rd-gen tech extracts the raw information but does the rest of the work outside the database server.

By asynchronously offloading correlation, processing, storage, and other tasks to another machine, a 3rd-gen solution can avoid the “observer effect” that slows down the database, and deliver the “magic” of complete visibility without the performance overhead.

Runtime Application Monitoring

On the application side, modern application stacks offer unique capabilities designed to extract information with minimal impact. In Java environments, for example, a javaagent can be added to the JVM startup command line. It adds runtime hooks that collect raw event information with negligible impact. Just like DAC, the trick is to offload the heavy lifting of correlation, processing, and analysis to another server asynchronously.

Using capabilities built into the infrastructure means you don’t need to change the application code or even have access to it. The Java stack has specific features that allow data collection with negligible impact. Invisible to the human eye, while delivering complete visibility to security personnel.

Is It Worth It?

Deploying a database agent, a Java agent, or any installation on production servers involves operational risks. So, does the effort justify the value they deliver?

Let’s answer it from several perspectives:

1. It is the only way to gain the visibility you need to secure your systems. If you’re not running in the machine, you cannot see what happens inside it. Agentless is a buzzword that doesn’t work: either because you still need an agent or because you don’t get sufficient visibility. Without visibility, you cannot have effective controls and will end up with a partial solution.
2. It is much easier and safer than it seems. The trick to stable agents is predictability. Agents that have few execution paths are easier to test and ensure reliability and stability. It means that “good” agents are small, simple, and have minimal functionality, offloading all the complex work to another machine. They are measured in kilobytes, not megabytes.
3. The alternatives are worse. Whether you deploy a WAF, a 1st-gen native auditing solution, or a 2nd-gen packet sniffer, they are more complicated to install, configure, tune, and get operational. WAF, for example, requires extensive testing to ensure it’s not blocking legitimate activity. The local agents of packet sniffers involve kernel drivers and additional network cards that need to be installed on the database machine. 1st-gen native auditing require a lot of careful tuning to avoid killing performance.

Blind Spots

Before jumping into the verdict, let’s rehash some of the attack vectors mentioned:

Attack Vector	Visible to DAC?	Visible to AAC?
SQL Injection	Yes (Unusual SQL)	Yes (Unusual SQL)
BOLA / Scraping	Maybe (High SQL volume)	Yes (User behavior)
Credential Theft / Rogue DBA / Local Access	Yes (Data access)	No (Bypasses the App)
Stored Procedure Injection	Yes (Internal execution)	No (Only Sees the ‘Call’)
XSS	No (client side only)	Yes (Client side control)

Note that there are many other attack vectors. This list only aims to illustrate the type of attacks each technology is better suited to address.

The Verdict

We must first point out that this review compared cutting-edge Database and Application activity controls. Older solutions with more limited visibility or analysis will likely drive other conclusions.

Ultimately, database and application activity controls are complementary, and using both would be ideal. However, budgets, personnel, and time are all limited, and we often have to choose one to go first.

Our recommendation will depend on the type of database/app stack that you aim to secure:

• “Traditional stacks” are built on “all-in-one” architectures (monoliths) and feature-rich relational databases like Oracle or SQL Server.
• “Modern stacks” are built on modular architectures (microservices) and cloud-native or NoSQL databases. They favor APIs and distributed designs.

These two stack designs have distinct risk profiles and merit different approaches. There are, obviously, many things in the middle, and you should determine which risk and approach aligns better with your environment.

“Traditional” Stacks

In a traditional stack, start with the database.

The risk profile of a traditional stack contains database attack vectors that cannot be ignored. For example, a database server breach, credential theft, and abuse of privilege. Traditional applications are also light on APIs, and SQL injection is a more likely exposure than a BOLA. Additionally, the rich database opens the door to creative attacks exploiting procedures, anonymous blocks, and more.

So, in a traditional stack, go with the physics: The database is the only place where every attack path terminates:

1. Coverage. You can’t secure what you can’t see, and putting your thumb on the critical path of any breach is a primary priority you cannot ignore.
2. Risk: Database Activity Control (DAC) addresses, on average, more significant risks than AAC. These are attack vectors you shouldn’t ignore.
3. Compliance: Database control is a compliance must. Auditors care a lot more about who touched your PII than which URL was accessed.
4. The “Inside-Out” Rule: First, you lock the vault, and only after, close the window. Data-centric security builds defenses from the inside out. First, protect the database, then the application, and finally, the endpoint. Skipping inner defenses creates holes you cannot compensate for outside.

These four points represent different facets of the same reality, but they are all important perspectives.

“Modern” Stacks

In a modern stack, start with the application.

In these environments, the application essentially functions as a data access service (through an API). It is a data source that feeds users or other applications. While it doesn’t store the data, it is the main relay point. As a core data source, these apps deserve a database-level security priority.

Additionally, these stacks often leverage feature-lean databases. databases that are, many times, distributed (making them harder to control), and when in the cloud (i.e., DBaaS), you won’t have control anyway.

All these tilt the risk profile in favor of the application. Not only that, it leans into application attacks that are less likely to be detected at the database layer. The underlying database still sees all the data access, but the activity patterns become ‘too noisy’ to detect an application logic abuse. The same SQL from that same microservice is executed in many different and unrelated application execution paths.

Final Thoughts

We went into great detail about protecting the database or the application. And, as you know, you really need to protect both. So, regardless of your initial choice, start planning on how you’ll build your security moving forward. One piece now, another in six months, another next year. We’ll build this wall brick by brick. But if you don’t start building it, it won’t happen by itself.

The perimeter isn’t offering protection that justifies your investment in it. It’s just difficult to justify the value of a porous defense. So, start shifting focus to building this wall. It’s the only play, and you know you must make it.

Take action now, because the longer you wait, the more time you give attackers to breach your defenses. Pick the layer that represents your highest risk and protect it today.