- 7 Posts
- 411 Views
Protection of Confidential Data in test environments
Our company has multiple test environments that it uses for testing of new bundles and patches, tax updates, configuration changes, etc. These environments are copies of the production database.
How are other companies protecting the PII and other confidential information in the test environments. Data such as SSN, DOB and checking account numbers. Are you obfuscating those data fields or scrambling or encrypting the data?
Do you have any tools you are using to monitor activity in these non-production environments to monitor access or if someone has done a screen capture of the data on the personal data pages?
We use apply masking to PII in our non-production environments. It started with a particular vendor we worked with to do discovery. We were a bit overwhelmed at the time with the number of places we'd have to modify to use PET so for non-production we decided to use the same vendor to implement masking. Now that it is scripted it's easy to reapply after a refresh. You'll have to decide how far you can do legitimate testing with masked data. For us we have found we can leave masking for almost everything except for certain payroll testing we do.
We are masking our non-production PII simply by using SQL scripts when the refresh occurs. Note that there are many different field names that contain the same PII throughout the system, we used PSRECFIELD and knowledge of the tables to find them all. If we need to test an interface that requires actual PII; we just use DataMover to move the table in question back to our non-production enviornment and then when we are done with our tests we re-run our masking script or restore the masked data from a backup. Likewise if testing interfaces with real PII in a non-production environment, we pay special attention to the interface files; once done with an actual test that contains PII, we remove those interface files from the file system. Additionally, we have an audit of which queries contain those same fields we maksed and who has access to those queries, and perform an quarterly audit to ensure those folks with access should have that access.
We just implemented this last fall and so far it is really easy to manage. We had some folks that complained about the change as it was inconvenient, but after sharing some identity theft stories with them, and putting them in that situation, they seemed to change their mind! So change control was fairly simple too.
This feature has been available for quite some time
Betty, Another option to consider is the use of PeopleSoft Encryption Technology. This is part of PeopleTools and has been available for several releases now. PET allows customers to encrypt and decrypt PII, PCI and other sensitive data by using industry standard encryption algorithms such as PGP or RSA. This encryption is at the field level, so if you take SSN for example, you can encrypt the value of SSN in your Non-Production database by applying this algorithm each time you refresh from production. To decrypt these encrypted values for certain authorized users, you can use PeopleSoft Security and a small piece of PeopleCode. I have implemented this before for customers and while this is a lesser known and often overlooked utility in PeopleTools, I can tell you from expeirence that it works once it is setup correctly.
Betty, most of the PeopleSoft customers of which I am aware who are performing this sort of data masking are doing it through custom developed scripts which are executed on the target environment after refreshing from Production. Typically, these efforts include the fields you mention at a minimum. Extending beyond that is dependent on the amount of time and effort you and your technical team are willing to invest. Some customers have developed fairly sophisticated data masking and subsetting routines, but this requires a lot of effort upfront and must be reevaluated with every update which may impact the data model. Of course, you could also invest in Oracle's Data Masking and Subsetting tool set but, sadly, Oracle does not deliver templates for PeopleSoft with this tool so you would also have to develop those on your own. I hope that this is helpful to you.