Data masking (also known as data scrambling and data anonymization) is the process of replacing sensitive information copied from production databases to test non-production databases with realistic, but scrubbed, data based on masking rules. Data masking is ideal for virtually any situation when confidential or regulated data needs to be shared with non-production users. These users may include internal users such as application developers, or external business partners such as offshore testing companies, suppliers and customers. These non-production users need to access some of the original data, but do not need to see every column of every table, especially when the information is protected by government regulations.

Data masking enables organizations to generate realistic and fully functional data with similar characteristics as the original data to replace sensitive or confidential information. This contrasts with encryption or Virtual Private Database, which simply hides data, and the original data can be retrieved with the appropriate access or key. With data masking, the original sensitive data cannot be retrieved or accessed.

Names, addresses, phone numbers, and credit card details are examples of data that require protection of the information content from inappropriate visibility. Live production database environments contain valuable and confidential data—access to this information is tightly controlled. However, each production system usually has replicated development copies, and the controls on such test environments are less stringent. This greatly increases the risks that the data might be used inappropriately. Data masking can modify sensitive database records so that they remain usable, but do not contain confidential or personally identifiable information. Yet, the masked test data resembles the original in appearance to ensure the integrity of the application.

The following types of users participate in the data masking process for a typical enterprise:

• Application database administrator or application developer

  This user is knowledgeable about the application and database objects. This user may add additional custom database objects or extensions to packaged applications, such as the Oracle E-Business suite.

• Information security administrator

  This user defines information security policies, enforces security best practices, and also recommends the data to be hidden and protected.

Besides data masking, Oracle offers the following security products:

• Virtual Private Database or Oracle Label Security — Hides rows and data depending on user access grants.

• Transparent Data Encryption — Hides information stored on disk using encryption. Clients see unencrypted information.

• DBMS_CRYPTO — Provides server packages that enable you to encrypt user data.

• Database Vault — Provides greater access controls on data.

Data masking supports Oracle Database 9i and newer releases. If you have a version prior to 11.1, you can use it by implementing the following workaround.

Replace the following file...

AGENT_HOME/sysman/admin/scripts/db/reorg/reorganize.pl

... with this file:

OMS_HOME/sysman/admin/scripts/db/reorg/reorganize.pl

Enterprise Manager provides several out-of-box predefined formats. All predefined formats and built-in formats are random. The following sections discuss the various Oracle-supplied format definitions and how to modify them to suit your needs:

• Patterns of Format Definitions

• Category Definitions

When you create a masking definition ("Masking with an Application Data Model and Workloads"), you will be either importing a format or selecting one from the available types in the Define Column Mask page. Format entry options are as follows:

• Array List

  Accepts a list of values as input and maps each value in the list to a value in the input column. The number of values in the list should be greater than or equal to the number of distinct values in the masked column. The values in the user-provided list are ordered randomly before mapping them to the original column values. For example, if the original column contains values [10,20,30,40,50] and the Array List specified by the user is [99,100,101,102,103], the first masking run could produce the mapping [10,101], [20,103], [30,100], [40,99], [50,102] and a different masking run can produce [10,100], [20,99], [30,101], [40,102], [50,103].

  A mapping table is created. The CTAS that creates the mapping table queries from:

  1. The original table to fetch the column values being masked and a row number for each column value. The row number is derived from the Oracle-supplied ROW_NUMBER function.

  2. The user-passed list of values — values in the user-passed array list are converted into a table-like record set using the SQL TABLE function. A row number is also retrieved corresponding to each value in the record set. The row number is derived from the ROWNUM pseudo column. The values in the record set are randomly ordered using DBMS_RANDOM.VALUE function.

  3. The mapping table CTAS then joins the row numbers in both sub-queries to map the original value (from sub-query in step 1 above) and a value from the user-list (sub-query in step 2 above). Multiple executions of the CTAS will create a mapping table with different original-masked value mappings because of the random ordering of the user list in step 2.

• Delete

  Deletes a row based on a condition. If the condition matches, then the row is deleted on the target. A mapping table is created. The “DELETE_VAL” column in the mapping table is set to 1 for rows that are candidates to be deleted. For example, we are masking the SALARY column and the masking definition has conditions on the EMPID column and formats defined as:

  EMPID < 100 
        DELETE 
  EMPID < 200
  	    RANDOM NUMBER [Start Value:1 End Value:100]
  DEFAULT
  	    PRESERVE
  

  The mapping table will have the DELETE_VAL column set to 1 for SALARY rows with EMPID < 100. DELETE_VAL for all other rows is set to 0. The final masking CTAS SQL which joins the original table and the mapping table to create the masked table filters out rows with DELETE_VAL set to 1. Therefore, the rows in the original table that match the join condition are effectively “deleted”.

• Encrypt

  The data in the table is fixed and does not change. Encrypts a column based on a regular expression. The column values in all the rows must match the regular expression. For a given value, the format always generates the same masked value. This format implements Format Preserving Encryption (FPE) by invoking dbms_crypto using 3DES with multiple cycles. The format is not trivial and involves significant processing. The function used is:

  function encrypt( orig_value varchar2, fmt mgmt_dm_formatmap, max_value number,inpsd number) return varchar2; max_value number,inpsd number) return varchar2;

  orig_value is the original value of the column before it was masked. fmt and max_value are specific to the FPE and are known at the time of generating the script. inpsd is the input seed the user specifies when executing the generated script. This value is not known during script generation time. When the SQL invoking this function is executed during incremental masking, the seed value is required. One option is to persist it in a table on the target when the user executes the masking script. The PL/SQL code executed during replication will look like this:

  1. Fetch the seed from the table.

  2. Invoke the SQL query that has a call to encrypt (and possibly other formats). Pass the replicated column value and the seed obtained from step 1 to the procedure. The query will return the masked value.

  Encrypt creates a mapping table when there is a combination of formats under conditions. No mapping table is created when Encrypt is the only format available for the column, since the PL/SQL code implementing encrypt is invoked inline from the final masking SQL.

• Fixed Number

  This format does not use a lookup or a mapping table. It assigns a fixed number value to a string/number column.

  The type of column applicable to this entry is a NUMBER column or a STRING column. For example, if you mask a column that has a social security number, one of the entries can be Fixed Number 900. This format is combinable.

• Fixed String

  This format does not use a lookup or a mapping table. It assigns a fixed string value to a string column.

  The type of column applicable to this entry is a STRING column. For example, if you mask a column that has a License Plate Number, one of the entries can be Fixed String CA. This format is combinable.

• Null Value

  Masks the column with a value of NULL. It does not use a lookup or a mapping table.

  Note:

  Fixed number/string and null value formats are implemented through mapping tables when a column is masked through multiple formats. For example, mapping table is used when SALARY is masked with fixed number for EMPID<100 and with random numbers for EMPID>100. Similar to the encrypt format, no mapping table is created when the column does not have a combination of formats. In the example, no mapping table is created when only fixed number is used to mask SALARY for all EMPID values. In this case, the formats are implemented inline in the final masking SQL.

• Post-Processing Function

  The format allows users to use a custom function to process column values after they are masked using standard data masking formats. For example, the SALARY column can be masked with a SQL expression first, and a post processing function can be applied on the masked values to add a currency symbol, like ‘$’. The function has a fixed signature:

  function post_proc_func(rowid varchar2, column_name varchar2, mask_value varchar2) returns varchar2;

  The ROWID input allows a user to fetch column values from the masked table. The function could these values to mask the input column value, basically to transform the column further after a standard format is applied on the column. This format creates a mapping table. The post processing function gets invoked as part of the mapping table CTAS SQL. The input to the mask_value argument of the function is the masked value of the original column. For example, say we are masking the SALARY column and the mask definition has conditions on the EMPID column and formats are defined this way:

  EMPID < 100 
        RANDOM NUMBERS [START:100000 END: 10000000]
        POST PROCESSING FUNCTION ppf 
  EMPID < 200
  	    FIXED NUMBER 100000
  DEFAULT
  	    PRESERVE
  

• Preserve Original Data

  Preserves the original column value. Used in conditional masking with a combination of other formats where only a subset of values needs to be masked based on a condition.

• Random Dates

  The format creates a mapping table. The mapping table CTAS contains code to generate random dates within a user specified date range. A random date is generated using the following logic:

  TO_DATE(start_date','YYYY-DD-MM HH24:MI:SS') + 
  mask_util.genrnd(0, <#of days between the specified date range>)

• Random Decimal Numbers

  If used as part of a mixed random string, these have limited usage for generating unique values. This masking format generates unique values within the specified range. For example, a starting value of 5.5 and ending value of 9.99 generates a decimal number ranging from 5.5 to 9.99, both inclusive. This masking format is combinable.

• Random Digits

  This format generates unique values within the specified range. For example, for a random digit with a length of [5,5], an integer between [0, 99999] is randomly generated, left padded with '0's to satisfy the length and uniqueness requirement. This is a complementary type of random number, which will not be padded. When using random digits, the random digit pads to the appropriate length in a string. It does not pad when used for a number column. This format is combinable.

  Data masking ensures that the generated values are unique, but if you do not specify enough digits, you could run out of unique values in that range.

• Random Numbers

  If used as part of a mixed random string, these have limited usage for generating unique values. This format generates unique values within the specified range. For example, a starting value of 100 and ending value of 200 generates an integer number ranging from 100 to 200, both inclusive. Note that Oracle Enterprise Manager release 10.2.0.4.0 does not support float numbers. This format is combinable.

• Random Strings

  This format generates unique values within the specified range. For example, a starting length of 2 and ending length of 6 generates a random string of 2 - 6 characters in length. This format is combinable.

• Regular Expression

  The format uses a lookup table. No mapping table is created. The PL/SQL function that implements the format is invoked directly from the final CTAS which creates the masked table. The lookup table has two columns to store the regular expression and the replacement value specified by the user. The SQL REGEXP_REPLACE function is used to implement this format.

  The function has the signature:

  regexp_replace(column_value, regex, replacement_val);

  For example, phone numbers in the format nnn.nnn.nnnn can be masked using a regex [1-9]{3}[.][0-9]{3}[.][0-9]{4} with a replacement value ***.***.****. The format invokes the regexp_replace for each regexp-replacement value pair. If the phone number column was masked using regular expression:

  EMPID < 100
    Regular Expression  	Regex: [1-9]{3}[.][0-9]{3}[.][0-9]{4}  Replacement Value: 999.444.555
    Regular Expression  	Regex: [9]{3}[.][4]{3}[.][5]{4} 	  Replacement Value: ***.***.***
  

  Each column value matching the first regular expression is first replaced with 999.444.555, this value then matches the second regular expression and is replaced with ***.***.***. The example is not a real world use case. The behavior probably is a side effect of how the format is implemented, the real use case of specifying multiple regular expression formats to mask a column is to handle cases when the data in the column could match multiple regular expressions. For example:

  EMPID < 100
    Regular Expression  	Regex: [1-9]{3}[.][0-9]{3}[.][0-9]{4}  Replacement Value: ***.***.****
    Regular Expression  	Regex: [1-9]{3}[.][0-9]{3}[.][0-9]{3}  Replacement Value: ***.***.***
  

  can be used to mask column values that store 10 digit - nnn.nnn.nnnn - or 9 digit - nnn.nnn.nnn - phone numbers.

• Shuffle

  This format does not use a lookup or a mapping table. The final CTAS which creates the mapping table includes a sub query to order the column contents randomly using the DBMS_RANDOM.VALUE function. If shuffle is used with a grouping column, the PARTITION clause is used to partition by the grouping column and the column is ordered randomly within each partition. The implementation is similar to that of Array List and Table Column. The random ordering for the shuffle format occurs on the column being “shuffle masked”, whereas in Array List, it is on the user-passed list, and in Table Column, the ordering is on the user-specified column.

• Substitute

  The format creates a mapping table. It uses a user specified “substitution” table as a source for masked values. The format uses the Oracle supplied hash based partitioning function ORA_HASH to map a column value to its mask value in a lookup (substitution) table. Processing involves querying the substitution table to get a count of distinct values in the mask column. This count – say n - is then used as the max_bucket parameter of ORA_HASH to hash the original column values into n buckets. For example, if we are masking EMPLOYEE.SALARY and using SUBST.SUB_COL column as the substitution column, we first get the count of distinct values in SUB_COL. The mapping table CTAS then queries:

  1. The original column, EMPLOYEE.SALARY

  2. The user provided substitution table to fetch all the distinct values in SUBST.SUB_COL and also fetches the ROWNUM associated with each row

  The CTAS SQL then joins 1 and 2 using ORA_HASH and equating its output to the ROWNUM from step 2. The SELECT part of the CTAS SQL is listed below. max_bckt is the count of distinct values in the substitution column SUBST.SUB_COL:

  select s.orig_val,
         a0.new_val
  from ( select orig_val
         from (select "SALARY" orig_val
          	 from "TESTU"."EMPLOYEE") 
         group by orig_val) s,
       (select rownum rn, 
               SUB_COL new_val 
        from (select distinct SUB_COL
              from TESTU.SUBST
              order by SUB_COL)) a0
   where ora_hash(s.orig_val, max_bckt, seed)+1 = a0.rn
  

• SQL Expression

  The format does not create a mapping table. It allows a user to use a SQL Expression for masking a column. Data masking uses this expression to generate masked values to replace the original values. The expression is invoked directly from the masking CTAS SQL. The SQL Expression can consist of one or more values, operators, and SQL functions that evaluates to a value. It can also contain substitution columns (columns from the same table as the masked column). Some examples of valid expressions:

  1.	dbms_random.string('u', 8) || '@company.com'
  2.	%first_name% || '.' || %last_name% || '@company.com'
  3.	dbms_lob.empty_clob()
  4.	custom_mask_clob(%CLOB_COL%)
  5.	(case when %PARTY_TYPE%='PERSON' then %PERSON_FIRST_NAME%|| ' ' ||%PERSON_LAST_NAME% else (select dbms_random.string('U', 10) from dual) end)
  6.	select MASK_ZIPCODE from data_mask.DATA_MASK_ADDR where ADDR_SEQ = ora_hash( %ZIPCODE% , 1000, 1234)

• Substring

  The format creates a mapping table. The mapping table CTAS invokes the Oracle SUBSTR function on the input column. The format accepts a start position and length as input, extracts that data from the input column using SUBSTR, and uses that as a mask value.

• Table Column

  The format creates a mapping table. The format maps original column values to column values in a user specified table. The processing is similar to the array list format. The values in the user specified table are randomly ordered using DBMS_RANDOM.VALUE before mapping each value to the original column. Unlike the Substitute format, the format is not deterministic since the substitution column is randomly ordered.

• Truncate

  The format truncates all rows in a table. It does not create a mapping table. If one of the columns in a table is masked using this format, so no other mask formats can be specified for any of the other columns.

• User Defined Function

  The format creates a mapping table. The return value of the user defined function is used to mask the column. The function is invoked as part of the mapping table CTAS. The function has a fixed signature:

  function userdef_func(rowid varchar2, col_name varchar2, orig_val varchar2) returns varchar2;Function udf_func (rowid varchar2, column_name varchar2, original_value varchar2) return varchar2;
  

You may occasionally need to consistently mask multiple, distinct databases. For instance, if you run HR, payroll, and benefits that have an employee ID concept on three separate databases, the concept may be consistent for all of these databases, in that an employee's ID can be selected to retrieve the employee's HR, payroll, or benefits information. Based on this premise, if you were to mask the employee's ID because it actually contains his/her social security number, you would have to mask this consistently across all three databases.

Deterministic masking provides a solution for this problem. You can use the Substitute format to mask employee ID column(s) in all three databases. The Substitute format uses a table of values from which to substitute the original value with a mask value. As long as this table of values does not change, the mask is deterministic or consistent across the three databases.

1. Enter search criteria, then click Search.

   The sensitive columns you defined in the ADM appear in the table below.

2. Either select one or more columns for later formatting on the Create Masking Definition page, or formatting now if the data types of the columns you have selected are identical.
3. Optional: if you want to mask selected columns as a group, enable Mask selected columns as a group. The columns that you want to mask as a group must all be from the same table.

   Enable this check box if you want to mask more than one column together, rather than separately. When you select two or more columns and then later define the format on the Define Group Mask page, the columns appear together, and any choices you make for format type or masking table apply collectively to all of the columns.

   After you define the group and return to this page, the Column Group column in the table shows an identical number for each entry row in the table for all members of the group. For example, if you have defined your first group containing four columns, each of the four entries in this page will show a number 1 in the Column Group column. If you define another group, the entries in the page will show the number 2, and so forth. This helps you to distinguish which columns belong to which column groups.

4. Either click Add to add the column to the masking definition, return to the Create Masking Definition page and define the format of the column later, or click Define Format and Add to define the format for the column now.

   The Define Format and Add feature can save you significant time. When you select multiple columns to add that have the same data type, you do not need to define the format for each column as you would when you click Add. For instance, if you search for Social Security numbers (SSN) and the search yields 100 SSN columns, you could select them all, then click Define Format and Add to import the SSN format for all of them.

5. Do one of the following:

   • If you clicked Add in the previous step:

     You will eventually need to define the format of the column in the Create Masking Definition page before you can continue. When you are ready to do so, click the icon in the page Format column for the column you want to format. Depending on whether you decided to mask selected columns as a group on the Add Columns page, either the Define Column mask or Define Group mask appears. Read further in this step for instructions for both cases.

   • If you clicked Define Format and Add in the previous step and did not check Mask selected columns as a group:

     The Define Column Mask page appears, where you can define the format for the column before adding the column to the Create Masking Definition page, as explained below:

     • Provide a format entry for the required Default condition by either selecting a format entry from the list and clicking Add, or clicking Import Format, selecting a predefined format on the Import Format page, then clicking Import.

       The Import Format page displays the formats that are marked with the same sensitive type as the masked column.

     • Add another condition by clicking Add Condition to add a new condition row, then provide one or more format entries as described in the previous step.

     • When you have finished formatting the column, click OK to return to the Create Masking Definition page.

   • If you clicked Define Format and Add in the previous step and checked Mask selected columns as a group:

     The Define Group Mask page appears, where you can add format entries for group columns that appear in the Create Masking Definition page, as explained below:

     • Select one of the available format types. For complete information on the format types, see the online help for the Defining the Group Masking Format topic.

     • Optionally add a column to the group.

     • When you have finished formatting the group, click OK to return to the Create Masking Definition page.

       The results appear in the Columns table. The sensitive columns you selected earlier now appear on this page. Primary key and foreign key columns appear below the sensitive columns.

   Note:

   When you add a column for masking, and select the available format types, you can specify the value for the masking format, and click the Show Sample icon to view a sample data masking format. However, the Show Sample icon isn't displayed for the delete, truncate, and null value formats.

The following options on the Masking Definitions page are all checked by default, so you need to uncheck the options that you do not want to enable:

• Data Masking Options

• Random Number Generation

• Pre- and Post-mask Scripts

1. Select the masking definition to generate a script for, then click Generate Script.
2. Change the default job name to something meaningful, if desired, and provide an optional job description.
3. Select a reference database from the drop-down list.
4. Select a script generation option:

   • Mask In-Database–to replace sensitive data in-place with masked data on a specified database (usually copied from production). Use this option only in non-production environments. This differs from the Actions menu option Clone Database, which clones the database and then masks the data.

   • Mask In-Export–to export masked data from the specified source database (usually production) using Oracle Data Pump. This option is safe to run in a production environment as it does not modify customer data. Note, however, that this option creates temporary tables that get dropped when the masking operation completes.

   Note that you can choose both options; that is, a script to mask the database directly and a script to create a masked dump.

5. Specify credentials to log in to the reference database.
6. Specify to start the job immediately or at a later specified date and time, then click Submit.

   A message confirms that the job has been scheduled. Refresh the page to see the job results.

1. Select the masking definition for which a script has been generated, then click Schedule Job.
2. Change the default job name if desired and enter an optional job description.
3. Select a database from the drop-down menu and indicate your preference:

   • Mask In-Database–to replace sensitive data in-place with masked data on a specified database (usually copied from production). Use this option only in non-production environments. This differs from the Actions menu option Clone Database, which clones the database and then masks the data.

     Note:

     You must enable the check box indicating that the selected target is not a production database in order to proceed.

   • Mask In-Export–to export masked data from the specified source database (usually production) using Oracle Data Pump. This option is safe to run in a production environment as it does not modify customer data. Note, however, that this option creates temporary tables that get dropped when the masking operation completes.

   Your selections affect the check box text that appears below the radio buttons as well as other regions on the page.

4. Proceed according to your selections in Step 3:

   • Data Mask Options–Provide the requisite information as follows:

     • After script generation completes, the data masking script is stored in the Enterprise Manager repository. By default, the data masking job retrieves the script from the repository and copies it to the $ORACLE_HOME/dbs directory on the database host, using a generated file name. The Script File Location and Name fields enable you to override the default location and generated file name.

     • Workloads–Select options to mask SQL tuning sets and capture files, as appropriate. Browse to the file location where you want to capture the files.

     • Detect SQL Plan Changes Due to Masking–Run the SQL Performance Analyzer to assess the impact of masking. Provide a task name and browse to the corresponding SQL tuning set.

   • Data Export Options–Provide the requisite information as follows:

     • Specify a directory where to save the mask dump. The drop-down list consists of directory objects that you can access. Alternatively, you can select a custom directory path. Click the check box if you want to speed the process by using an external directory. Recommended default: DATA_FILE_DIR.

     • Specify appropriate values if you want to override the defaults: enter a name for the export file; specify a maximum file size in megabytes; specify the maximum number of threads of active execution operating on behalf of the export job. This enables you to consider trade-offs between resource consumption and elapsed time.

     • Specify whether to export only the masked data or the entire database along with the masked data.

     • Select whether to enable dump file compression and encryption. Enter and confirm an encryption password, if appropriate. Log file generation is selected by default.

5. Specify credentials to log in to the database host.
6. Specify credentials to log in to the reference database.
7. Choose one of the following options to create temporary objects:

   • Optimize storage using default settings — creates all the mapping tables in the user’s default tablespace. While creating the mapping tables, basic compression is used to compress the mapping tables.

     Mapping tables are used to transform one value to another in an Oracle database.

   • Optimize storage using recommended settings — creates a compressed tablespace. All the intermittent objects (mapping tables as well as the copy of original tables being masked) will be created in this tablespace.

     Note:

     If the DB_CREATE_FILE_DEST is set, the datafile required for the new tablespace will be managed by Oracle. Otherwise, the datafile for the new tablespace will be created in the directory from where the masking script is being run.

     This tablespace will be dropped when the masking job is completed. However, the tablespace is not dropped if the user chooses not to drop the mapping tables while creating the script.

   • Optimize storage using custom settings

     • Create temporary objects in a custom tablespace — creates temporary objects in the tablespace specified in step 8. Basic compression will be used to compress these temporary objects.

     • Create temporary objects and copy of table being masked in a custom tablespace — creates the temporary objects that are compressed, and creates a copy of the original table that is being masked while moving it to the tablespace specified at Step 8.

     Note:

     This option might increase the masking time considerably as it makes a copy of the original table and moves it to the custom tablespace.

     For accurate storage estimates, ensure that you use dbms_stats.gather_table_stats to gather the stats of all the tables participating in the masking process.

8. If you chose custom settings in Step 7, select a custom tablespace where the objects must be created.
9. Specify to start the job immediately or at a later specified date and time, then click Submit.

   A message confirms that the job has been scheduled. Refresh the page to see the job results.

Here are some guidelines for estimating space requirements for masking operations. These estimates are based on a projected largest table size of 500GB. In making masking space estimates, assume a "worst-case scenario."

• For in-place masking:

  • 2 * 500GB for the mapping table (the mapping table stores both the original and the masked columns. Worse case is every column is to be masked).

  • 2 * 500GB to accommodate both the original and the masked tables (both exist in the database at some point during the masking process).

  • 2 * 500GB for temporary tablespace (needed for hash joins, sorts, and so forth).

  Total space required for the worst case: 3TB.

• For at-source masking:

  • 2 * 500GB for the mapping table (as for in-place masking).

  • 2 * 500GB for temporary tablespace (as for in-place masking).

  • Sufficient file system space to accommodate the dump file.

  Total space required for the worst case: 2TB plus the necessary file system space.

In either case, Oracle recommends that you set the temp and undo tablespaces to auto extend.

You can specify a tablespace for mapping tables during script generation. If you do not specify a tablespace, the tables are created in the tablespace of the executing user. Note that space estimations are provided during script generation, with resource warnings as appropriate. There are some situations, for example when using the shuffle format, that do not require a mapping table. In these cases, updates to the original table happen in-line.

Dependent columns are defined by adding them to the Application Data Model. The following prerequisites apply for the column to be defined as dependent:

• A valid dependent column should not already be included for masking.

• The column should not be a foreign key column or referenced by a foreign key column.

• The column data should conform to the data in the parent column.

If the column does not meet these criteria, an "Invalid Dependent Columns" message appears when you attempt to add the dependent column.

1. On the Data Masking Definitions page, click Export from Software Library.
2. Select a masking template in the Software Library list.
3. Click Export.

   Save the template file for import into a different repository.