See below
Robert Galambos CIPP/C CIPP/IT Compuware Senior Technical Specialist IBM Certified Database Associate IBM Certified DB2 9 for z/OS Database Administration Certified Information Privacy Professional/Canada Certified Information Privacy Professional/Information Technology [email protected] Tel: +1 905 886 7000 Toll Free: +1 800 263 7189 Fax: +1 905 886 7023 Quebec: +1 877-281-1888 Le contenu de ce courriel s'adresse au destinataire seulement. Il contient de l'information pouvant être confidentielle. Vous ne devez ni le copier ni l'utiliser ni le divulguer à qui que ce soit à moins que vous soyez le destinataire ou une personne désignée autorisée. Si vous le receviez par erreur, veuillez nous aviser immédiatement et le détruire. The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. "Service in every product... Les renseignements contenus dans le présent message électronique sont confidentiels et concernent exclusivement le(s) destinataire(s) désigné(s). Il est strictement interdit de distribuer ou de copier ce message. Si vous avez reçu ce message par erreur, veuillez répondre par courriel à l'expéditeur et effacer ou détruire toutes les copies du présent message. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Farley, Peter x23353 Sent: April 22, 2009 10:39 AM To: [email protected] Subject: Re: Data masking/data disguise Primer 1) WHY > -----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. TRUE BUT THAT IS NOT THE MAJORITY OF ISSUES > 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. TRUE. THEN YOU CAN SUE A TECHNIQUE OF SCRAMBLING THE DATA. IN OTHER WORDS TAKING THE ADDRESS FROM PERSON A AND MOVE IT TO PERSON B AND VIS A VERSA >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. TRUE. BUT DUE DILIGENCE IS REQUIRED. NOT DOING ANYTHING IS NOT A SOLUTION >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. NO ARUGMENT. ALL I AM SAYING IS THAT SCRUBBING PII SO THAT YOUR NEIGHBOR ON YOUR CUBE WON'T ACCEDENTLY SEE YOU HEALTH RECOIRD WHEN TESTING USING REAL DATA. HE WILL ONLY SEE 'KERMIT THE FROG' DATA WITHOUT KNOWING WHO KERMIT IS IN REAL LIFE <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? NOT TRUE. DUROING 'NORMAL' TESTING DEBUGGING THERE IS NO NEED FOR REAL DATA WHEN THE PROBLEM IS NOT INVLVOED WITH PII. (AS YOU MENTIONED SORTING AND MAYBE ZIP CODE BUT THAT TO CAN BE ADDRESSED) OTHER THEN THAT A DEBUGGER DOES NEED TO SEE/USE RECORDS WITH PII. EXCEPTION CAN ALWAYS BE ADDRESSED >I'm willing to be shown that practical and timely solutions exist, but I >haven't seen any yet. GIVE ME A CALL IF YOU WANT 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 ---------------------------------------------------------------------- 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
