The article, written by Anushka Asthana (Policy Editor), discussed the concerns around using data masking or “anonymization techniques” to de-identify sensitive and personal information. Many large and well-known multi-national organizations and government agencies are using data masking methods to keep their production data secure (or anonymous) when they use it in development and test.

Anushka’s article, however, states that computer scientists in the US have discovered ways to “re-identify” the personal information of individuals who were included in anonymous datasets. How?, through using a statistical “de-anonymization” technique or, as my last blog suggested, re-engineering of masked test data.

So, as Anushka’s article asks, just how safe is it to share personal and sensitive information even if it is masked or de-identified? The answer, once again, is not very.

Organizations should start looking into other methods to secure their production data when using it outside of their “live” environment; whether this be for testing, development, training, QA or even presenting statistical information. My last two blogs discuss the option of using ‘data creation’ techniques. No, this isn’t the process of “creating” or making-up some data based on whatever fake names or addresses come into your head. It’s quite a sophisticated process, and the end-product is secure test data that can never be re-engineered. It’s based on a model of your production environment, so the data maintains referential integrity and is exactly like “live” data, but it isn’t. Read my last two blogs to find out more.

There is only one issue changing our IT infrastructures and threatening the comfortable and reliant procedures we know good and well; compliance. Yes, we’re now in the data protection era. Regulating bodies would rather personal information be kept safe and secure inside the production database where it belongs, thank-you-very-much. Also, ignoring compliance measures isn’t really the best idea. We’ve learnt this firsthand from our competitors and their very public data breaches whilst secretly smiling to ourselves, relieved it didn’t happen to us.

However, let us consider for a moment the potential implications of your organization’s sensitive data being leaked into the public domain by some unfortunate soul’s mindless mistake:

• Potential law suit – check
• Damage to corporate brand and reputation – check
• Large fines imposed by regulating bodies – check
• Loss of integrity and potential loss of customers – check

So, what about data masking – you ask? It’s a quick and easy way to solve the problem, right? Let’s get a bit of production data, scramble it up, de-identify some names and – there you go. You’ve got your test data and the perfect solution to the thorn digging into your side.

Oh, but wait. We now hear data masking isn’t actually that secure. Bugger.

Then what alternative do we have? Well, using ’synthetic’ or ‘fake’ test data seems to be the topic of the day – the new method, the new ‘fad’ if you will.

Now, for those of you who don’t know, test data creation is a bi-product of modeling and sampling production data. What is modeled is then turned into data objects or templates which are based on the entire production environment. The templates can be edited or enhanced based on project needs, or moved into different data formats like flat files or CSV files.

This may sound impossible to you. You may be thinking about the referential integrity of your production database; the value of every table, every cell, every format, every name, how each table is ever so consequentially connected to one another. But it’s rather easy, actually – very easy to be frank.

I’ve started looking into this as part of my consultancy. It came to light when I was contacted by a government agency needing an alternative to data masking. I’m impressed. It is true – using test data creation is the way forward. On top of this, less data is actually being used and stored, since the data is generated from the model into a small template. Also, believe it or not, synthetic data gives you better code and functional coverage. How? Well, it’s easier than you think. You simply point your test data creation tool toward its data editing, enhancing and manipulation functions.

Oh, and yes, I nearly forgot about the most important point. More secure than data masking, you say?! Well, it is. This is because data creation tools never actually access or manipulate ‘live’ production data. They can, in fact, create data without data. Confusing? Most data masking tools anonymize your test and development data by moving live production data into a separate staging environment so it can then be masked. How is this secure? Well, it’s not really. Likewise, I bet you didn’t know that masked data can be reengineered back into its original format fairly easily. Synthetic data can never be reengineered because it’s not actually ‘real’ data.

So, why are you still using data masking? My guess is because you don’t know enough about data creation – start reading! It’s the way forward.