[email protected] (Darth Keller) writes: > Quote: "gushed out of its (Target's)mainframes." > > Is the author really implying this was a mainframe hack? Really? > > Keep in mind that this is what the CEO's, CIO's, etc. will read.
somewhat because having been involved in doing "electronic commerce" with small client/server startup that had invented SSL ... in the mid-90s was 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. the resulting standard was x9.59 ... some references http://www.garilc.com/~lynn/x959.html#x959 x9.59 did nothing to eliminate breaches, but did slightly tweak the infrastructure and made the information from breaches useless to the bad guys (no longer able to use the information to do fraudulent financial infrastructure). the standard ran into some deployment difficulties because it eliminated fraud. merchants had been indoctrinated for decades that a major portion of interchange payments was heavy prorated surcharge based on fraud rates. Around 2000, x9.59 and some other "safe" payment products were pitched to internet online merchants (accounting for 70+% of online transactions) and saw high acceptance ... they were expecting 90% drop in interchange fees. Then cognitive dissonance set in, the financial institutions told them that instead of a 90% drop in fees, there would essentially be a surcharge on top of the highest fee they were already paying ... and the whole thing falls apart. One of the issues was payment fees were accounting for 40-60% of the bottom line of these institutions and a 90% drop would be a big hit. we were also tangentially involved in the cal. state data breach notification legislation (first in the country). we had been brought in to help wordsmith the cal. state electronic signature act ... some posts http://www.garlic.com/~lynn/subpubkey.html#signature and many of the participants were heavily involved in privacy issues ... and had done detailed, in-depth public surveys. The #1 issue was identify fraud, primarily the kind that results in fraudulent financial transactions as a result of breaches. There was little or nothing being done about it ... and it was hoped that the resulting publicity from breach notification might prompt corrective action. The issue is that security measures are normally taken for self-protection ... the problem with breaches is that the institutions aren't at risk ... it is the public. we've also pointed out several issues with the current paradigm ... a couple metaphors: dual-use ... since information from previous transactions can be used for fraudulent transactions, that information has to be kept totally confidential and never divulged. at the same time the same information is required in dozens of business processes at millions of locations around the world. we've periodically commented that even if the planet was buried under miles of information hiding encryption, it still wouldn't stop leakage security proportional to risk ... the value of the transaction information to the merchants is the profit on the transactions, which can be a couple dollars (and a couple cents for the transaction processor) ... the value of the information to the crooks is the account balance and/or credit limit ... as a result the crooks can afford to outspend the defender/merchants by a factor of 100 times. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
