Masking

As an organization, if you plan to restrict access such that only users with required privileges can view sensitive data, while other users view masked data, the Masking method can be used. Considering the sensitive data is residing in protection endpoint in clear, based on how the Masking data element is configured, users are granted view access. The masking data element as a default considers all users as restricted users and displays masked sensitive data. If any user must be granted access to view clear data, then it must be configured through roles.

For example, consider policy users user1 and user2 trying to access CCN data. As default, when policy with the masking data element is created, both users view the CCN data in masked format, such as ****45856655****. If the user1 is granted privilege to view data in clear, then user1 sees the CCN data in clear while the user2 still sees masked CCN data.

With the Masking method, the users who should not use sensitive assets can be prevented from receiving this data, even if the data is stored in the clear.

Unlike Masking data element, masking cannot be enabled for No Encryption data element. It can only be mapped to roles in policy. In contrast, when masking is enabled through a Masking data element, the data is masked for all users unless authorized users have permission to view it in clear.

Similar to the No Encryption method, implementation of the Masking method does not cause any changes in the target environment.

The Masking data element is created in combination with the Masks option. The Masks option helps define how the masked data output format is visible to users.

The masking method is controlled by the security officer from the centrally administered ESA Appliance.

For more information about creating masks, refer to Creating a Mask.

Note:
If a masking data element is configured in the policy, and username is not specified in the policy, an error message will display when the data is protected. That error message appears as:

The user does not have the appropriate permissions to perform the requested operation

Table: Masking Algorithm Properties

The following table shows examples in which a value will be protected with the Masking algorithm.

Table: Output Values for Masking Algorithm

Using Masks

The Masks option is a data output restriction that is used in combination with the tokenization, encryption, no encryption, and masking protection methods. Masks define data output formatting, which means what data to disclose to users that want to view the data. The formatting includes unprotecting and transforming the result in a way that part of it is obfuscated. For example, a masked social security number could look like: 12345****, or ***456789.

Using a mask for the output is optional. If none is specified, then all data is returned in the masked output format by default for all users who are not a part of any policy. If users are a part of the policy:

• Data is shown in the clear for No Encryption data elements.
• Data is masked in output format for Masking data elements.

Masks are defined in the ESA and have the following properties:

• Mask name and description
• Number of characters from left
• Number of characters from right
• Whether “left” and “right” should be masked or clear
• Specific mask character - *,#,-,0,1,2,3,4,5,6,7,8, or 9.

The mask definition or how the mask looks like is implemented as per role and data element combination. This means that one data element can have multiple mask definitions.

When a mask is applied to data that is too short, that is, the data will not match to what has been defined in the mask, everything gets masked. For example, if a mask of 6 from the left and 2 from the right will be applied to data that has a length of 4, such as a name John, then all four characters will be masked.

If a user role is included in multiple policies with masks, then the masks may conflict in one of the following conditions:

• The user has different mask settings for both roles for the same data element. In this case, the unprotect access rights to the data element with the conflicting masks are revoked.
• The user has the data element with a mask in a role and another with no mask settings in the other role. In this case, the user’s access rights to the data element is set to the role with no mask settings.

For more information about masking rules for users in multiple roles, refer to Masking Rules for Users in Multiple Roles.

Important: Masking is supported only for character-based data types. If a role with masking is applied to unsupported data types, the operation will fail.

It is not recommended to use Masking with multibyte encodings, such as UTF-8, UTF-16, and so on, as it might corrupt the data.

The masked, unprotected value is distorted in the above case. Since each character in the input is represented by 2 bytes in UTF-8 encoding, we aim to preserve the first 3 bytes from the left and the next 3 bytes from the right. However, this approach results in a distorted output.

The following table shows examples of the way in which Masks can be used in combination with other protection methods.

Table: Examples of Masks

Combining Data Elements and Masks

Masks are always applied using the supported Data Elements. The Masks are applied right before the data is presented to the end-user.

Tokenization, Encryption, FPE, No Encryption, and Masking Data Elements all support Masks, with some exceptions as to the configuration. Refer to support matrix below to check whether a specific Data Element and Mask combination is supported.

When combining Masks with tokenization, encryption, and FPE, sensitive data will be unprotected before a Mask is applied. In the case of the Masking Data Element, data is masked during the unprotect operation only.

Table: Data Element and Mask Support Matrix

Masking for Protectors

The Input type / Character set for all protectors vary across DBs. The Output type / Character set is the same as the input type. For example; if the input type is an integer, then the output type is also an integer.

Application Protector

Table: Input Data Types Supported by Application Protectors

If the input and output types of the API are BYTE [], the customer application should convert the input to a byte array. Then, call the API and convert the output from the byte array.

For more information about Application protectors, refer to Application Protector.

Big Data Protector

Table: Input Data Types Supported by Big Data Protectors

^*1 - The customer application should convert the input to and output from byte array.

For more information about Big Data protectors, refer to Big Data Protector.

Data Warehouse Protector

Table: Input Data Types Supported for Data Warehouse Protectors

Important: Masking is supported only for character-based data types. If a data element with masking is applied to an unsupported data type, the operation will fail.

Database Protectors

Oracle Database Protector

The supported input data types for the Oracle Database Protector are listed below.

Note: While unprotecting the data, the masked value is passed to Oracle. These masked strings are not valid hex values. Therefore, the following error is observed; ORA-06502: PL/SQL: numeric or value error: hex to raw conversion error.

Important: Masking is supported only for character-based data types. If a data element with masking is applied to an unsupported data type, the operation will fail.