Plumbing the Depths
DBProtector's policies, or rules, are defined as enabling and disabling. By default, all activity is blocked, then allowed through the creation of enabling policies. Crossroads recommends that enabling policies be a bit broad and disabling policies be more specific; however, for highly sensitive environments, we recommend that enabling policies be as precise as possible. Care must be taken, though, that too much administrative overhead isn't created from overly complex policies. Think about those who come after you: The more intricate a policy, the harder it is to decipher it, especially, if you aren't the one who developed it.
NEWS | REVIEWS | BLOGS | FORUMS TUTORIALS | STRATEGY | MORE
At first, we thought that the metrics for building policies were limited, but as we continued to work with the interface and build a variety of rules, it became apparent that this was not the case. Policies are created through a context-sensitive wizard that shows only those metrics that are relevant based on whether the policy is affecting database objects, database responses, applications used, time of day, SQL impact (access, modify, execute), and rows returned.
DBProtector fared as well—or as poorly, depending on whether you're a "glass half full" kind of person—as the other products in our review when confronted with our attacks. It was able to spot large numbers of customer records being returned through our e-commerce application but couldn't detect theft when we lifted one record at a time. When deployed inline, it blocked the attacks it detected and alerted when placed out-of-band.
Crossroads' interface development team has done an impressive job in making DBProtector extremely user friendly. Organizations looking for database extrusion prevention should keep DBProtector on their short lists.
