Deterministic data masking

What is deterministic data masking?

Deterministic data masking is the process of replacing a value in a column with the same value whether in the same row, the same table, the same database/schema, and between instances/servers/database types.

Example: A database has multiple tables, each with a column that has first names.  With deterministic masking the first name will always be replaced with the same value – “Lynne” will always become “Denise” – wherever “Lynne” may be in the database.

What’s the benefit of deterministic masking?

In a nutshell, the benefit is the consistency of the masked output within and across masking projects regardless of the database or, indeed, the RDBMS platform.

Every downstream database user tends to have a favourite account he or she works with.  After a database refresh the masked data values would have historically been different between refreshes.  Now, it will be the same.

QA and Test teams want to have data consistency so that their manual or automated procedures can be reliably and consistently deployed.

No more translation tables needed

In previous versions of DATPROF Privacy it was possible to achieve Deterministic Masking with the use of Translation Tables. These tables are generated afresh during each masking run and subsequently used within the run as “lookup tables” for masking functions. This achieved a quasi-Deterministic Masking within the current masking project but the next time the project is run the results would be different (although consistently applied).

Implementing a practice where the Translation Tables are secured and re-used for lookup would achieve consistency between runs but requires actions to be specified in the event that a value to be masked does not have a corresponding value in the lookup table.

Translation Tables, by their nature, provide a way of reverse engineering the data masking process should they be exposed. By implication they needed to be held in a secure manner and transposed across instances / servers to achieve consistent masking across the Estate.

Our new Deterministic Masking feature removes all of these considerations.

How does it work?

In concept, the replacement of a data value with a generated alternative is determined by a user-specified “Salt” key. This is “combined” with the replacement datasets themselves to determine which row in the replacement dataset is chosen.

The choice of the replacement Properties…

…has a significant impact on the replacement candidate row selection.

Remember, you can select any combination of properties to achieve your masking objectives but to achieve consistently masked values you must ensure that the replacement property selection is consistent between tables and databases/schemas (projects).

There is also a concept of a Project Global Key which is the over-arching value in the replacement value selection algorithm.  This value Privacy generated value can be found in the Deployment tab under Settings:

The Global salt value is generated when the project is created or upgraded from a previous version of Privacy.  It is, however, fully editable so you can replace it with a Global key created in another project.

It follows, therefore, that using a deterministic technique will allow you to implement consistent data masking across your estate if you:

• Use the same Global salt key across all projects
• Use the same Deterministic salt value at the rule level and
• Keep the Properties the same for the Generator which you select in a rule

Conclusion

This new feature and the additional platform support in DATPROF Privacy Version 4.1 reinforces our position as a Global Leader in the provision of test data management solutions.

For more information or to arrange a personal demonstration of DATPROF Privacy Version 4.1 please contact us at any time.