In the first three parts of this series, we established a strict data-centric methodology that builds security from the inside out. We started with the database where the data lives, and inside the database we focused on the critical sensitive data assets.

However, once an attacker is already accessing your sensitive data, you have no buffer room left. You must quickly detect, evaluate, and stop the exfiltration. It is hard to tell how long you have until the attacker gets the SQL right and aligns their tools, but you should assume you have little time left.

When we follow the data-centric path, the next logical step is to build another fence a little further out. Relying exclusively on a single fence at the edge of the cliff is a dangerous game.

This brings us to the next step of the inside-out defence: Securing Activity Profiles.

This defence is not a substitute for the inner fence around sensitive data. While it aims to be tight and comprehensive, it also acts as an early-warning system. Before an adversary touches a sensitive asset, they almost always exhibit anomalous behavior.

We can build an additional defensive ring inside the database by categorizing distinct personas and identifying unusual behaviors an attacker cannot avoid.

Activity Profiles

Database activity is not composed of a random blob of queries. It has goals and follows certain predictable rules. The ecosystem has fundamentally different types of actors that use different tools to accomplish entirely different objectives.

If you attempt to apply a single policy across your entire database, you will fail. What is abnormal behavior for one actor is normal for another. Finding things that no one should do is nearly impossible and offers no meaningful defense.

To build effective security, you must divide and conquer. You categorize activity sources into distinct Activity Profiles based on their operational reality.

Three pillars define an activity profile:

• Who is connecting (the database user).
• How they are connecting (e.g., the client application).
• What type of activity they execute, focusing on core behaviors that an attack must deviate from (e.g., administration, repeatable SQLs, low row counts, or target objects).

By establishing these profiles, you stop treating every database connection as a generic activity source. Instead, you create distinct, highly tailored rulesets for each user class. A malicious actor, whether internal or external, must stray from the account’s profile to execute an attack. When they do, you catch them along the approach path – before they try to extract data and breach the inner data fence.

Who is the Threat

Before dissecting individual profiles, we must consider who we defend against. At the database level, different threats and attack vectors can appear the same. Enumerating the threats helps ensure we address them all.

When a connection arrives at the database listener, the engine only knows what the connection string tells it. It cannot tell whether the person at the keyboard is the authorized account owner or an adversary impersonating them. It cannot know their intentions or whether it is even a real person.

Practically speaking, all database accounts face three basic threat vectors:

Threat	Source	Who
Credential Theft	External	An Attacker using a valid user and password
Close Impersonation	External	An attacker takes over an employee desktop, an application server, or a database session.
Abuse of Privilege	Internal	The legitimate authorized user with malicious intent

1. Credential Theft: An adversary acquires a valid username and password (from a file where it was saved, via a keylogger, etc.) and establishes a direct, rogue connection to the database. Credential theft attacks often originate from a different IP address and may also use a different client program than the real user.
2. Close Impersonation: An adversary compromises an authorized user’s workstation, an application server, or takes over an active user session. These connections are indistinguishable from the original user and may have been initiated by the actual user.
3. Abuse of Privilege: A legitimate, trusted user (a disgruntled DBA, a rogue developer, or a desperate application administrator) intentionally uses their authorized access to commit malicious acts. These are the authorized users who know how to successfully connect to the database, are allowed to do so, and do it regularly.

The takeaway is that connections that look perfectly valid can still be used for malicious activity. Even if we implicitly trust the legitimate users, those legitimate-looking connections may still be an attacker perfectly imitating them.

In other words, it doesn’t matter whether a connection looks valid. What matters is the activity. Malicious intent, regardless of who performs it, invokes malicious actions. These actions are the clues we must identify.

The question “How do we verify if this is actually Bob or an attacker using Bob’s password?” is irrelevant. The answer is simple: You don’t care. You do not need to solve the identity attribution problem to stop an attack. You simply need to detect the execution deviation.

Whether you trust your DBAs or your application developers is irrelevant. You must monitor everything blindly, because you can never guarantee who is on the other end of the wire.

Profiles Breakdown

To build effective activity profiles, you must identify the fundamental operational “weakness” of each user class. Every profile has something inherent in it that eliminates it as an attacker. Something essential for an attack, and that must be violated to carry out a malicious intent.

Profile	Activity Profile	Key “Weakness”
DBAs & Privileged accounts	Many DDLs, manual hand-crafted SQL, scripts, and specialized tools.	No legitimate business justification to access data.
Applications	Billions of SQLs accessing every piece of data. Querying and modifying sensitive data.	Highly repeatable SQL patterns when eliminating literals.
Analysts & Others	Manual hand-crafted SQL, scripts, and specialized tools.	Require schema access. Usually, they don’t need to modify data, access PII, or extract a high volume of rows.

DBA & Operations Profiles

On the surface, DBA accounts seem like a security nightmare. They have unlimited access, often with direct server access. They are database experts with intimate knowledge of the configuration and operational reality. They use specialized tools, execute a chaotic mix of hand-crafted SQL, create custom scripts, and automate maintenance procedures. Their regular tasks include inspecting internal database metrics, making configuration changes, changing objects in the data schema, modifying users, and granting permissions.

The Weakness: While DBAs maintain the infrastructure, they rarely need to read or write data from the sensitive schema.

A database administrator may need to change the credit cards table by adding columns or indexes, but does not need to query the actual credit card numbers inside it.

The Strategy:

• Data Fence: Alert or block any query or DML targeting the data schema or sensitive tables. DBAs do not need to access data, but native database controls cannot enforce that. Isolating DBAs from the data eliminates the vast majority of DBA account exploitation by any means (insider or external).
• Session Traps: Monitor applications and source IPs. While DBAs use varied tools, they generally connect from designated machines and administrative networks. An anomaly can easily identify when the activity source changes. This is a valuable control against administrator credential theft, which serves as an earlier warning signal.
• DDL Monitoring: DDLs are administrative database commands used to manage configuration, users, permissions, objects, and more. Best practices are to use them strictly under change control procedures. Monitoring DDL executions is good practice and helps ensure all are tied to approved tickets.
• Local Activity: DBAs often use local connections within the database server (e.g., to start up or shut down the database). While these connections are required for administrative purposes, they are used only for limited and highly specific tasks. Alerting on different usage is critical because local compromise is a significant attack vector exploited in all double-extortion ransomware attacks.

Restricting or controlling DBA accounts is not as difficult as it is portrayed. However, databases don’t have built-in mechanisms to limit DBAs, and achieving this control requires Database Activity Control solutions.

Application Profiles

Applications represent over 95% of total database activity. They flood the engine with billions of SQL executions automatically generated by application code to satisfy end-user requests. Human review at this scale is impossible.

The Weakness: Applications are inherently deterministic. Users click buttons, and code paths execute pre-defined SQL templates. Even highly dynamic applications that generate SQL constructs based on user input eventually exhaust their unique query shapes.

While the literals change constantly (e.g., WHERE id = 623 vs WHERE id = 9981), the underlying SQL construct remains fixed. Usually, over a 90-day reference window, nearly 100% of application query patterns repeat.

The Strategy:

• SQL Construct Anomalies: Since SQL constructs inevitably repeat, alerting on a deviation highlights application misbehavior. For example, any SQL injection attack will create a SQL construct the application does not natively generate. This is an early warning sign, as the first injected SQL is unlikely to be the one exfiltrating data.
• Errors: When attackers try to make the application misbehave (e.g., cause a SQL injection), they go through many failed attempts that trigger errors. Monitoring errors gives an even earlier warning sign of an application vulnerability.
• Volume Anomalies: Some attack vectors aim to exploit the SQL queries the application normally issues, only at much higher volume. For example, a BOLA attack scans through all possible identifiers and extracts information for each one. Monitoring query volume is a good indicator of this type of application misbehavior.
• Session Control: Application service accounts only connect from known programs on known application servers. Alerting or blocking an application account connecting from a different activity source is an easy control against credential theft and abuse.

Controlling application activity is entirely possible. Contrary to common beliefs, Database Activity Control solutions offer highly effective controls that detect most, if not all, breaches.

Analyst & Ad-Hoc Profiles

Analysts, BI tools, and reporting users are the ultimate challenge. They access sensitive data tables, write ad-hoc SQLs by hand, and execute unpredictable joins.

The Weakness: Analysts require schema visibility to perform business intelligence, but they rarely require direct access to actual identifying PII. For example, they don’t need to view Social Security numbers or credit card details. When they require PII access, it is never in high volumes (e.g., to extract thousands of identities). They often perform the analysis inside the database and don’t extract much data. Finally, they don’t require administrative access or write access to the database, and you can restrict that using built-in database controls.

The Strategy:

• Least Privilege: Eliminate all administrative and write access privileges. Additionally, use database permissions to revoke access to unnecessary sensitive tables and columns.
• Masking: If partial PII access is required, you can use static data masking to create a desensitized table, use dynamic masking to modify data on the fly, or use a database view to apply simple database functions that restrict visibility.
• Data Volume: When analysts perform analysis inside the database, set low-threshold alerts or blocking limits on row counts and data extraction volume. If they extract data, ensure those limits prevent PII extraction.
• Identifier/Data Decoupling: Use the previous methods under Masking to decouple identifiers from data. For example, you can allow them to see the salaries and the names but not the name that matches each salary. Alternatively, prevent joins between the data and PII, forcing PII access to be separate and limited in volume.

You can mostly achieve these restrictions through built-in database mechanisms. However, some mechanisms such as volume control and join prevention require more advanced Database Activity Control solutions.

Proactive Forensics

You cannot build accurate activity profiles based on assumptions. We tried it many times, and it never works.

When faced with the list of programs that connect to the database and the list of IPs, DBAs often fail to account for all the programs or who uses those IPs. It is not unheard of to perform forensic investigations to explain how certain activities occurred.

Guessing user behavior guarantees two outcomes: massive security blind spots where you failed to predict reality, or an avalanche of false-positive alerts that forces teams to turn off certain controls. Sadly, it is usually both.

Proper security starts with Proactive Forensics. That is the capability to retroactively inspect, query, and analyze 100% of the activity occurring in your database across extended timeframes. Thereby transforming security from an exercise in guesswork into an empirical science.

Before you write a single rule or fire a single alert, proactive forensics lets you test your security hypotheses against historical reality:

• Hypothesis: “Our DBAs never SELECT data from the sensitive schema.”
  Test: Query 90 days of DBA activity filtered for DML and SELECT statements targeting sensitive tables. You may discover, for example, that DBAs occasionally dump data tables for certain users or fix corrupted data values.
• Hypothesis: “The main application account only uses two programs and always connects from the primary app-server pool.”
  Test: Look at the account’s activity source over the past quarter. You may uncover, for example, that developers regularly use this account.
• Hypothesis: “Only authorized maintenance scripts run DDL statements.”
  Test: Run a forensic search for all DDL executions, and review the list of users and programs that executed them. You may discover, for example, that the application also executes certain DDLs.

Testing these assumptions invariably exposes operational drift, forgotten legacy jobs, unauthorized shadow processes, and poor security practices. Aligning controls with reality before enforcing policies is what separates an effective security program from a noisy, unmanageable one.

The Implementation Steps

Putting together all the concepts discussed so far reveals a structured implementation roadmap. While there is some art to it, you should approach the design and execution of profile-based security as an organized engineering process.

1. Profiling with Proactive Forensics

Use forensic data to map every active account:

• Activity Source: Connecting applications and source IP addresses/subnets.
• Activity Types: For example, DDLs, DMLs, or Queries.
• Time & Volume: Activity time, SQL execution volume, and the number of rows.
• Objects: Sensitive tables, views, and procedures along with row counts.
• External vs. Internal: Activity over the wire vs. internal activity from procedures.

Sometimes, you need to break down activity profiles by user and program rather than just username. For example, when both DBAs and automated scripts use privileged accounts.

In some cases, it is better to go backward and map the accounts that perform the activity. For example, which accounts, programs, and IPs execute DDLs and which access sensitive data.

2. Establish Initial Profile Hypotheses

Group your inventory into the core activity profiles like DBAs, Applications, and Analysts. For each profile, define the fundamental operational boundaries and “weaknesses” you intend to enforce:

• DBAs: Restrict to administrative actions and prevent access to sensitive data schemas.
• Applications: Bind to fixed application programs and servers and detect deviation from SQL construct patterns.
• Analysts: Revoke admin/write privileges, restrict access to sensitive tables and columns, control extraction caps, and mask or decouple data from identifiers.

3. Validate Against Historical Baseline

Test your proposed rules against 30 to 90 days of recent activity. Identify instances where a rule would have triggered and determine:

• True positives: How many alerts indicate a legitimate threat, require operational remediation, or otherwise benefit from security personnel awareness?
• False positives: How many are false positives?
• Review load: Is the alert volume burdensome or acceptable? A reasonable quantity of alerts is healthy. It is the hallmark of sensitive and tight security.
• Required tuning: Should you tune the alerts, for example, by filtering out certain activities?
• Coherent profiles: Should you adjust the profile boundaries? It may be necessary if conflating different profiles causes too many alerts.
• Value: Is this a valuable and effective alert that will highlight a potential security event, or should you re-evaluate the weakness profile?

4. Enforce & Alert

Transition your policies into active detection or prevention. Because you pre-validated your theories, the alert volume should be predictable and align with your expectations.

Remember, you are not aiming for zero false positives. No false positives invariably mean you have many false negatives and your security is ineffective. The objective is a healthy and manageable level of alerts. Enough to ensure security personnel are aware of operational reality and keep a watchful eye over it.

5. Periodic Audit & Maturity Scaling

Database activity profiles are not static. Applications change, new users join, and old ones depart, DBAs update their tooling and scripts, and business units onboard new BI platforms. Everything changes, and your security must evolve as well.

Perform a proactive forensic audit at least once or twice a year. Use it to re-validate your profiles and your approach to securing them. Consider:

• Activity: Newly created accounts, shifting IP pools, or changing SQL patterns.
• Controls: Effectiveness of existing measures. Is it time to retire some alerts, and should you introduce new ones?
• Coverage & Gaps: Do your current controls cover all the activity? Are the controls tight, or are there holes that could allow a potential breach?
• Attack Vectors: Do the controls mitigate the attack vectors you’re worried about, and can they mitigate risks you’re aware of?
• Historical Performance: How did the controls perform in the preceding period? Did they surface any real security issues? Are you aware of undetected issues? Do they generate too many alerts or consume too much time from personnel?
• Maturity: As your visibility improves and you gain experience with the controls, use these periodic reviews to tighten things further. Attempt to address profiles or vectors you previously considered too complex.

From Theory to Practice

Most database security products are sold as a collection of features. A toolbox full of tools vendors drop in your lap, expecting you to turn them into a functional security program. The burden of figuring out how to protect your data is delegated to you. This article series offers a logical, structured methodology for converting a collection of such tools into a solid defense.

With Core Audit, Blue Core Research offers not just a collection of features but a way to combine them into a hardened strategic implementation. The activity profiling we outlined isn’t a theoretical exercise—it is how you can use Core Audit to protect your data.

However, instead of glossing over parts of the implementation requirements that Core Audit handles implicitly, let’s explore a little deeper into what it takes to convert this theory into practice.

Uncircumventable Control

One of the pillars in this guide is securing DBA accounts. When securing privileged accounts, you defend against actors who know the database engine better than anyone else. They installed it, configured it, and are managing it every day. Trying to monitor or restrict a DBA using light-touch, easily bypassed auditing mechanisms or network proxies is like trying to stop a bullet with a wet paper towel.

To effectively control DBAs or attackers operating with administrative privileges, Core Audit enforces complete, uncircumventable visibility and control directly at the core of the database engine:

• Total Activity Source Capture: It captures 100% of activity, including local connections inside the database server, encrypted traffic, dynamic SQL, and internal database activity executed within stored procedures and triggers.
• Non-Bypassable Enforcement: When a policy dictates that a DBA account cannot execute a particular SQL statement, Core Audit blocks it at the engine level. It offers no blind spots, workarounds, local connection backdoors, or encrypted bypasses an insider or an attacker could exploit.

The Security Repository

The engine that drives Proactive Forensics and Anomaly Analysis is Core Audit’s proprietary Security Repository. You can only investigate activity profiles across months when you have the data. It is trivial when you have the right tool and impossible without.

Core Audit has two repositories, both hyper-optimized. The security repository is responsible for automatic long-term capture. It records everything that happened in the database regardless of policies. It compresses all the database activity down to usually less than 100 MB per month per instance. About a gigabyte of disk space per year.

A footprint of this magnitude completely changes the math on database security:

• Infinite Lookback: You are not limited to a 30- or 90-day retention window. You can keep years of full forensic history online and instantly searchable without impacting storage budgets or performance.
• Flexible Anomaly Reference Windows: While a 30- to 90-day reference window is typically enough to eliminate false positives for application SQL constructs, you have the freedom to expand your baseline history as far back as your operational reality requires. You can also use different reference windows for different anomalies as appropriate.

One of the “tricks” the Security Repository uses is automatic literal stripping. It counts how many times unique SQL constructs execute rather than treating them as unrelated SQLs. That is how we can store forensic information about billions of SQL executions in a small amount of disk space.

Literal stripping also allows the anomaly engine to track these executions over time. When an application account suddenly issues a SQL it has never generated before – such as an injected SQL fragment – the anomaly engine flags the deviation and alerts you of a precursor attack before exfiltration occurs.

Tailored Capabilities for Your
Operational Reality

Security is not a one-size-fits-all conveyor belt. The tools and controls you deploy depend entirely on your team, your environment, and your operational reality:

• Declarative Rules vs. Anomaly Detection: Some environments thrive on explicit, declarative rules (e.g., binding service accounts to specific IPs). Others rely heavily on automated anomaly detection. Effective security programs tend to use a pragmatic mix of both.
• Forensics as a Core Control: Proactive forensics is an ongoing security control, not just a setup phase. It empowers human operators to inspect actual operational behavior. Reactive forensics allows for immediate deep-dive investigations when security events occur.
• Self-Paced Progression: Mastering database security takes time, and every organization takes a different maturity path. Core Audit provides the full spectrum of capabilities from day one, allowing you to build confidence at your own pace. You start with visibility, add some declarative and anomaly reports and alerts, and gradually expand your policies as you gain control over your environment. Active blocking is almost always a later component in that journey.

The point is that while you don’t use everything on day one, every customer uses different capabilities in distinct ways and evolves along an individual path. It is like getting a full palette of colors and painting a unique picture. To succeed, you need access to all the capabilities.

Final Thoughts

Securing databases isn’t about identifying the few connections that could cause a breach, nor is it about blindly trusting authenticated credentials. It is about classifying the activity systematically, recognizing that every actor operates within a distinct operational reality and holding them to it.

By breaking your database traffic into tailored Activity Profiles, you stop playing catch-up with generic signatures. You force attackers, rogue insiders, and compromised credentials to reveal themselves along the approach path, giving your security team the critical lead time they need to respond before attackers compromise the sensitive data.

Protecting databases is not impossible. It is not even that difficult. It just takes a practical methodology and some effort. Start with visibility, investigate each profile, and tune the alerts. You will build a resilient detection perimeter around your database.

Try Core Audit today and join us in the next part of this series, where we will take the logical next step in the maturity process: Active Blocking. We will examine how to transition from detection to prevention, which paths are safer, and how to reduce the risk to your data without breaking production or compromising operational reality.