Data breaches are a regular occurrence. Most people had their emails or phone numbers stolen. That should be a shocking reality, but the scale of the problem and the frequent breaches have normalized it into something everyone accepts and mostly ignores.

Data theft remains one of the most persistent and damaging problems in information security. Organizations store vast amounts of sensitive information, and the volume continues to grow. The potential for a catastrophic data breach has never been higher.

There are significant financial incentives to both internal and external threat actors, and the results speak for themselves. Cybercrime is projected to cost the world $23 trillion by 2027, and the average cost of a data breach in 2024 was almost $5 million. Those are staggering figures and, somehow, everyone thinks it won’t happen to them. Yet it happens to someone all the time. Not a week goes by without a new scandalous breach.

As insurmountable as this problem seems to be, it really isn’t. You just need a different approach. The most effective and often overlooked solution lies in protecting the data itself. That means securing the databases that hold it. If you protect the data, then a hacker penetrating the corporate network or an internal employee violating your trust won’t trigger a data breach. Perimeter security keeps people out while database security controls what they do once they’re inside.

This article explains how to build this type of security.

Compliance

Data theft is not just about money. It’s about people’s privacy, personal data, identity theft, and more. These violations harm individuals, erode customer trust, and cause reputational damage.

It’s a massive problem for most companies and the many individuals who work with them. As a result, governments and regulators step in. That means we now have one more thing pressuring us to protect information – regulatory compliance. It’s no longer only a matter of protecting our businesses and doing the right thing – it’s the law.

Privacy

Privacy regulations have many facets. Aside from restrictions on how companies can use our personal data, a core aspect of privacy laws is to mitigate the risk of data theft. The European Union’s GDPR (General Data Protection Regulation) is probably the most well-known privacy regulation. However, in recent years, most countries and states have enacted privacy protection laws.

While each law regulates different entities and sets distinct restrictions, when it comes to data security, the objectives are almost identical.

Financial Data, Medical Records, Corporate Data, and Beyond

Data theft is a risk to many categories of information. There’s a lot of data we expect to remain confidential, and we rely on it being so. Laws and regulations in most countries already cover personal data, such as financial information, medical records, and credit card numbers. When it comes to corporate data and intellectual property, those are critical to the business, and companies are already incentivized to protect those.

If unauthorized individuals or the general public gained access to any of these oceans of data, there would be significant harm to the person or company whose data was disclosed.

Hackers also evolve, discovering more creative ways to exploit our dependency on information. Ransomware is the latest ploy to extort payment by denying us access to our data. To pile on the pressure to pay the ransom, hackers use double extortion: they also steal the data and threaten to expose it. So, ransom ware and data theft are tightly linked.

Few people in the world today need convincing of the plague that is data theft and the urgent need to stop it. The question, then, isn’t whether to act – it’s how to build a robust defense that will protect the data.

Databases: The Most Effective and Challenging Security Frontier

Perimeter security aims to prevent malicious actors from getting into the corporate network, while database security controls data access and the information going out. Databases are, therefore, the perfect place to identify data theft. There is no other layer in the technology stack capable of easily and precisely identifying what information goes out and how much of it.

However, this comes with a significant challenge: ALL the information goes through the database. It is not just sensitive information, and it is for every possible purpose. That means billions of queries and massive volumes of information feeding every data consumer anywhere in your company.

That presents a dual challenge: capturing all that activity without impacting performance, and identifying malicious activity in this ocean of queries. If we can do this effectively, we will secure our data. That is the golden key to data security.

Technologies

Before going into implementation details, let’s look a little at the technologies required to protect the database. These technologies divide into two main categories: capture and processing.

Capture

Capturing activity means generating an audit stream that includes all the activity. Essentially, to “see” everything that happens in the database. This is especially challenging for data theft since the bulk of the database activity is queries – the SQLs that extract data, and there are billions of those. The challenge with so many SQLs is that capturing them can impact database performance. A partial solution to that is to capture a small subset of those SQLs, which leads to insufficient visibility. One more visibility challenge is activity inside the database server and internal activity in the database.

There are three primary capture technologies in the database security market:

• Native auditing leverages built-in database capabilities. Solutions that rely on it are cheaper, but have limited visibility and a high performance impact on the database.
• Network capture solutions can see everything with minimal overhead. They require an agent to capture local activity and cannot capture internal database activity. They may also have a problem with encrypted connections.
• Full Capture is a technology that connects directly into the database engine. It can see everything with negligible performance impact. It’s the best of both worlds, giving you superior visibility at less than 3% overhead.

	Native Auditing	Network Capture	Full Capture
Performance Overload	Poor	High network impact	Less than 3% CPU Low network impact
Visibility	Limited due to performance overhead	Remote and local activity	Complete visibility (remote, local, encrypted, internal)
Price	Low	High	Medium

Processing

Once you have an audit stream, you need to do something with it. You need to somehow gain security value. Remember, we’re talking about billions of SQLs. The solution is divide and conquer: use different approaches for different subsets of the activity stream.

Different solutions in the market offer varying capabilities, but a comprehensive solution should offer a combination of methods whose combined capabilities address all the database activity.

Processing approaches fall into 4 main categories. We will first explain what they are and later explain how to combine them to build a proper defense.

• Policies, Reports, Alerts. These features allow you to record particular subsets of the activity, generate reports, and send alerts. This type of auditing is called declarative auditing: you instruct the solution what activity to record and what to include in the reports and alerts. These measures excel at controlling activities that are high-risk and low-volume, like those of administrators.
• Anomaly Analysis. These types of features analyze the activity profile to find unusual behavior. They can handle any activity volume and aim to single out suspicious activity within the stream. Anomalies can be a new SQL, a new user, a different machine, an unusual time, higher activity volume, and more. It is about finding a needle in the haystack and works especially well for repetitive activity. The application activity profile is repetitive, and anomalies can identify attacks targeting application vulnerabilities, such as SQL injections.
• Proactive Forensic. These features aim to give security personnel visibility into what’s happening in the database. It lets you investigate 100% of past database activity to understand the behavior of individuals, programs, and more. This visibility can serve as an independent control or as a means of planning other controls and identifying gaps in them.
• Advanced Blocking. These features are designed to prevent undesirable activity. They extend built-in database security measures by scrutinizing every SQL in every connection. While prevention is a powerful tool, use it with care. It can block legitimate activity, causing service interruptions and user complaints.

With Core Audit, all these capabilities are built into the solution, empowering you to do more with an easy-to-use interface.

Designing Security

Activity control is the most effective security measure in databases. Some might say that is the only effective security. However, designing a security plan for activity control isn’t trivial. You cannot push a button, and everything is secured. This section gives initial guidance on the steps involved in building an activity control plan.

Step 1: Visibility

It may seem like an obvious step, but it’s one most people neglect. You must gain visibility into the database activity profile. You need to know who’s accessing your database, from where, when, and what they are doing inside. Understanding the activity profile you aim to secure is essential to protecting it. You cannot secure what you cannot see and do not understand.

In solutions like Core Audit, this is part of Proactive Forensics. Proactive Forensics is a collection of graphical visualization and analysis tools that help you understand activity sources and what they do, the volume of activity over time, and the relationship between multiple dimensions.

Step 2: Accounts Classification & Risks

There are many paths to designing an activity control plan. You can design controls for each risk, subdivide the activity by different dimensions, and more. We found that the easiest approach is based on accounts.

Accounts in the database typically fall into categories like DBAs, the Application, Analysts, etc. The activity profile of each account type tends to have unique characteristics and a distinct list of risks. Using those characteristics, we can design a targeted plan for each account type. We’ll walk through it later, but we first need to classify the accounts and identify the risks.

Here are the steps:

• Group Accounts based on type. For example: DBA, Application, Local connection, Analysts.
• Consider unusual activity paths such as local connections and new accounts.
• Determine Risks for each account type. You should consider both how the intended user can abuse their privilege and how an external hacker can penetrate it. An external breach could be, for example, through credential theft. Accounts used by the application may also get exploited through a vulnerability, such as SQL injection.

For example, these are three standard account types that exist in every database:

• DBA. A category that includes individual DBA accounts and shared privileged accounts, like SYS, SYSTEM, or SA. This category is subject to risks such as Abuse of Privileges, Credential Thefts, and Compromised Desktops.
• Application. An account type that includes one or more application accounts. It is subject to risks like Abuse of Privileges (e.g., by an application administrator), Credential Theft, and Vulnerabilities (e.g., SQL injection).
• Local Connection. In most databases, there is at least one operating system account that can connect to the database without a password. Therefore, breaching the server’s operating system account gives the attacker access to the database. The risks include Abuse of Privilege and a Breached OS account.

After identifying our account groups and their risks, let’s start setting up controls for each.

Step 3: Session Controls

Session controls provide protection based on the connection information. For example, the account, the connecting program, and the source IP address. These are the simplest controls you can deploy, and they are easy to understand.

Session controls are like judging a book by its cover. It’s the more simplistic outlook that can provide a lot of insight, but it’s nothing like looking inside. It’s fast and easy to understand and may be sufficient for some attack vectors, but not all.

Session controls fall into the same 4 approaches mentioned earlier:

• Reports & Alerts: These are reports showing connections to the database. For example, who connected to DBA accounts, from where, and how many times. Alternatively, it can alert you when the Application account has a connection not from the application program or the application machine.
• Anomaly Analysis: An anomaly can alert you when connections come from unusual sources. For example, when a DBA connects from an unusual program or IP address. You can also send an alert when a new account connects to the database, a new program, a different combination of program and IP, etc.
• Proactive Forensics: Just as you gained visibility into the database activity in Step 1, you can choose to use this method as an ongoing control. By periodically evaluating who’s connecting and where from, you can detect suspicious behavior and identify gaps in your existing controls.
• Preventive: You can block activity from connections that do not conform to particular requirements. For example, you can allow activity on the application account only when it originates from the application server and the application machine.

Session controls often target specific account groups, like DBAs or the application. However, they can also be global, like alerting to new accounts or performing a proactive forensic investigation.

Session controls are mostly effective against various forms of credential theft since exploiting stolen credentials usually means connecting from a different machine or program. However, they are completely ineffective against abuse of privilege or application vulnerabilities since that type of activity originates from valid sources.

Step 4: SQL Controls

SQL controls or Activity controls provide protection based on the activity inside the connection. For example, the name of a table inside the SQL or the SQL command (e.g., Create, Alter, Drop, Insert, Update, Delete, Select).

Activity controls are more complicated and require some understanding of database activity. It’s valuable to not only understand what you’re looking at, but also how an adversary might attempt to achieve their goals. In other words, know how people work in a database environment.

SQL controls are effective against almost any risk – it’s just a matter of figuring out what to look for.

It is the opposite of judging a book by its cover. It is like opening the book and looking deep inside it. There is a lot of information and a lot to see. Actually, there’s too much information, and it’s highly unlikely you’ll be able to inspect everything yourself. However, if you know what you’re looking for, you can find it based on the characteristics it may present.

SQL controls fall into the same 4 approaches:

• Reports & Alerts: These are reports showing particular activity, such as a DDL report for validating change control. Alternatively, it can alert you when the DBA touches a sensitive table.
• Anomaly Analysis: An anomaly can alert you when there’s a change in the database activity profile. For example, when the application has a new SQL construct that is a potential SQL injection. You can also alert if a sensitive table is accessed by an unusual account, or when activity occurs at an unusual time of day.
• Proactive Forensics: Gaining visibility into the database activity can be a powerful ongoing control. By periodically evaluating who’s accessing sensitive data, how much data is accessed, and when, you can detect suspicious behavior and identify gaps in your existing controls.
• Preventive: You can block activity that does not conform to your expectations. For example, you can block DBAs from accessing sensitive data. You can also implement separation of duties by requiring DBAs to obtain amnesty codes before performing restricted activity.

Most SQL controls are specific to particular account types (e.g., DBAs or Applications), but in some cases, they can be used globally, like in a DDL report.

These controls are highly effective against most risks. They work for high-risk activities such as DBAs, and for high-volume activities like the application that involves billions of SQLs. This is an irreplaceable control to secure activity when the activity source seems legitimate (e.g., an abuse of privilege or an application vulnerability), and it works just as well for activity that is likely to have a different source (e.g., credential theft).

Data Theft Recommended Controls

Every organization should design controls specific to its environment. However, many organizations wind up with a few common controls. So, let’s review these and explain why they work:

• DBA account usage (session report) or DBA session anomaly. This report summarizes connections to DBA and privileged accounts. Alternatively, you can choose to have it as an anomaly alert that only highlights when there are changes in the activity sources. This is an important control against DBA credential theft as it highlights when DBA connections originate from unusual sources or are otherwise suspicious.
• DBA sensitive data access. This report lists DBA SQL activity that accesses the data schema or sensitive data tables. DBA accounts don’t usually access sensitive data. It is a strong control because if DBA connections don’t access sensitive data, then they have not been used for data theft. It is powerful against DBA abuse of privilege as well as various DBA impersonations (including credential theft).
• Application session anomaly. This alert informs you when the application activity comes from a machine that is not the application server or from a program that is not the application account. That is a vital control for combating application credential theft and abuse of the application account. In both cases, connections originate from programs other than the application software.
• Application SQL anomaly. That is a critical control against SQL injection and many other types of application vulnerabilities. Application activity is always repetitive, even for applications that generate dynamic SQL. This alert will inform you when the application activity profile changes.
• DDL report. DDLs are changes to the database metadata. While they are not data theft in and of themselves, DDLs can be used to compromise security. DCL is a subcategory of DDLs that manages users and permissions, and other DDLs manage tables, procedures, triggers, and more. A DDL report is a fundamental control to closing the loop and complementing that change control process.
• New User Anomaly and New Program Anomaly. These are alerts of new activity sources. These are important in controlling the attack surface and keeping you aware of fundamental changes in the database activity profile that will require you to adjust your controls. For example, if a new user is connecting to the database, that is something you need to know about. You probably also need to adjust one of the controls to monitor this new user.
• Scatter plot or Rows to SQLs Ratio Anomaly. These practices essentially inspect the average number of rows per SQL. Data theft exhibits large extractions that significantly raise this ratio. Looking at scatter plots or ratio analysis quickly highlights potential extractions. For example, if a certain combination of user, program, and IP has a much higher row-to-SQL ratio or that ratio changed drastically, it probably means that this connection was used to dump a table.

There are many more controls you can deploy, but these provide good and broad coverage for most databases against most threats.

Control Review

Here is the mapping from the threats to the controls we recommended. We just looked back at the threats we discovered in Step 2 (and added a few more):

• DBA risks:
  • Abuse of Privilege. The DBA sensitive data access report will reveal any malicious access by DBAs. The DDL report is also instrumental in ensuring all changes are approved by the change control process and that DBAs are not abusing DDLs to gain access. To achieve tighter control, you can also deploy preventive measures that, for example, prevent DBA access to sensitive data and a Separation of duties.
  • Credential Theft. A DBA session anomaly will alert you when DBA credentials are used from an unusual machine or program. The DBA sensitive data access report will also inform you if the account is used for malicious activity. Tighter preventive controls, like blocking access or separation of duties, are also effective.
  • Compromised Desktop. A compromised DBA desktop looks identical from the database perspective to an abuse of privilege and benefits from the same controls.
• Application risks:
  • Abuse of Privilege. An application abuse of privilege will be caught by the Application session anomaly alert, as such abuse will originate from a different program and likely also from a different machine. If the application account is regularly used by administrators, the Application SQL anomaly will alert to unusual behavior. However, if administrators regularly use this account, it’s advisable to also deploy the DBA measures on those particular sessions.
  • Credential Theft. An application credential theft will manifest in a similar way to abuse of privilege and can be detected by the same measures.
  • Vulnerability (e.g., SQL injection). An application vulnerability will be caught by the Application SQL anomaly. That anomaly will detect any change in the application activity profile, and an exploited vulnerability will, inevitably, change the application activity profile. For tighter controls, you can also perform forensic investigations or set up anomalies on activity volumes. You can monitor the number of SQLs or the number of rows processed.
• Local Connection risks:
  • Abuse of Privilege. On local connections, this is an abuse by DBAs, and it will be identified in the same way as other DBA abuses of privileges..
  • Breached OS account. In most databases, local OS accounts are in regular but infrequent use by DBAs. You could set up a Login Alert if the account is rarely used. Since this account is usually used to execute the same SQLs, an Anomaly SQL Alert would be effective. And in all cases, DBA controls, like the Sensitive data access report, would catch the attack.

To be effective, you’ll need to tune the controls to your environment. For example, if a privileged account like ‘SA’ is used by the application, the controls should distinguish between DBA access and application access (usually based on the program or the machine). It is highly recommended that applications use a dedicated account with minimal privileges. However, that type of change may be difficult and time-consuming to implement. Another tuning example is that DDL reports often need to exclude temporary tables or similar common activities you might have in your environment.

You may notice that the control recommendations included a New User Anomaly and a Scatter Plot that were not mapped to risks. The New User Anomaly maps to the risk of a new account in the database. Part of that risk is of a DBA who creates a new account to steal data. However, the majority of the risk is neglecting to adjust the security controls when there’s a new user. The Scatter Plot control is more global and aims to identify large data extractions from the database regardless of any particular risk.

	DBA			Application			Local
	Abuse of Privilege	Credential Theft	Compromised Desktop	Abuse of Privilege	Credential Theft	Vulnerability	Abuse of Privilege	OS Account
DBA account usage DBA session anomaly		X
DBA sensitive data access	X	X	X				X	X
App session anomaly				X	X
App SQL anomaly				X	X	X
DDL report	part.	part.	part.	part.	part.	part.	part.	part.
New User Anomaly New Program Anomaly	part.	part.	part.	part.	part.	part.	part.	part.
Scatter plot Rows/SQL Ratio Anomaly	X	X	X	X	X		X	X

Final Thoughts

There are two things you need to acknowledge: First, protecting the database is important. Second, it is possible. This article aims to demonstrate these facts.

In the past, database security technologies were far less effective. Our inability to defend them shifted the security mindset from focusing on the obvious to the tools that were available and delivered value.

Database security technology has changed dramatically over the past 25 years. Modern technologies are far more effective in both capturing and analyzing the data. At the same time, attackers found new and effective ways to penetrate the perimeter, limiting the effectiveness of those defenses. The ineffective perimeter further accentuates the inescapable need to secure the database.

Detecting and preventing data theft at the database level is not only possible – it’s a crucial step in security. While it requires a little work and know-how, modern technologies make it the most effective measure to identify an attack and respond to it.

Follow the attack vectors that lead attackers to the data. Effective control over the activity that leads to the data means you can detect, prevent, and respond to a breach if and when it occurs. Once you address these different threats, you will successfully combat the risk of data theft.

The database is the single point that controls all data accesses. There is no other point like that. There is no alternative to advanced database security solutions. The database is the last and most powerful line of defence in the battle against the scourge of data theft.

As we move forward into the future using the cloud and remote employees, the perimeter will completely disintegrate. Controlling the data is the only path forward.

Ready to move beyond perimeter security and build a proper defense for your data? Contact us to learn how to build robust database security with Core Audit.