Pete Finnigan's Oracle Security Forum (http://www.petefinnigan.com/forum/yabb/YaBB.cgi)
Oracle Security >> Oracle Security >> How do I protect production data in a test/dev env
(Message started by: Pete Finnigan on Sep 3rd, 2005, 5:13pm)

Title: How do I protect production data in a test/dev env
Post by Pete Finnigan on Sep 3rd, 2005, 5:13pm
We have an environment where we are constantly having to do the following to our production data:

1. Copy and insert it into our test/development environment for our developers to troubleshoot a production issue, and

2. Send a copy of our entire production database to  our vendor so that they can upload it to their database instance and reproduce the bug.

Obviously our data is very sensitive but it's equally important for us to fix show-stopper bugs for which the data needs to be sent to the vendor.

Are there any safeguards/measures that you all can suggest if we were to use production data in a test/dev environment.

Thank you in advance.

Title: Re: How do I protect production data in a test/dev
Post by Pete Finnigan on Sep 6th, 2005, 1:38am
"Obviously our data is very sensitive"

Part of the issue is, in which way is it sensitive.
If it is personal information about people, then your jurisdiction may have laws governing whether you can disclose it (eg to the app vendor).
That may 'just' be a matter of anonymising it (changing names/addresses/birth dates etc).
Obviously the quantity of data is important there. If it is a couple of thousand customers, it may not be a problem to rename them all to John Doe001 to John Doe99999.

One issue that is more important for the extract to test is that it is very important that data generated from the test environment (eg bills) does get used as if it were production. You do not want your 'real-life' customers billed by your testers.
You need to mangle credit card numbers, bank accounts, addresses (again)....

Title: Re: How do I protect production data in a test/dev
Post by Pete Finnigan on Sep 6th, 2005, 10:56pm
Hi,

This is a difficult problem to solve and is very dependant on a number of things. The first is legislation. If there are legislative issues with your data then you need to know about them and account for them. If legislation for instance protects Credit card numbers then you cannot simply copy them into test and dev databases or worse even to outside suppliers.

The second issue is not just legislation but the issue of whether morally you should be spreading the customers data around. Can you trust your software supplier to look after the data during or after fixing the bugs. What if they then pass your data on to another sub supplier so that some software component they have bought in can be tested?

The issues are endless and un-controllable IF you give them the real data.

Two options. Have test  databases with completely made up data and try and replicate the issues there. I have worked in software houses with complicated systems and this mathod has worked in a lot of cases. The reason it worked is that the software was well instrumented and we were able to get application traces from production databases without revealing the data or copying it. We could replicate the issue in test systems. Sometimes this does not work and that is where the applications trace helped as it was possible to see the flow of events in the production system without copying the data off site.

The other option is as suggested by Gary to mangle the data before its copied, if it must be copied. I have written routines to do this in the past.

The bottom line is try and find a way to not copy the data, if you have to copy it try and keep it internal to your organisation, if you cannot keep it internal then mange it.

cheers

Pete



Powered by YaBB 1 Gold - SP 1.4!
Forum software copyright © 2000-2004 Yet another Bulletin Board