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.
Yes, there's overhead involved in encryption: Nothing is free. Would encryption have cost Heartland $20B? I doubt it. This is why encrypting everything isn't a good idea: massive overhead, breakage, and (with many modern storage subsystems) huge increases in storage requirements, as traditional encrypted data doesn't compress worth a darn. Even a modest, 1M-row table is worth $200M if you believe the studies. That'll pay for a lot of hardware and software, and even a body or two to implement it! And even if the estimate is high by an order of magnitude, $20M is still some decent coin. Also don't forget the intangible costs of a breach -- folks don't like companies who leak, either as customers or investors. Sure, there's pressure to do things on the cheap. And there's plenty of bad management who will decide to try to get away with it. Real management, of course, involves doing what's best in the long run, and ignoring PCI DSS (or GLBA, or Red Flag, or any of the others that may apply to your company) isn't part of that equation. Don't get me wrong: the objections you're stating are valid. That doesn't mean they're sufficient to allow companies to rationally say "Naw, we don't need to be compliant with the law because it's hard/unpalatable/not perfect". As for the CS rep, (s)he may indeed need to see at least *some* of the data, such as the last 4 digits of the SSN, or the address. But perhaps not my deposit history, unless I'm asking about that specifically. And those folks are already monitored and audited pretty closely; the rep who starts looking at everyone's deposit history will get noticed. In any case, these reps see only a relatively few records -- 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. 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. (Hey, Robert, this is a fun discussion you started! Thanks!) -----Original Message----- From: Farley, Peter x23353 <[email protected]> Date: Tue, Apr 21, 2009 at 5:27 PM Subject: Re: [IBM-MAIN] Data masking/data disguise Primer 1) WHY To: [email protected] 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. ---------------------------------------------------------------------- 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
