Walking the tightrope between data security and the desire for maximum performance is a high-wire act well known to organizations that rely on the critical information contained within their databases. Their search for the right mix now prompts them to find the best way to identify users tapping into sensitive databases, while minimizing any impact on performance.
Anonymity—there are times when it is not only desirable but vital.
Whistleblowers often need anonymity when they are working to expose nefarious and potentially dangerous activities.
Undercover agents, maybe working for the Drug Enforcement Administration, must operate under an assumed identity if they are to perform their work effectively and thwart the machinations of a drug smuggling operation.
Clearly, there are times when anonymity fits the situation like a tailored suit fits an investment banker.
But there are also times when clear and accurate identification is demanded by the circumstance at hand.
Drivers that Create the Need to Know
There are multiple reasons why managers inside of an organization need to have a handle on the identities of individuals who have access to business critical information. Ranking high among the most important of those reasons are the requirements of some very high profile compliance standards.
The Payment Card Industry Data Security Standard (PCI DSS), Sarbanes-Oxley, the Health Insurance Portability and Accountability Act (HIPAA) and other regulations have a lot to say about the need for granular IDs on those with access to sensitive information.
For example, an important requirement of PCI DSS is that all users are identified with a unique user ID name before they can gain access to systems components or cardholder data and that user identity must be verified before performing any password resets.
Particularly crucial is the requirement to authenticate all access to any database containing cardholder data, including access by applications, administrators and all other users.
HIPAA regulations also require unique user identification (either through the assignment of a unique name and/or number as a way of tracking user identity).
The intent is that each user has a unique login account.
So that electronic audit logs that identify patient health information (PHI) can be linked to a single user as an aid in identifying individuals who are trying to access PHI or have already done so without having the authority that would give them legitimate access.
On another front, a large number of organizations have adopted the Control Objectives for Information and related Technology (COBIT) as a framework to help with Sarbanes-Oxley compliance. COBIT calls for users with access to be uniquely identifiable.
The Concept of Competing Priorities
Considering the demands of these standards, any prudent security policy should incorporate user identification as a must have item.
The problem is, many database environments make use of technology that greatly complicates the process of user identification.
The reason for this level of complication is straightforward and relatively simple; the applications found in these environments are coded with ease of use and performance as major considerations and with security as either a secondary concern or a non issue.
It’s not because the writers of these applications don’t care about security, it just that they have other things to consider.
Along that line, it’s instructive to look at the evolution of approaches to accessing the database.
For example, in three-tier application environments, three application users will be accessing the database. One approach to creating this kind of an application environment works in the following way: for every connection opened by a user, a corresponding connection is opened to the DBMS.
This approach creates a lot of overhead contained within the process of initiating and disconnecting sessions. Beyond that, most users are inactive for large periods of time, resulting in established connections that are inactive but still consume resources from the DBMS, the application and the network.
A way of dealing with these inefficiencies has been adopted by many application writers and it creates a single connection between the application and the database. All transactions are sent within this single session with the result being that time and resources are not consumed in the near perpetual creation of new sessions between the application server and the database.
This architectural approach uses pooled connections and creates a much more efficient method for accessing the database, resulting in minimal performance overhead. In most circumstances, the application authenticates itself with a single user (or a limited number of users) known as the application user.
No Free Lunch
But when looking at things from a security perspective, it becomes apparent that the security measures designed to protect an application, also result in making that that application more complex.
In many cases, the opposite is also true, i.e. simplifying an application to improve performance and reduce overhead, often produces the unintended consequence of reduced security and, for the purposes of this discussion, the loss of user accountability.
In a pooled connection environment, when monitoring or auditing of the database is undertaken, transactions are identified only by a single user, meaning that crucial information such as the original user name, the client name, host name and the original IP address, are not available.
From a security perspective, a scenario might play out in the following way: Let’s say someone ran a query that returned all of the customer account data stored in a CRM database. At the time the query was run, only the application was connected to the database but there were 350 active application users. The resulting problem is that there is no way to know who originated the transaction. What’s more, if the data is sold to a third party, there’s no way of identifying the individual responsible.
Regardless of the details of a circumstance, without granular user identity information, a post-breach or post-event forensic audit won’t yield the kind of actionable information that is needed.
It’s this reality that partly explains the growth in popularity of database activity monitoring as a way of determining what is happening and what has happened in a database environment.
Who’s Been Accessing my Database?
When it comes to determining user identity, there are a number of approaches to dealing with the issue.
An application re-write preserves the option of using connection pooling because the identity of the user is added to the transaction, making it possible to identify whoever might be accessing the database.
The downside to this approach is that it can be costly and is sometimes impossible to pull off.
Another method is to correlate between database logs and application logs, which does not require any change in the application but does not scale to large numbers of transactions and is suspect when it comes to accuracy.
A third approach makes use of an application plug-in which adds a filter to the application that gathers the user name, IP address, and host name for every new remote user within the connection pool. This approach requires no changes to the application and delivers full user accountability but requires some configuration file changes. Regardless of the details, the bottom line doesn’t change: knowing the identities of those tapping into your databases is a crucial element to your overall security health.