I'll jump in on this with a couple of thoughts from the application programmer's standpoint.
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. And when interactive debugging is used to resolve the production issue (as is the "norm" these days), the plain-text values are right there for the programmer to see and use -- or abuse. Not to mention that the unmasked values may also be right there in the dump, for those who can read it. If a production issue cannot be solved without the real offending data, then enforced global "masking" prevents problems from being solved. That is obviously not acceptable to either the programmer or to management. Also, adding the CPU overhead for "demasking" calls to already strained CPU resources is going to cost the company large money, mainly in added software costs for added MSU's to cover the "demasking" CPU usage. Is that added MSU software cost greater than the *potential* cost of a breach? Maybe, maybe not. Especially when executive pay and perceived "shareholder value" is tied to increasing profit by reducing "overhead" like software MSU costs. Cost/benefit analysis is not always carries out by perfectly rational people. And to take one of your own examples, the customer service agent for the bank has an absolute need to see your very private information because that's the exact information you are calling to ask about, and which they must, by law, verify your identity against. How can "masking" help prevent employee abuse in that case? In my view, it cannot. Other protocols are needed to protect against abuse in such cases, not least among them serious audit and review capabilities, including key-loggers and screen loggers and whatever other sorts of monitoring software as can catch abuse for such sensitive work. In the end, making sure your employees are honest (programmers and service agents alike) and supporting them when they need it will be the best solution to preventing breaches, IMHO. Encrypting things that can be stolen or lost (tapes, hard drives, etc.) does make sense to me, but masking on the mainframe just doesn't make sense to me for too many real-world scenarios. Peter > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Galambos, Robert > Sent: Tuesday, April 21, 2009 4:02 PM > To: [email protected] > Subject: Re: Data masking/data disguise Primer 1) WHY > > 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? 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
