> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Phil Smith > Sent: Tuesday, April 21, 2009 7:51 PM > To: [email protected] > Subject: Re: Data masking/data disguise Primer 1) WHY > > Why can't you debug a production issue, if you're using Format-Preserving > Encryption? Does the application need the "real" data? Most do not. Or I'm > not understanding your point.
Many business processes *do* require the "real" data. Format preservation does not help when sort order is affected. When a business needs to determine a 9-digit zip code from the customer address, format preservation will not do -- the program needs the real street number and address and the real city and state or it gets the wrong zip code. Neither the customer nor the USPS appreciate or long tolerate incorrect zip codes. And once the zip code is determined it must be the "real" zip code that is sorted, or the USPS gets very upset, which will cost the company more money. My point is that when debugging a production issue with such a process, real customer data is going to be exposed somewhere no matter how much money or CPU time is spent trying to hide it. There are many, many such business processes. They will not be debuggable without real production data. Q.E.D. I am not saying don't mask at all, just that no one should expect data masking to be a complete protection against fraud and theft. It can and will happen anyway wherever there are clever people with a need for money that they can't get legitimately. I do not mean that CICS transactions and batch reports should not mask private data sent to 3270 screens or their HTML/SOAP equivalents. Indeed, I do not want my private data being shown to anyone unless they have a real need to see it and I have authorized them to do so. I am saying that prohibitions against programmers using real production data will prevent production problems from being resolved, and that no one should be surprised at this. <Snipped> > -- far more dangerous > is the rogue DBA who decides that a private copy of the database would be > fun to put on a USB drive. Indeed, that one is the far more dangerous threat. No argument. > To be blunt, whether you agree with masking or not, the regulations in > place and coming WILL NOT allow you to use copies of production data for > test. Sure, having honest folks is the norm and A Good Thing, but the > regulations don't assume that you've reached that Nirvana. Nor should > they. I have yet to see a *practical* plan or software architecture that would satisfy the application programmer's needs for both realistic data and large volumes of it. Particularly in larger organizations where the sysprogs and storage admins and DBA's are all independent groups with different managements and goals than the applications programmers, the data that is needed will seldom be there when it is needed, for either testing or problem resolution. I see no other choice than to continue permitting application programmers the use of production data, perhaps with field-level encryption and decryption for privacy purposes. Regardless, the dumps and debugging will reveal the data anyway, so where is the protection then? I'm willing to be shown that practical and timely solutions exist, but I haven't seen any yet. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
