In the recent months I've done a lot of research around database security, talking with vendors like Oracle, IBM (Guardium), Sentrigo (now McAfee), Imperva, Bitkoo, and some others as well as with several end user organizations who either are using database security products or evaluating those technologies.

When looking at the market it is very important to understand that it is not a homogeneous market. The different solutions range from firewalls to specific tools for label security or data masking. Some are tightly integrated with databases, others are non-intrusive. I will provide a broad overview in an upcoming research note which covers the entire database security market and the vendors therein.

But before selecting the right vendor and the right tool for your database environment, you should ask and answer another question: How does this fit into your overall IT security strategy and implementation? I'm not a friend of point solutions in security. Solving one problem without looking at all the other problems doesn't necessarily increase the overall level of security achieved. It might give a better feeling, but frequently there is still too much attack surface left.

Just think about securing your databases with a firewall. Some of the attack surfaces left are:

  • Security issues in the applications which access data in the databases
  • Administrative actions
  • All actions performed locally at the database server
  • Copying or deleting the database with administrative access at the operating system level
  • ...
And that's just a short and incomplete list. From a strategic perspective, you have to look at how to secure the stack. Recently I've been at a customer who discussed about where to best start securing his apps. As a quick start, I proposed to him to build a simple spreadsheet with his (defined) 30 most critical apps and the stack these apps are using - including operating system, application platforms, hypervisors, and for sure the databases. That simple spreadsheet will give him an impression of the dependencies he has to keep in mind - it visualizes that security isn't about point solutions.

I don't say you should not invest in database security - but that should be one element of security. Thus, database security has to be put into context.

One interesting aspect within that are database firewalls. There are some firewalls out there, inspecting packets for SQL traffic based on policies. However, when inspecting packets - why not for everything? CIFS/SMB traffic to file servers? Web service security? That would allow to apply a consistent set of policies wherever it is appropriate. It would provide a consistent layer of security. For sure that won't solve all problems, but the advantage in contrast to having a "DB firewall", a "Sharepoint firewall", a "CIFS/SMB firewall", and so on is obvious. Another example is around privileged user (account, identity, access) management, e.g PxM. That is important for database management systems, but it is important for other types of systems (apps, operating system, hypervisors, network appliances,...) as well. I'd opt for a solution which covers all.

For sure there are as well many database specific aspects of security, like data masking and others. And given that there isn't the "multi-purpose firewall" or other solutions which cover everything out there, it is about using several solutions. There is also some good reason for specialized tools - easier to implement, easier to manage, more specific features. However, they should be used as part of an overall strategy, not as isolated point solutions. Customers have to look at it from that perspective - and vendors should move forward to provide more integrated solutions over time.

Good security is achieved by strategy, not by tactics.

EIC 2011: Munich, May 10th to 13th - the place to be for IAM, GRC, Cloud Security, Database Security, and more...