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
