Tech Insight: Database Activity Monitoring

It's mid-afternoon. Do you know who's accessing your databases?

Until recently, the answer for many organizations -- including the TJX Companies and Ameritrade -- the answer has been no. While all databases come with tools for security and access control, many users -- mostly employees or other insiders -- have found ways to circumvent them, leaving IT people in the dark about who's been using the data, and when.

The problem isn't just headline-grabbing external hacks, such as the one at TJX, but also insiders who, for one reason or another, find it inconvenient to follow security policy.

"It’s not that the users are malicious," says Phil Neray, vice president of marketing for Guardium, a maker of database security tools. "They’re doing it for the sake of convenience."

While some vendors offer broad data leak prevention solutions to the insider threat problem, many enterprises are taking a closer look at a more focused set of products built specifically for databases: database activity monitoring (DAM) tools. DAM products can help enterprises meet compliance requirements by verifying proper controls and auditing database access, in addition to detecting -- and sometimes preventing -- malicious attacks.

How can you find a DAM package that works for your organization? The best approach is to issue a request for information (RFI) from a range of vendors that offer such tools, giving you the means to examine the differences in the products and their various approaches.

When developing a DAM RFI, enterprises should focus on a few key features to help cut through the marketing fluff. The RFI should include as much information as possible about the production environment, reducing the number of responses from vendors who think they can solve the problem, when they really can’t.

The most basic part of the RFI should include the database servers currently in production, and any that might be used in the future. The major DAM vendors, such as Guardium, Imperva, and Application Security Inc. support Microsoft SQL Server, Oracle, and IBM DB2, but they generally don't cover open source database servers such as MySQL and Postgres. DAM products don't always support every protocol between database clients and servers, either, so be sure to include those in the RFI.

Besides the obvious database and protocol support, DAM solutions monitor database activity in different ways. Some can "listen" on the network, in the same way that intrusion detection systems do, and analyze the database traffic as it passes from the client (or even an application server) to the database server. This approach has some limitations: Activity on the database server itself doesn't pass through the network, and therefore wouldn't be detected by a network appliance.

In this scenario, a software agent must be installed on the database server to monitor local activity. The agent should have minimal impact on the server, and shouldn't rely on the database server’s native logging. A DAM solution isn’t complete unless it can monitor both local and network-based activity, so make sure the RFI includes both requirements, along with information on the operating systems the database servers are running.

Like other security products that send alerts based on attack signatures, DAM solutions provide the best value to security analysts when they provide both SQL request and response information when an suspected attack is detected. Having both sides of the conversation can provide the context needed to determine if the attack was successful or not.

However, enterprises should be aware that monitoring both sides of the conversation can tax a DAM system's performance, notes Mark Kraynak, senior director of strategic marketing at Imperva. "Knowing something is taken may not be as important as knowing what was taken," he says. "[But] recording both sides essentially doubles the work being done, so performance and throughput is crucial.”

Recording the responses may also pose a risk to data privacy, because sensitive information stored in the database could end up recorded by the DAM solution. If this might be a problem, confirm that the solution can mask or discard the responses to prevent unnecessary disclosure to security personnel who don’t need that information.

One of the most important features of a DAM product is its ability to tie the database activity to a specific user -- a crucial method for identifying the source of an attack. DAM solutions should be able to tie a user identity to database activity from end to end, whether the user is connecting to the database directly or passing through a Web or application server first. If a vendor claims to have this capability, make sure that it can identify users in all of your environments, not just for a select few commercial applications.

When putting together a RFI, make sure to ask all of the questions we've outlined here. What database servers and operating systems are supported? Does the product monitor from both the network and database server (and if so, how does local monitoring impact performance)? Does the product make the database responses available for review, and can it mask sensitive information to prevent accidental disclosure? And, how well can the DAM solution monitor user activity end to end, on both commercial and custom applications?

With solid answers to these questions, you should see significant differences between the DAM product offerings and be able to narrow down the list of vendors that offer a viable solution for your particular environment.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.