First of I want to thank everyone who either has contributed, or at least read this thread. It makes for some eye opening, information gathering, networking opportunities for all.
Before I go on, as I stated my intension is a series of threads the first being this WHY. Watch for another either latter today or tomorrow (takes me some time to correct my own spelling etc <S>). So far I see this as a series of about 4 or five different takes on the same subject. Now for some additional 'notes' 1) For prod supp testing from peter. I don't believe anyone here is thinking that every field in every table/file needs to be masked. Only PII (personal identifiable information) and the vast majority of cases that type of info does NOT effect the business process (the only think I can think of that is not the case is if there is a sorting/reports/ on names/SIN/SCN/address etc. issue) most times debugging has to do with the business process (insurance rates, customer/client options etc) the data typically, when the personal information is 'scrubbed', can be used for debugging. Since the PII is no longer refers to a 'real person' that the offending record belongs to (and the main reason for data scrubbing) debugging can proceed. 2) Studies are about averages. While 20B for the heartland breach maybe a little much, I concede, it is more then 100m to client, 'for sure', of both hard and soft cost. If a list of publicly confirmed breaches please go to www.privacyrights.org/ar/ChronDataBreaches.htm 3) Total number of known data breaches is 260,211,123. as of April 20 2009. (see explanation of the above mentioned web site) 4) Laws. There are a huge number of laws through out the world containing some aspects of data privacy. Some very strong, other less so. In some countries/communities the laws are very explicit, a good example is the EU privacy directive, Canada's PIPEDA, and some US states individual laws, while in other areas far less so. Basically the various laws state (a very simplified generalization) you can only use the info for what it was intended for/given permission for. And you must protect it for disclosure (I know someone here will argue about my interpretation but it will work for this general discussion). A small partial list follows; United States Gramm-Leach-Bliley Act, Sarbanes-Oxley Act Various US State regulations and laws requiring notification European Union Personal Data Protection Directive, 1998 US Health Insurance Portability and Accountability Act (HIPAA) Australia Privacy Amendment Act of 2000 Japanese Personal Information Protection Law Canadian Personal Information Protection and Electronic Documents Act 5) PCI (Payment card industry). Not a law but a regulation from private industry consortium. Basically a global standard that effect any business, gov't that accepts credit card payments. Its regulation is to provide safeguard protection of PII. An example is 3rd section 6.3.4 that requires that real CC number NOT to be used for testing or development Feel free in contacting me for additional info. 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 Gerhard Postpischil Sent: April 21, 2009 10:03 PM To: [email protected] Subject: Re: Data masking/data disguise Primer 1) WHY Farley, Peter x23353 wrote: > Data masking may very well be needed to prevent the internal/employee > type of data breach (accidental or malicious). However, it poses the > very serious problem that debugging production issues with production > data cannot (AFAIK) be done with "masking" in place unless the > programs are calling a "demasking" subroutine for every > record/database row that they process. FSVO "cannot" - in the sixties a colleague of mine, Mike Guzik, worked at ADR on an NSA contract to write a sort for Stretch. While Mike is a good programmer, he wasn't perfect, and the sort occasionally failed. When it did, the security officer needed to concoct phony data that failed the same way, so they could allow the dump out of the computer room. While I wouldn't want the job, they did it without "demasking" any real data. Gerhard Postpischil Bradford, VT ---------------------------------------------------------------------- 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
