Last week I had an interesting briefing with IBM regarding their Guardium acquisition. With that acquisition of a company specialized on database security, IBM becomes the second large vendor investing in that area, following Oracle who has Database Security products in its portfolio for some years now. The IBM/Guardium deal fits pretty well in the current time, when looking at the increasing problem of information theft. Besides IBM and Guardium there are some smaller vendors in that market which I will cover in another post near-time.
IBM Guardium, in contrast to the Oracle approach, is not tied to a specific database management system but works as an external solution. There are obviously pros and cons for both approaches. Performance, administration, flexibility regarding the defined policies and other aspects differ significantly. Thus, before choosing solutions, a detailed analysis of these approaches should be performed (and KuppingerCole will provide a market overview for database security around April which might be a good starting point for such an analysis).
The entry of IBM in that market shows an increasing maturity and relevance of this particular IT market segment. And it raises the question of which role database security can play within IT security. From my perspective, it is an interesting area which is mandatory to protect sensitive information. Information in databases is at risk, and cases like BKK or the stolen data from Swiss banks offered to the German government prove that. However, this is just one element within an IT security strategy focusing on authorized access to data. Securing the database with the wrong policies or with giving away privileged accounts to untrustworthy parties won't help much. Thus, database security projects never ever should be driven by the database guys but must be understood as an element within IT security blueprints. Only a consistent approach to security will really reduce the security risks and thus the related operational risks.
Even more I think that database security always will be somewhat limited in its scope. Once data is outside the database, it doesn't protect the data anymore. On the long run we might have to fundamentally rethink the concepts of today's databases and make them "security-aware". What do I mean by that? Data within databases should be inherently protected. Think about applying concepts we find today in Information Rights Management (IRM) at the document-level at a much more granular level to data within databases, ensuring that any record (or part of a record) can only be accessed according to defined policies. Such an approach would have massive impact on the existing technology. How to index? How to deal with encrypted information? How to define these policies? However, if you look at database security from a very fundamental point-of-view, it becomes obvious that applying database security to existing databases won't fully solve the problem because it is only about "data at rest".
Nevertheless I think that any organization has to think about implementing database security in the meantime, until we have better solutions sometimes in the far future - I'd expect fundamental changes to database technology to take at least 10-15 years to become ready for mass adoption. It might take even a little longer. To cite John Maynard Keynes, the famous economist who focused on theories with a short-term view when being critized for not looking at long-term evolutions: "On the long term we are all dead". Given that, short-term we should evaluate and implement existing database security approaches, rethink the authentication and authorization approaches within databases (using the GRANT statement a little bit more detailed...) and integrate this with our overall IT security and governance approaches (and especially IAM). In the meantime, the vendors have to think about how to do the next fundamental step to make DBMS inherently security-aware.