I hope this post helps shed a little more “technical light” on the encryption vs. masking discussion. Feel free to reach out to me with questions or other views!
We do a good job of giving a simple, down and dirty explanation regarding the differences between data masking and encryption on our site, and we also put together a great tutorial on the differences. Our company president also weighed in on Adrian Lane of Securosis’ blog post that discusses data masking and encryption, but I wanted to take a moment to add more color to all three and go a little deeper on the subject. This will be helpful for those who are evaluating solutions and need a “checklist” so to say.
1.- Encryption is great for securing data that needs to be returned to its original value at some point – e.g. during transmission, sitting in a production database, etc.
2.- Encryption is not a suitable replacement for masking when data would not need to be returned to the original value – e.g. development, unit & QA testing, etc.
3.- Encryption secures the data, but only while the encryption keys are safe. If the encryption key is discovered, it can unlock everything. With most data masking strategies, there is no “master key”. Certainly not with DMsuie’s algorithms, which is why our platform is iron clad when it comes to ensuring non-production data is truly safe and never compromised, no matter what happens to it.
4.- Encryption poses technical issues if it is being used to secure production data in non-production environments. For example, a small name like John would be a very long string of characters when encrypted. This means that database tables might not be able to store the entire encrypted string (usually there is a specified “width” of the column, and that may not be large enough to hold the encrypted string). Same goes for applications using that data, UI designs might not be able to accomodate strings that large.
5.- If encryption is used to secure a database or specific tables, generally, the application using that data needs to decrypt it before showing it on the screen. This means that although the data is protected from users hitting the database to browse the tables, sensitive information would still be available in the application using that database. This is obviously desired for production scenarios, however, in development/QA this is a security risk.
6.- Data masking with DMsuite solves the technical/risk issues associated with data in non-production environments and non-production activities by permanently changing the dev data in a consistent, repeatable fashion using the original data as an input to the algorithms – so you end up with data that is productoin quality, but without the production risk.
I have also been asked about Format-Preserving Encryption (FPE). The obvious point for FPE, is that it is encryption still and although the obfuscated value retains the same formatting, it is essentially just a jumbled number/string with the same formatting as the original data. This would work for number-based data, like SSN and credit card numbers, but when you take a first and last name and turn it into a jumbled string that is not realistic, you actually make it harder for dev/QA folks to do testing since the data no longer looks real. Dates would also be a tricky area with FPE. Essentially, FPE is a point-solution, but does not provide the breadth/depth that data masking with DMsuite does.