From

Thank you

Sorry

The scenario is simple: a user has rights to query the database’s customer table. He usually queries one customer at a time through the application interface, but one night, he stays late, dumps the entire customer table into a text file, and burns it onto a DVD.

This type of activity is called privilege abuse, and no database vendor has built-in protection against it. In fact, although network administrators have enjoyed firewalls for years, database admins have been left out in the cold -- until now, that is. Enter Imperva SecureSphere Database Security Gateway (DSG). Available as an appliance, SecureSphere DSG equips DBAs with the firewall functionality they need to protect databases from unwanted activity, malicious or otherwise.

SecureSphere DSG protects your systems from a wide variety of unwarranted activity by limiting the types of queries that can be run, the times they can be run, and the client programs that can run them.

At its core, though, SecureSphere’s firewall capabilities defend against privilege abuse, which comes from inside as well as outside the network in many forms, such as injection attacks. It manages this feat by learning your traffic patterns. After it defines typical activities, the DBA can basically go in and approve them (assuming they are, indeed, permitted activities).

When installing SecureSphere DSG, planning is key. This appliance has to be set in just the right spot on your network in order to capture the traffic coming into your servers. That said, it is fairly easy to install, and training the defense mechanism is just a matter of time. Management is done through a Web-based GUI that’s fairly easy to navigate.

Complex filtering

SecureSphere DSG can filter queries in three different modes: Learning, Static, and Dynamic. In Learning mode, it merely collects the queries being performed on your server and does nothing to stop them.

Static mode will stop queries that are not in your approved profile set and will not allow any new queries to run on the server.

Dynamic mode is similar to Static, but it allows certain types of new queries to run. This one is used in more dynamic environments where ad hoc querying is more common. Of course, you still don’t want someone to dump the entire customer or patient table; string substitution is a good way to prevent objectionable activity. SecureSphere DSG sniffs a query for a given string of text and replaces it with whatever you choose. The search conditions can get complicated, but you can have as many as you want, so the sky’s the limit here.

One app at a time

One of the more serious problems DBAs face is how to limit end-users to accessing the database only from the front-end application. It is becoming increasingly common for auditors to ask how users are being restricted from circumventing those apps and connecting with a query tool. SecureSphere DSG allows you to lock down which applications can connect to a given DB. Of course, you can assign roles defining which users can connect with which applications. DBAs could connect using any tool they like, whereas end-users can be restricted to certain applications.

You can also set SecureSphere to only allow certain queries, or to permit only specific users to perform work on the server during certain hours. This capability has endless applications for everything from preventing actual abuse to simple mistakes. Abuse is easy to understand, but what mistakes could be prevented? You could keep DBAs from accidentally running reindex statements; deleting or updating data without “where” clauses; altering tables; dropping database objects; and so on. Using this as a method of change control only makes you look that much better to the auditors, and it helps you tighten down your environment so when something happens, you can narrow down the possibilities very quickly.

You can set SecureSphere to perform various actions when a policy is violated. You might have it merely block the activity, which is really more of a passive way of dealing with the intrusion. Alternatively, you could take a more aggressive approach and block the user from further activity, send an e-mail, or block the IP of the connecting process (my personal favorite). The more proactive approaches let you investigate the suspicious activity on the spot by not allowing the user to perform any more work at all until you manually unblock him or her.

So-so reporting

Imperva’s reporting is useful, but it has notable limitations. There are some very helpful reports on the activity hitting your server; unfortunately though, they’re only viewable from the Web console and not easily exportable for archiving purposes, nor can they be e-mailed automatically. The company tells me that later this summer such a functionality will be added, but currently the reports’ usefulness in compliance audits remains more limited than it should be, requiring a lot of manual labor on the admin’s part.

SecureSphere does provide specific reports that will help you gather valuable information for compliance audits. HIPAA, CIP, and Sarbanes-Oxley are all covered. I did find, however, that going through some of the report screens is very slow at times, so looking for something specific on a busy server can take a while. There’s also no way to add your own reports.

The SecureSphere Database Security Gateway is a very important part of a complete database security model. It not only fills the security void left by vendors, it also provides the only means of preventing privilege abuse to date. You simply can’t find a better means of preventing unwanted queries from hitting your system. When it comes down to it, there is far too much functionality in this product to detail here. Still, you’ll realize its usefulness immediately.