|
Today’s ace attackers are gunning for fortune, not fame, and they know that the big score lies at the end of an SQL query. Got protection?
By John H Sawyer
When a Web server attack exposed Second Life customer data last September, Linden Lab invalidated all user passwords and announced that one lowly SQL injection flaw had enabled attackers to run arbitrary SQL commands on a back-end database. The company admitted that 650,000 names, along with contact information, encrypted passwords, and payment data had been compromised.
|
Fast forward to May, when University of Missouri employees probably wished they were in some alternate universe. IT staff noticed abnormal application behavior on May 3, and the next day discovered a mother lode of errors. One vulnerability was in a Web page used to check the status of help desk issues, and by exploiting an SQL injection flaw, an attacker was able to retrieve names and social security numbers the old-fashioned way—one record at a time, using tens of thousands of Web requests.
By the time IT realized what was happening, sensitive data on 22,396 people was long gone.
Your Money And Your Data
It’s no coincidence that over the past year an increasing number of security breaches have been the result of database compromises rather than pilfered laptops. Steal a PC from a car and you might get nothing but some hardware and an MP3 collection. Infiltrate a database of customer information and the possibilities are endless. And this trend will only continue as more companies deploy data-rich online services needing database back ends.
In the case of Second Life, attackers mined personal information on thousands of users who might have ended up being the focus of highly targeted phishing scams. For the University of Missouri, affected employees must worry about identity theft because of one insecure Web application and an old database still left in service.
Sure, it would be ideal if secure programming techniques were always followed when developing Web applications. But let’s face it, basing your data security strategy on developers producing bulletproof apps is like going to a shootout with one round in your magazine.
A better idea? If Linden Lab and UM had database extrusion prevention systems (DBEP) deployed at the time of the compromises, these breaches could have been prevented. The DBEP offerings we reviewed can keep abnormally large numbers of records from being returned, as in the Linden Lab compromise, and block the SQL injection attacks seen in the UM hack.
In the arsenal of IT defenses, DBEP systems have a slight advantage over standard data leakage protection products that sit at the network perimeter or run as endpoint agents in that they can be placed directly in front of your databases. They see traffic before an attacker can obfuscate, transform or encrypt data to evade detection. With data leak prevention, an attacker can avoid discovery if he gains a level of control over the data before it’s shuttled through the network.
Enterprises worried about exposure through attacks against Web servers with database back ends, the database servers themselves, or via misuse by authorized users, have protection options—we were generally pleased with the products we reviewed, with only a couple of exceptions. These products aren’t one-size-fits-all, but any of the five could have prevented a good number of the breaches that are currently making news.
Wild Cards
We put five DBEP systems to the test at our University of Florida Real-World Labs. Crossroads Systems, Guardium, Imperva and RippleTech sent us appliances, while Pyn Logic submitted software. We also invited Application Security, IPLocks, Symantec, Tizor Systems and Transparency Software. Symantec declined. Application Security and Transparency Software didn’t have their latest revisions ready within our testing window. The others never responded.
When we started testing we weren’t entirely sure what to expect, but we knew exactly what we were looking for: ease of installation and configuration, a breadth of database support, good visibility into database activity, detection and notification or blocking of attacks, helpful features, and a reasonable price.
To be effective, DBEP systems must provide visibility into database activity, whether it occurs on the network between the database and application servers, or locally on the database server. Rules can then be created to monitor for activities that indicate possible misuse or attack. After an activity is detected, it can be allowed, blocked, or recorded, or an alert can be sent out.
Up to this point, all the products we tested worked pretty much the same. It’s the extras that separated the leaders from the rest.
We found it interesting that the top two vendors in our review, Guardium and Imperva, approach the problem of database extrusion differently. Imperva focuses heavily on network security, with features like a stateful firewall, intrusion prevention system signatures, and vulnerability scanning of the database server. Guardium, in contrast, concentrates more heavily on reporting. We found at least a dozen different ways to take data gathered during monitoring and turn it into automated audit statements and security assessments that report on the security of a database server based on generated alerts, not by testing the server directly.
Baselining database activity and creating related policies are a key differentiator for the appliances from Crossroads, Guardium and Imperva. Each could monitor database activity and determine a base policy to fit the usage profile. Imperva stood out for its dynamic profiling which monitored activity, created usage profiles, and then let those profiles dynamically update themselves by defining safe margins and hard limits. For any enterprise with large-scale database deployments, this is a welcome feature that will spare DBEP administrators from constantly having to update policies as user roles change over time.
Management was performed through a Web browser for all the products tested, except for Crossroads DBProtector, which features a Java-based interface. We saw few usability issues in the Web interfaces, though it became obvious after testing with both Mozilla Firefox on Linux and Internet Explorer on Windows that they were built with IE in mind. Crossroads’ Java interface is both pleasing to the eye and easy to navigate. For the Web-based offerings, Guardium’s and Imperva’s GUIs are well done, with Guardium’s being slightly more polished.
Editor’s Choice
Right from the start, Imperva SecureSphere Database Security Gateway impressed us with its abundance of features. Deployment options include both in-line and out-of-band monitoring via a switch’s network monitoring port or network tap, with both options allowing blocking either by dropping traffic entirely when in-line or sending TCP reset packets when out-of-band. Only one other entry, Guardium SQL Guard, has the same blocking capability.
Unique to Imperva SecureSphere was the ability to scan the database server for vulnerabilities and act as an intrusion-prevention system. The gateway scans the database software and underlying operating system to find known vulnerabilities and weak security configurations that could allow the server to be compromised. Additionally, when deployed in-line, it can act as a stateful firewall and IPS with more than 2,500 signatures to prevent attacks such as protocol violations, SQL injection, and known worm activity. SecureSphere cost $45,000 as tested, and is our Editor’s Choice.
|