One of the things that I have noticed is that a lot of companies use production data for testing. They usually justify this by saying that some use cases can only be reproduced by using production data. PCI-DSS requires that production data is scrubbed or sanitized before being used for testing purposes. The Ponemon Institute has come out with some interesting (and scary) data on data security during development and testing.
This report is of interest since it brings up compliance issues as well as insider attack threats. Segregation of duties is a very important thing and one of the things that most organizations have is to separate the production environment from the development, testing and QA environments.
The data was obtained in a survey and US businesses and the first data point is that 80% of US companies and 77% of UK companies use production data for testing. That is huge, even considering that this was a survey and and the data is skewed a little by some organizations not responding, etc.
As you can see, compromises involving any of the types of data listed here can have serious consequences.
But, now comes the scary part. 70% of UK companies and 67% of US companies responded that they did not mask data. 70% of UK companies and 71% of US companies responded that they did not reduce (or scrub) data.
These companies may have separate environments, but production data is now in development or testing environments. Instead of the data residing in tightly controlled environments with access restricted to a small group of people, the number of people who have access to production data grows exponentially. There is a lot more chance that the data may be compromised. Insiders who have access to the data may be tempted to sell it for profit. As an aside, a new study found that the cost of 1 US credit card record was $2 and that of a German card was $4.
Another thing that comes up in the report is that fact that the data is shared with 3rd party solution providers or out-sourced development/testing teams. This is a big problem if the data is not scrubbed or masked. this is compounded by the fact that some these out-sourced services/solution providers may be in different countries with different laws.
The most prominent cause of data compromises was due to insiders, negligent or malicious. External attacks were responsible for a small (but still significant) portion of the compromises. What takes the cake here is that almost 9% of UK companies and 26% of US companies did not know how the compromises happened.
Some of the things that you should be doing:
- Have policies and procedures in place. This is easier said than done. But you will have to start somewhere sometime.
- Make all your employees (dev, QA, managers, support personnel, and others) aware of the policies and procedures.
- If it is at all possible to not use production data, take that option. You will need to spend time to come up with alternate ways of testing scenarios.
- Always ensure that production data is masked or scrubbed when it is moved out of the production environment.Not doing so can severely impact compliance and result in huge financial and reputation losses in the event of a breach.
- Additional safeguards would be to ensure access to this data is restricted and the data is destroyed once the testing is over.
Download full report
Data Security in Development and Testing
PS: If you have looked at the full report, you will already know, but just in case, the graphs above are from the report.