How to Choose Your Dynamic Data Masking (DDM) Solution
I invented DDM 8 years ago as a feature to my database technology. Since then, I have implemented DDM in dozens of the global banks, insurance and healthcare organizations. I get many inquiries on this subject on a weekly basis – and hence this blog. Today there are three approaches for DDM: SQL proxy, http proxy, and application agent. Each one has its own different capabilities aiming at different use cases.
SQL proxy approach: Putting a proxy between applications and databases adds a single point of failure – hence, this approach is not appropriate for applications, but for protecting SQL development tools (such as Toad and SQL Plus). Another limitation to note is SQL proxy is blind to stored procedure requests, types of proprietary database network encryption, and when applications use cache. As it sits on the connection pool, ensure you can get the user context. Implementation requires meticulous collection of every table, view, and snapshot that contains sensitive data. You also need to restrict DML with these objects, as the DDM proxy can be easily fooled by creating a view on a sensitive object and then querying the new object.
I once was asked by a Swiss CISO – how can I prove to the Swiss authorities that your SQL parser is bullet proof? I still don’t know what I should have said.
HTTP proxy approach: Great for demos, but not for you. It does not protect client-server SQL tools, and with applications it does not provide you with the required robustness to support all types of client protocols and variants as well as ensure that masked data does not land back and corrupt your database.
Application agent: All the limitations of both the HTTP and the database proxy approaches are solved – no single point of failure, no parsing limitations, no caching blindness, rich user context, scalable and has out-of-the-box support to any type of data source – both relational and no-SQL databases, EAI interfaces such as Tibco (used by many of the global banks), files and big data stores. It also allows much needed implementation flexibility – applying DDM on SQL and/or DDM on result set.