Mask Functionality in DS 4.2 SP 04

Hi Kolli,

This transform is different in lots of ways.  The Data Mask transform allows you to mask sensitive data while keeping the data relevant so it can be used by other systems and allows you to keep the referential integrity.  I've added some examples below of what the data mask transform can do for you:

Preserving relationships:
In a normalized relational database quite frequently we rely on data itself to
be a key of the table, for example social security number is unique and could
be the primary key of that table. In this case references to SS# in other
tables (foreign keys) should match the values of the primary key, otherwise it
will be impossible to relate the tables. For example one table may contain SS#
and names, other may contain SS# and purchase history and the tables need to be joined on SS#.

Preserving the shape of the data set:
Blanking out sensitive data also makes it hard to do analysis on it down
stream. For example, changing all birthdates to 1/1/1900 while hiding
information makes it hard to do demographic analysis. In this particular
example it may better to scramble the day and month while retaining the year.  Similarly, though we may de-identify zip codes, we want the number of rows mapping to the obfuscated zip code to remain the same so we know how the data is distributed without knowing the actual data

Keeping the data sensible:
People consuming the data downstream will find it hard if they are dealing with nonsensical data. For example if we convert a name like ‘John W. Duncan' to ‘@#R%amkGG87%%’ it is jarring both visually and also creates problems for other programs operating on this data downstream (for example asserting that name should be made of alphabets). It would be better if we convert ‘John W. Duncan’ to ‘Scott T. Smith’ instead. This also holds for address information, ‘TX’ should be scrambled to something like ‘IL’ not ‘ZZ’. Care should be taken that we don’t inadvertently provide wrong data – it would not do if we change a social security number and the new social security number identifies a different but valid person! Another point to keep in mind is the range of the de-identified value. For example, if we want to scramble the salary information of employees that new value should fall within a reasonable range – this could be an absolute number (between 10K and 1000K) or a percentage (+/- 50% of original value).

Preserving part of the data:
Quite often only part of the data is sensitive, for example in a credit card
number the first 6 digits identify country and issuing bank and that can be
open (and is useful information), but the rest of the digits should be hidden.
Similarly in an e-mail we may want to hide just the username part while leaving the domain open.

Preserving the format:

A simpler requirement (than the sensible data need) is to at least maintain the
format of the data. For example e-mail should map from lynne@sap.com to asdfa@xx_email.com rather than ‘elrjnmkmjnfer##’,
same thing with social security numbers.

Sufficient de-identification:
It is important that information isn’t reconstituted by linking the scrambled
information with other sources that are not scrambled. For example if in the
Salary table we obfuscate the names of people but leave their city of residence
open and if there is another table where the employees and their addresses are listed we can by cross reference infer information in the scrambled data set. For example we have: Name: John Smith Sal: $9,000,000 City: Scotts Vally.  And in another table we have Name: John Schwarz City: Scotts Valley and there is only 1 employee in Scotts Valley ergo we know how much John makes. So it is important that combination of multiple fields be considered when creating the anonymization. This is also important when there are a limited number of source values, for e.g. if you want to hide the *** of a person no point mapping M to X and F to Y, it is easily deducible.

I hope this helps.

Lynne