“Who Was That Masked Man?”

What is Data Masking?

Data masking, sometimes known as data obfuscation, or scrambling, is the process of protecting classified, personally identifiable, or commercially sensitive data with random characters (https://en.wikipedia.org/wiki/data_masking). Data masking has been historically used to enforce data security in non-production systems to protect it from prying eyes during the software development, quality assurance, and testing lifecycle. For example, a dataset used for testing software would be masked to ensure that social security numbers, credit card numbers and names all conform to the correct data format, but contain fake values, as in the example below:

Development teams apply masking either when the test dataset is created, or after it’s written to the database. The former option is known as “dynamic data masking” (i.e., applying obfuscation “on the wire”). The latter is known as “masking the data at rest” (i.e., running queries to scramble existing data values in the database).

There are a variety of solutions to mask data in various ecosystems, but if you’re an SAP customer, then Attunity has an excellent solution for you. Attunity Gold Client improves the efficiency, cost, and security of managing your test data with features such as data masking and subset replication. Follow the link for more information about Attunity Gold Client.

Data Masking – Critical for SAP GDPR Compliance

We all know that the General Data Protection Regulation (GDPR) for citizens of the European Union (EU), is prompting enterprises to re-think their data management practices because penalties for a data breach are steep. Most of us think of a data breach in terms of the actual loss or exposure of information to an unauthorized or unintended user. However, when it comes to the EU regulation, it also includes a violation of the legislation. While an in-depth discussion of GDPR compliance is beyond the scope of this article I do want to highlight how you can leverage data masking to reduce the risk of an unintended data breach.

Enforcing GDPR Article 17 – Right to Erasure (Not an ‘80s pop duo)

GDPR Article 17 – Right to erasure (aka. ‘right to be forgotten’) is one of the most challenging aspects of GDPR because we just can’t comply by deleting the client’s PII records from our production systems. Often there are additional regulatory requirements like tax record retention policy that means we need to retain customer information, and also GDPR states that article 17 shall not apply “to the extent that processing is required”. In addition, there are business constraints that can prevent deletion of customer data. For example, the customer may have an active contract or outstanding balance, and deleting the data might stop us from servicing the client or getting paid. Finally, there are many technical reasons why we just can’t delete customers personal information too. The underlying records are likely cross referenced by other information systems and referential integrity will break if we delete them. Implementing and complying with article 17 is a tricky problem indeed!

Attunity Gold Client for Data Protection

If you have an SAP system, then once again you’re in luck because we’ve launched Attunity Gold Client for Data Protection. Attunity Gold Client for Data Protection helps you to quickly and easily detect, identify and fix your exposure to GDPR Article 17 non-compliance for your SAP production systems. The secret sauce to make this happen is… you guessed it… DATA MASKING the production records, rather than deleting them. By masking the data, you can comply with the right to be forgotten AND maintain the referential integrity of your SAP systems. Also, the anonymization process can be applied across all core and/or industry-specific SAP modules and cannot be reverse engineered to recreate the original data. Thus ensuring that the customer data is very definitely “erased”. But there’s much more to the compliance process than that. Let’s work through an example for an on-line retailer who uses SAP as the customer master. Using Gold Client for Data Protection the retailer performs the following steps:

Step 1 – Define Erasure Policy

The retailer has decided that any customer who does not have an outstanding balance and has not purchased an item in 3 years is a candidate for erasure. Note the retailer tax retention policy is also 3 years.

Step 2 – Define Masking Policy

The retailer has decided that it will mask names, addresses, emails, phone numbers and credit card numbers. The retailer also defines an “undo period” at this stage. The default is 30 days. We’ll discover why this is important later.

Step 3 – Run Exposure Report

The retailer now runs an exposure report on the production SAP system. The output describes which customers can be safely masked, aka “forgotten”. The retailer also has the option just to confirm singular requests for erasure.

Step 4 – Execute the Masking Process

The retailer’s next step is to run the Gold Client for Data Protection masking process on the production SAP system. As each record is masked, an entry is written to the SAP transaction log. Note that Gold Client for Data Protection ALSO masks the data in the transaction log, otherwise erasure will not be GDPR compliant since PII data will remain in the log. At this stage the masking process can be reversed until the “undo period” has expired. It’s also worth noting that the GDPR masking change will trigger interface updates downstream. This ensures that the GDPR change is propagated and applied to any downstream systems that receive updates to that same data. For example, masking changes will filter down to SAP CRM, SRM and BW systems. Even non-SAP targets that are configured to listen for updates will receive the masked data.

Step 5 – Confirm Erasure Compliance

The final step is to re-run the exposure report and confirm that the records have indeed been masked/forgotten. If the retailer just masked individual customer records, then they can use the SAP application to confirm that the customer account has indeed been “erased” according to the masking rules.

And that’s it! Gold Client for Data Protection makes the process of complying with GDPR article 17 a whole lot easier. Oh, and it’s not surprising that the product has features that specifically match the erasure process.

Gold Client for Data Protection features:

• Configurable erasure-policy rules: Rules that define which records can be masked.
• Custom data masking instructions: Rules that define how record field values are masked.
• PII exposure reporting: Reporting to highlight records that match erasure policy criteria.
• SAP change log protection: The process of masking PII data in SAP transaction logs.
• User-defined “undo” period: The period after which data masking is irreversible.

Conclusion

Data Masking is a technique that’s used to obfuscate data for the express purpose of security, and it’s traditionally been used to protect data in non-production systems. However, it’s become an essential technique with the ascent of GDPR and the “right to be forgotten”. Gold Client for Data Protection uses these methods and enhanced processes to help you comply with GDPR Article 17 – Right to Erasure. So next time you hear “Who was that masked man?” the answer is surely, “We don’t know because we’ve use Gold Client for Data Protection.”

Next Steps

Request a Gold Client for Data Protection Demo.