IF THERE IS NOTHING TO STEAL…
Making data masking an integral part of test data management just makes sense
In 2015, the first Canadian study of its kind, the “2015 Cost of Data Breach Study: Canada”, was released by the Ponemon Institute in Traverse City, MI.
The report found that the average cost per lost or stolen record was $250 and that just over half of the data breaches were a result of directed attacks. 21 Canadian companies, representing 11 different industry sectors, paid a cost of $5.32 million on average, with the largest cost component being lost business.
While there are many comprehensive and sophisticated security measures an organization can and may have to take to protect against directed or accidental data breaches, it remains a certainty that nobody can lose or steal what is not there.
Many organizations have embraced the use of copied production data for their software quality assurance. The virtues of this approach are well understood – the testing yields better results, more defects are found and more functionality is verified. It is also typically a lot more economical to copy and subset production data rather than tie down scores of people to manually create artificial data.
However, from a security standpoint, not every organization has the same tight governance of their non-production data and environments:
• Developers may have production data on local machines.
• Test data may be handed over to deployment teams for demo and training purposes.
• In large comprehensive IT environments, a significant number of test repositories can be deployed as there can be several sets of test environments strung together in test architectures, serving parallel projects that release at different times.
• Comprehensive test data may be required in varying volumes/subsets in assembly, integration, product, performance, automation, security, user acceptance and deployment test environments.
• There may not be a strict protocol for wiping data from these environments every time a test is completed and access to these environments may be more open.
• Indices of the test data may be circulated among a large group of users for management purposes.
In short, organizations can have a lot of test data deployed to a range of environments and users without necessarily having a lot of data security protocols in place. Such protocols can be cumbersome to operate and audit, tying up both time and personnel. In many cases, masking the data may be a better alternative as it essentially makes the copied production data useless as a target for directed attacks as well as reduces the impact of a data breach from this source.
There are several comprehensive data masking suites available on the market today already and some of them are even capable of producing artificial data automatically, for those test scenarios that require test data in volumes that the production systems may not hold at the time the copy is taken – for example data related to end-of-year/end-of-season.
Furthermore, it becomes relatively easier, after the data masking software is configured, to create new and updated test data repositories in targeted subset quantities, thereby saving storage space.
Progressive organizations can see this as an opportunity to QA and Risk Management to co-sponsor data masking as a solution to both test data needs as well as risk prevention and avoid a lot of alternate costs all at the same time.
Service Delivery Sr. Manager and in charge of the Testing Centre of Excellent at Indigena Solutions
Service Delivery Director at Indigena Solutions