Our website uses cookies so we can analyse our site usage and give you the best experience. Click "Accept" if you’re happy with this, or click "More" for information about cookies on our site, how to opt out, and how to disable cookies altogether.
We respect your Do Not Track preference.
Sometimes it seems a good idea to use real production data in a test environment. But doing so means security becomes even more important if you want to stop things going wrong.
When testing a new system, it is always tempting to use a copy of real data from your existing system. The data is readily available, it has the variety of records needed, and it exists in a volume large enough to make it convenient for testing.
But in Britain last month, the parenting retailer Kiddicare admitted the personal information of 794,000 people had been exposed on a version of its website set up for testing purposes and the incident has underlined the dangers of using real personal information.
The Kiddicare breach came to light after some customers reported receiving text messages that appeared to come from a subsidiary website of Kiddicare.com. A security company found the mobile phone numbers had come from a dataset used on a test website in November 2015. The messages invited Kiddicare customers to take an online survey - a tool often used by scammers to cheat people into signing up for fake schemes.
Close to home, we know of two other data breach ‘near misses’ which are examples of how using real data for testing a new system or website can be a risky thing to do.
In both cases, software developers took copies of their client organisations’ data back to their own offices to use for testing. In one case, the software developer’s own system was hacked and the organisation’s data could have been exposed. In the other, the developer forgot to delete the data before uploading the software they had written (and the data!) to a public website.
Fortunately, neither of these incidents resulted in the sort of harm that flowed from the Kiddicare breach.
For this reason, it’s usually much safer to generate fake data for testing purposes – just in case. The best practice for software testers is always to mask or transform the data in some way so that personal information cannot be exposed inappropriately and accidentally.
We regularly get data breach notifications and this year we will be sharing the lessons learned from these more regularly. If you want to know more about data breaches, please check out our Data Safety Toolkit.
Image credit: Test road sign - Creative Commons via Pixabay
Back