Integrate Your Ticketing System into Database Security to Prevent DBA Privilege Abuse

Many of the recent high-profile data security breaches were made by trusted insiders. They are often database administrators (DBAs) who are highly privileged and trusted insiders with access to sensitive data.
In this blog post, I will discuss the inherent risk introduced by highly privileged administrators who are required to support production databases, the challenge of ensuring they are not abusing their privileges, and then, how you can integrate your ticketing system with your database compliance and security solution to mitigate the risk.

The risk of highly-privileged database users

Database administrators are sometimes required to connect to a production database to conduct maintenance tasks or diagnose and fix a problem. These tasks often require high-level privileges. With these ultimate privileges, it means database administrators can do whatever they want.
Any DBA can drop, create, backup, recover, truncate, and obviously query any table. At first look, querying any table is the least dangerous task from the list. On the other hand, if someone is trying to export and sell the content of the credit cards’ table, that’s exactly the privilege they will need.
Malicious DBAs (insiders) are just one face of the risk. Careless DBAs might expose their DB credentials. Alternatively, their DB credentials may be compromised by an email phishing campaign (outsiders).

The “need-to-know” approach

In theory, you would like to grant each user the minimal permissions that they need for the task. In practice, it’s virtually impossible to achieve this since most administrative tasks require high-level privileges. In some cases, these privileges are hierarchic and contain other privileges the administrator should not have. In addition, the administrator’s permission needs keep changing based on their current task.
An example to demonstrate the risk of reading the SQL Server audit file using the sys.fn_get_audit_file stored function, requires the CONTROL SERVER permission. This permission also allows the administrator to query any table on any database of that server. Querying any table might enable exporting all personally identifiable information from your most sensitive tables.

The “trust, but verify” approach

The alternative to a strict permissions model is to audit all activities, let administrators know their actions are audited, and finally, review and investigate any suspicious activity.
Let’s assume the first two parts are easy. But, how would you review all activities? And what the hell is a suspicious activity, when you do not know what the administrator was supposed to do?
Trust is easy. However, if the verify part is too tedious, you and your database security personnel in general, will not do it properly. What you’re probably looking for is a set of tools and procedures that will simplify the verify part.

Managing production maintenance tasks and supporting cases using a ticketing system

Now let’s say you use a ticketing system. Each maintenance task or production issue has a ticket. It describes the symptoms to investigate, or the required action. Someone assigns each ticket to a DBA, who will in turn connect to the database and handle the ticket.
In a well-managed system, no highly privileged user will connect to a production database without having a ticket assigned to them.
In a perfect world, the highly privileged user will act according to the ticket’s description. That’s exactly what you need to verify.

The missing link

When database support is managed through a ticketing system, you can tell which task should be done and by whom. Still, the ticketing system will not validate that DBAs do not abuse their privileges.

The missing building block is a tool that matches what the privileged users actually did, with the support tasks that should have been done. Such an automated process will filter out all legitimate actions, which leaves you to deal with suspicious activity only.
Naturally, a database security solution that audits all activity, also has the potential to help you validate that privileged users don’t abuse their privileges and alerts you when they do.

Integrating a ticketing system into DB audit and security

Let’s take a closer look at how ticketing systems and database security solutions should cooperate to automate alerting for abuse of high privileges. Such DB audit solution integrations should have:

• Easy one-time set up
• Continuous notifications on any new ticket
• Highly privileged users, who can easily tell the database their assigned ticket ID. This is crucial: It must be as easy as executing a single SQL statement in the current connection.
• A unique ticket ID for a specific DB connection that is associated with all activity performed in the same DB connection
• Validation that the ticket ID is both valid and assigned to the connected DB user
• Alerts issued when a highly privileged user connects, executes privileged actions, or queries sensitive tables with no valid ticket assigned
• Validation of the actual activity by reporting all audited events that belong to each ticket ID

SecureSphere DAM provides all the above and more

SecureSphere allows you to integrate a ticketing system into your database security policies. Its highly-customizable audit and security policies let you define which DB users must have a valid ticket ID, what actions should trigger alerts when no valid ticket is assigned, and much more.
Find out more about how it works with “Integrate Imperva SecureSphere with BMC Remedy.” I’ll discuss the technical details of how to set up SecureSphere for integration with a ticketing system in my next post.