On 21 Apr 2009 09:28:35 -0700, in bit.listserv.ibm-main you wrote: >I have noticed a couple of questions in the last couple of months >concerning issues along the lines of data disguise/data masking/data >obfuscation (a lot of different words for the same issue Protecting PII >(personal identifiable information)) from being 'released' > >My plan, unless there is a backlash, is to create a series of threads >discussing the issues, provide some 'interesting' studies, some >resources available to IT professionals etc. > >The first in the series is WHY. > >This maybe one of the easiest and hardest subjects to deal with. Easy >because in most case people have seen what happens when production data >gets 'out'. Those who have read the newspaper reports of MAJOR companies >being embarrassed in the press (as well as sued, loss of customers, etc) >because of data breaches. A study of the Ponemon Institute sates the >average cost per lost customer record was $197 U.S. in 2007. Now >multiply that by 10,000 customer records... 'Loss of face'/confidence >of the customer etc. it adds up. > >The hard part is the same as the above. That is convincing management >that there is a issue in the first place. Typical responses are (and >this may or may not be relevant to your organisation) is 'we have non >disclose agreements', 'our files are secured by, RACF, TOP SECREAT, >WINDOWS AUTHICATION, ACF2, etc. While these types of security are >important, they do not solve the whole issue. > >Example, > >Application require 'good' quality of test data for QA/user >acceptance/system testing. Right now the QA department/group/team copy >production data. The reasoning is that the quality of the production >data is the 'best' An QA analyst runs a report as part of his/her test >case senerio. The report is printed and after verified, thrown out in a >recycle/garbage bin. It lands up in a dumpster where someone finds >it.... >
It gets interesting when personally identifiable data is needed for validation of the routines. If there is a street address / postal code validation routine, the real addresses are needed. Various name matching and validation routines could need the real names. For these and other cases, the test / QA environments have to be guarded as closely as the production environment AND the people cleared on the need to know and reliability basis. All copies, hard and soft, have to be handled appropriately. Test data should have both weird but valid information and pathological information (the error routines must be validated so erroneous data is needed). One of the things that an organization must consider is whether it can adequately protect the information entrusted to it. It must understand the liabilities and consequences of delegating the handling of sensitive information to other organizations. It must understand the laws of all of the jurisdictions where that data can be accesses and updated. In short obfuscation can work for some things but not all. Responsible data handling is a core obligation for ALL organizations so delegation of any of the duties should be done carefully. All organizations will have to decide who they will trust and what safeguards are both needed and viable. >Another example > >A customer service rep (CSR) who is responsible to access clients who's >last name starts with the letter 'A'. Given most security set ups, >she/he has access to the query application and has access to the entire >DB. She/he access clients through out the DB, which she sells their >info. How do you track/verify/prove/correct that? (Application auditing) > >And it goes on (note these are actual cases) > >And while this is not a direct concern to IT, there are legal >restriction/requirements concerning protection PII. Depending on where >your company operates certain safe guards/process/agreements needed to >be executed/observed. And since a lot of companies are operate in many >jurisdictions, there maybe may different laws that have to be observed, >even when there is no actual 'brick and mortar' building there. > >While I am sure many of you already 'get' this, the idea is to open a >discussion on the listserv so others, as well as ourselves, can see >other opinion on this matter > >While this subject id extensive, my idea is to just give everyone a >little taste of the 'WHY. > >PLEASE let me know if you are interested in reading more. Otherwise I >will stop. > > >THE VIEWS EXPRESSED WITHIN THIS EAMIL ARE MINE AND MINE ALONE. > > > >Robert Galambos CIPP/IT CIPP/C >IBM Certified Database Associate >IBM Certified DB2 9 for z/OS Database Administration >Certified Information Privacy Professional/Canada >Certified Information Privacy Professional/Information Technology > >Compuware Corp. Of Canada > > Service is our best product > > >Le contenu de ce courriel s'adresse au destinataire seulement. Il contient de >l'information pouvant etre confidentielle. Vous ne devez ni le copier ni >l'utiliser ni le divulguer a qui que ce soit a moins que vous soyez le >destinataire ou une personne designee autorisee. Si vous le receviez par >erreur, veuillez nous aviser immediatement et le detruire. > > >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. > >---------------------------------------------------------------------- >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
