It should prove quite interesting as I’m not convinced that taking a copy of production data and using minimal masking techniques is quite as robust as their millions of customers imagine it to be.

In fact, if the average punter knew that copies of production data are used in development – often offshore – there would be an audible gasp of amazement. What? You have reassured us all with assurances about state-of-the-art security systems for live data only to let copies walk out the back door. And the reason why? Because they are only being used for development?

Well call me pernickety but that the simple issue of using a copy of live data is enough to make me sit up my keyboard and write me a letter. I’ll keep you posted with what I find out.

Not good by most measures but the real shock comes with the realisation that something as simple (cough) as data testing and development is a massive green no-no.

The standard practice of using copies of production data in testing and development can mean that many organisations are apparently making 24 copies of the primary databases annually with some even noting that demands have meant that up to 120 copies are made each year.

It can’t be a surprise then to learn that copies are a massive drain on power, cooling and storage.

If the size of the production database is 500 GB then ten non-production copies will weigh in at 5 TB. That’s big, scary and unwieldy, hey, just like the now-dropped-from-production Humvee…

I’m guessing that the demand for the ‘cooler hybrid options’ of the testing and development world will grow and that means more attention should be given to the brave new world of synthetic data generation.

A combination of good old human curiosity will generally find a way. For most complex systems there is so much information that finding the intersection of a few data points will usually get you to the data you need. If you look at pretty much any HR or Health care system there are so many data points that the complexity of trying to second guess human curiosity is mind boggling. Changing a name and address is not enough!

The only safe way is to generate the data based on the characteristics of production, not the actual production data!

I thought about that baffling wisdom during a conversation about the use of production data in testing and development. If you were to ask why copies are used, what answers do you think you‘ll hear?

In the main, I’m guessing it will be because that’s the way it has always been done. Sure, but dig further and underpinning the ‘why’ is belief that it is the best way to ensure quality in systems testing. So the challenge comes when you’re told that it simply isn’t true.

Yes, production data is just the starting point and manual methods are then used to edit and extract relevant data but do conventional methods meet project objectives? Put aside for a second the need to mask sensitive live data and look again at the issue of quality.

Undoubtedly, quality data is the key to success but a copy of production data does not guarantee that – all it guarantees is high volume.

Manual techniques can enhance test data but not to any significant degree. Even automation tools such as QTP and LoadRunner improve richness but only to a certain extent and the risk is that defects and bugs remain undetected.

So working with the ‘if I were you, I wouldn’t start from here’ logic, projects should start with low volume data that offers a rich combination of scenarios.

And what is the quickest, most cost effective and timely way to achieve that? With software that is capable of creating data – (no more fears over live data leaks) – and that generates a richer coverage of characteristics that will deliver the functionality that you and your team have been tasked with. True or false?

The Welsh Assembly Government’s e-Crime Wales is a partnership of organisations, agencies and the police – that it has dedicated police business liaison officers is thought to be a world’s first.

Data loss and security breaches are a growing problem for businesses everywhere and Detective Constable John Cherry recently confirmed something most organisations are aware of when he said: “I have found that 70 per cent of threats come from within companies, either through malicious abuse of data or simple employee ignorance of existing threats.”

A Computer Security, Issues, & Trends report placed the risk of security breaches from employee and former employees even higher, at 81 per cent.

But when government gives with one hand it can certainly take with the other and data protection issues are ever pressing (no matter that government departments have breached their own DPA principles).

When the Nationwide Building Society was fined £980,000 by the FSA for failing to manage information security back in 2007, everyone sat up and took notice.

Now the UK Information Commissioner has made it clear that companies found wanting can be hit by ‘unlimited fines’ and that it is down to the ‘data controller to comply with the data protection principles’, day-to-day demands on data use are brought into sharp relief.

No matter the security polices that are drafted, unless operational integrity is in place, good intentions will come unstuck. And when it comes to testing and development, testing on copies of production data contains unavoidable risks.

Discussions have recently centered on using representative or “fake” data for testing and development. No, there is no other secure way – not even data obfuscation. Seeing as we’re now hearing that masking algorithms can easily be re-engineered (read: http://www.guardian.co.uk/technology/2010/jan/24/computer-security-crime-anonymous-datasets) the time is now to get on the train.

Even if you set aside the advantages of the time and space saved, synthetic data is the most secure and completely compliant – it seems the case for producing synthetic data is copper-bottomed.

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.

Well, unfortunately most data centers are starting to read the writing on the wall and beginning to discourage just copying data from production system to test system to QA system to who knows where. Data centers are now implementing one of two types of methods, masking data or creating synthetic data, to help secure sensitive information in transit to these secondary systems. But how secure are either of these two methods? Is one better than the other?

Data masking is very easy to understand and involves the obscuring of specific pieces of information—ensuring that sensitive information is replaced with realistic data but data that doesn’t identify the data it has replaced. So if John Doe had a SSN, with data masking, we would replace his SSN with another SSN that obviously could not be traced or reverse engineered to get back at John Doe’s original SSN. But how secure is this method of masking data? There are two very typical scenarios which include:

• The inability to understand what needs to be masked. Let’s face it databases are complex, the information is often obscure, and it takes years to master the schemas of these systems. Unfortunately many database systems are being managed by teams that do not fully understand the data. This leaves their ability to mask all the sensitive data that databases contain to nothing more than a shot in the dark—creating a scenario where sensitive information is copied throughout the enterprise and leaving a gaping security hole
• The inability to use a masking tool effectively. Call this operator error but many times the copy mechanism is performed before masking takes place either without knowing or to be masked on the target system. The fact of the matter is that under both scenarios sensitive information has left the production system, has traveled through the network, and landed on an unsecure system. Again, leaving sensitive data vulnerable as it travels on the network and for a time when not masked on the target system.

Synthetic Data Generation on the other hand is a process of creating real data but through a detailed process of data anonymization, that is the creation of data that has no real identity. The most important aspect of synthetic data generation is that because it doesn’t strictly rely on production data, rules or conditions can be met to generate data that is able to test certain aspects of an application or system that normal production data might not be able to. How secure is synthetic data generation?

• Clearly, synthetic data generation is the ultimate in protecting the privacy of real production data. No longer are test systems tied to production data and no longer is production data flying through the enterprise unsecured.

I enjoy some banter on this subject as for me it would seem that synthetic data generation is the most secure method of providing test data throughout the enterprise. I can see how many would be thrown back by what would seem to be a very complex initiative. But when using tools such as Datamaker from Grid-Tools I see this aversion to creating test data being reduced. Plus, with the added value of ensuring representative data is always available for testing, synthetic data generation can be extremely beneficial in providing data that goes far beyond just raw production data while encompassing relationship, properties, and nuances of data not normally seen in production.

Anyone who has had to test applications clearly understands that proper application design and functional testing is directly related to the availability of a representative dataset. Let’s face it, we all know that testing applications is vitally important but we often neglect performing any extensive testing because it is considered to be too difficult and time consuming to find, message, or generate any decent test data. Likewise, both application and database performance testing is often inadequate—inhibiting the ability intelligently modify database structures to approximate database performance for application usage.

It would seem to most that using real-world data would be the best for performing application and database performance testing. Unfortunately real-world data is not always available, may be hard to acquire, doesn’t exist in sufficient quantity, or doesn’t have or is missing important properties (PKs, FKs, etc.). For these reasons, synthetic data generation is a viable alternative that helps ensure representative data is always available for testing. Synthetic data generation can be extremely beneficial in that it can:

1. Data goes far beyond just raw data and encompasses relationships, properties, and nuances of data. It is this ability of a synthetic generation tool to build in these types of relationships that helps perform the fine-grain testing within applications.
2. With a complete and representative dataset, database parameters, queries, indexing strategies, table structures, etc. can be tested and modeled to help tune database performance.
3. Instead of using ‘caned’ data, it is much easier to model and introduce outlying data and ask important questions as to how an application might behave.
4. It is much easier to create standardized benchmarking datasets that can be reused as application or database design changes.

Objects and object-oriented design has become main-stream within many data centers. Compiling attributes into object entities and modeling interacting objects is almost second nature. Grid-Tools has brought the concept of objects to synthetic data generation—enabling users of their Datamaker tool to assemble data objects together for the generation of test data. For instance an application that requires data representative of an order system might link together separate objects that represent internet, phone, or walk-in orders; each type of order object containing fixed or variable attributes that uniquely define the object.

The specification of a data objects ensures the representation of data that includes, but not limited to, fixed and variable data, inheritance by other objects, have a defined structure, have attributes, can relate to external data, can contain expected results, and can contain test coverage data. Data objects is what drives the power of Grid-Tools Datamaker to generate a rich and meaningful spread of data that will be representative of the application intended to be tested—guaranteeing maximum coverage of a code base.