In the 10th release of the Oracle Fusion Applications, the Oracle Data Masking for the Fusion HCM Cloud Services is provided to the customers as an optional subscription-based service. They plan to extend this service in the 11th release. It is so to include the ERP and sales cloud products that mask PII attributes in all the tables that are owned by these products.
What is data masking?
Data masking is also widely known as Data anonymization or data scrambling. It is a process of hiding all the sensitive and private information that is copied from a production database with actual scrubbed data based on the masking rules to a non-production or a test database. The process of data masking can be perfect for a situation where confidential, private, and regulated data needs to be shared with the non-production users who want access to the original data. But, they might not need the data for every column of every table. The example of such users is the internal application developers or some external business partners such as suppliers, customers, or even off-shore testing companies. It helps the customers generate realistic and fully functional data that has the same characteristics as the actual data to replace the sensitive or confidential information.
The customers of the software can always send a request for data masking as a part of an environment refresh appeal. PII or personally identified information data are masked or removed in the schema of applications and are removed further from the temporary tables, interface tables, and also the audit tables as well that include the workflow notifications. Besides that, the link to all the attachments is removed too which in turn removes the access to these attachments from all the user interfaces. Once the environment refresh is done, data masking is run and released to the customers when the masking process is finished.
Why data masking?
The main reason why data masking was introduced in the 10th release of fusion applications is that the developers wanted to fulfill the customer’s needs. It was to mask all their specific sensitive and personal data or the personally identified information (PII) attributes. There are a lot of masking rules applied to the attributes to ensure that the masked data does not fail validation when the same query arises in the fusion application user interfaces. Here is a list of all the PII attributes that data masking covers:
- Tax Registration Number or National Taxpayer Identifier
- Person Name
- Passport Number, Visa or Work Permit details
- Person Telephone Number
- Instant Messaging / Email Address
- Date of Birth
- Credit Card Number
- Date of Death
- Bank Account Number
- Country / Town / Region of Birth
- Address
The company strongly encourages its customers to use the principle of least privilege. They should do so when they grant users access to their masked database by restricting their access privileges. They should grant the users only those privileges which are required and necessary to complete their work.
The major aspect of data masking is replacing sensitive information with fictitious data. It is done without even the need to break the semantics and structure of the actual data. The data should be realistic and should pass the specific checks like the Luhn validation. Let us understand this with an example. Suppose a masked credit card number must not only be a valid card number but it must also be a valid MasterCard, visa discovers card number, or something else. It will break the corresponding application if it fails to maintain data integrity.
Drawbacks
There are some disadvantages that Oracle did not address for Data Masking in fusion applications. They are as follows:
- Sometimes running the payroll on masked data may not catch the valid results. It’s because sometimes any personally identified information attributes that are related to the payroll calculation are mixed up.
- Several sensitive information like compensation, benefits, and performance are not masked by it.
- All the underlying identities are not masked by it in the fusion schema. This is why it is possible to associate the internal database IDs with the identities and infer these identities in a masked database.
- Lastly, user login accounts are not masked by this system. Therefore, several formats like first name and last name may reveal the identity even in a masked database.
You need to make sure that you understand all the limitations of using the masked data before you request the data masking service. The data masking process may not be much of a help in specific scenarios like:
- Verifying the interfaces to downstream systems that need real unmasked data.
- Testing all the payroll calculations or the other processes that use data masked by the data masking service.
Data masking requirements
Organizations and companies mask their data using custom scripts or solutions. While all such in-house solutions might work for some columns, they don’t work for large applications that have distributed databases and hundreds of columns. An enterprise data masking system or solution should fulfill the following requirements for data masking:
- Make sure that the applications continue to work with all the masked data.
- Locate your sensitive data in the middle of many applications, environments, and databases.
- Ensure that your masked data is irreversible. Only then a person won’t be able to retrieve the actual data from the masked one.
- Mask all the sensitive data correctly that has different forms and shapes such as names, credit card numbers, etc.
- At last, make sure that the masked data is real. It’s because then you can use it for non-production purposes like analytics and development.