Not a problem. Discussion is what this is about. BUT the only item I can dis-agree with you is when you state that
'Heartland: 100M records breached; claimed cost per record: $200 -- that's clearly hyperbole, but 100M times *anything* realistic is still a ton o' money' It isn't Hyperbole..... According to studies, which I mention at least one, the average cost is about $197 USD and that was in 2007. If you consider ALL cost (which can include lost of sales, legal costs, cost to 'maintain the customer base', cost for credit monitoring (if applicable), 'SPPINING' (no reference to fox news <S>), losing business focus, soft costs etc) it can be even much higher. As you noted there are a lot of reasons for data breaches and here are some additional info for those who want to know 39% of breaches are from employees (non-malicious) 16% Hacker external 30% employees (malicious) 15% other So everyone out there reading this, make sure your company's name (bottom line) isn't on the front page of NYT, Globe and Mail, The Financial Times, etc. because of a breach. Any other thoughts? 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 Phil Smith Sent: April 21, 2009 1:39 PM To: [email protected] Subject: Re: Data masking/data disguise Primer 1) WHY I'm interested. Of course, we sell a product in that arena. I'd distinguish between data disguise/data masking/data obfuscation and encryption. Encryption is for production data -- so that when a backup tape falls off the truck, its contents aren't useful for someone who finds it. Encryption can vary from all data (typically but not necessarily hardware-based) to column-based. Data disguise/data masking/data obfuscation (henceforth just "masking") is for test data, to allow use of realistic data from production without risking leakage due to any of human error, weaker security on test systems than production, or malfeasance by staff (yeah, it happens). This might seem like an insignificant distinction--and indeed, they may (or may not) use the same underlying technology--but they're quite different usages, in that production encryption demands tend to be random and selective (within applications, or at most report generators), whereas masking tends to be "OK, we need to generate 10M rows of test data *now*". Clearly you can create an application to do the latter, using the production encryption technology, but as a vendor, we should (and do) provide tools to make that easy. Management who isn't interested hasn't read the news (Heartland: 100M records breached; claimed cost per record: $200 -- that's clearly hyperbole, but 100M times *anything* realistic is still a ton o' money); management who says "we have non-disclosure agreements (and therefore our data is impregnable)" are, of course, laughably incompetent. Anyone whose management says such things would be well-advised to keep hardcopies of the notes suggesting that there is an issue, and their responses, so that if and when a breach occurs, you can say "Don't look at me" if they try to. That still may not work, but it's worth a try. As you note, the law is catching up here. NDAs aren't sufficient for the new regulations; it's time to get on board and at least start planning for encryption. At worst you'll learn a few things; at best you'll avoid a breach. And in the middle, if a breach occurs, you'll be Johnny-on-the-spot with domain expertise to help clean up and avoid another one. I'm not sure I've added much to what you wrote, Robert, but those are some of MY thoughts! -- ...phsiii Phil Smith III [email protected] Voltage Security, Inc. www.voltage.com (703) 476-4511 (home office) (703) 568-6662 (cell) -----Original Message----- From: Galambos, Robert <[email protected]> Date: Tue, Apr 21, 2009 at 12:06 PM Subject: [IBM-MAIN] Data masking/data disguise Primer 1) WHY To: [email protected] 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.... 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. ---------------------------------------------------------------------- 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
