The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well.
[email protected] (Phil Smith) writes: > 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". PCI security rules may require reinforcements; Critics carp that the standard isn't protecting credit and debit card data http://www.networkworld.com/news/2009/041309-pci-security-rules-may-require.html from above: Created by Visa and other credit card companies, the PCI rules will have been in effect for four years as of June 30. But with breaches of card data continuing and questions about the standard's effectiveness on the rise, PCI DSS is showing signs of coming apart at the seams. ... snip ... recent PCI thread/news: http://www.garlic.com/~lynn/2009d.html#69 PCI Compliance http://www.garlic.com/~lynn/2009f.html#3 Cybersecurity hearing highlights inadequacy of PCI DSS http://www.garlic.com/~lynn/2009f.html#16 Cybersecurity hearing highlights inadequacy of PCI DSS We had been called in to consult with small client/server startup that wanted to do payment transactions on their server ... they had also invented this technology called SSL they wanted to use. The result is now frequently called electronic commerce. Somewhat as a result, in the mid-90s, we were asked to participate in the x9a10 financial standard working group that had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. This involved doing detailed, end-to-end threat & vulnerability studies of the different mechanisms & kinds of retail payments (POS, attended, unattended, internet, transit turnstyle, magstripe, contact, contactless, debit, credit, gift card, stored value, ACH, etc, i.e. *ALL*). The result was the x9.59 financial transaction standard ... some reference http://www.garlic.com/~lynn/x959.html#x959 One of the big threats/vulnerabilities was transaction information being harvested (skimming, phishing, evesdropping, data breaches) by crooks (&/or insiders) for the purpose of fraudulent transactions. X9.59 addressed this problem, not by attempting to prevent such activity ... but slightly tweaking the paradigm and making the information useless to crooks for purposes of fraudulent transactions. In much of the current infrastructure, knowing the account number is sufficient for a crook to perform a fraudulent transaction. We've tried using a number of metaphors to describe the current infrastructure (fixed by x9.59): * dual-use vulnerability metaphor account number is required in a large number of different business processes and is required to be readily available. at the same time the account number has to be kept strictly confidential and never divulged to anybody (not even those needing it for business processes, since insiders have repeatedly been shown to be the major source of identity theft). we've claimed that even if the planet was buried under miles of information hiding encryption, that it wouldn't be sufficient to prevent information leakage. * security proportional to risk metaphor to the merchant, knowledge of the account number is worth some percent of the profit off the transaction (possibly only a dollar or tow); for a processor the knowledge from the transaction may be worth only a few cents; that same knowledge for the crook, is worth the account balance/credit-limit. as a result, the crook may be able to outspend by a factor of 100 times attacking the system (as the merchant can afford to spend protecting the system). * naked transaction metaphor lots of archived blog activity & posts related to naked transaction metaphor http://www.garlic.com/~lynn/subintegrity.html#payments .... One of the issues is that the earlier work we did for electronic commerce, uses SSL for hiding financial transaction information ... which appears to the largest use of SSL on the web today. X9.59 eliminates the need for hiding that information (as countermeasure to fraudulent transactions) and therefor eliminates the major use of SSL as an aside ... we were orthogonally involved in the cal. state breach notification legislation. we had been brought in to help word-smith the cal. electronic signature legislation and some of the other parties were involved in privacy issues. there had been detailed, in-depth consumer privacy surveys ... which found the number one issue to be identity theft, and a major form of identity theft involved information from data breaches being used for fraudulent transactions ... and at the time, there seemed to be little or nothing being done about data breaches. it apparently was hoped if the information was made public ... then there might be some stuff done about it. -- 40+yrs virtualization experience (since Jan68), online at home since Mar70 ---------------------------------------------------------------------- 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
