we were somewhat involved in (original) cal. data breach notification act ... having been brought in to help wordsmith the electronic signature act and several of the players were heavily involved in privacy ... and had done in depth public surveys and #1 was fraudulent financial transactions somewhat as the result of various kinds of breaches (before notification each member of public thot it was isolated incident affecting only them). Problem was that little or nothing was being done about the breaches and it was hoped that publicity from the notifications might prompt corrective action. The issue is that entities normally take security measures in self interest/protection. In the case of breaches, it wasn't the institutions that are risk, but the public. Since then there has been a dozen or so federal bills proposed about evenly divided between those similar to the cal. state act and those that effectively negate need for notification (in some cases, specifying a combination of information compromised that would essentially never occur).
We had aksi been brought in as consultants into 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 for having done "electronic commerce", we get brought in to the X9A10 financial standard working group that had been given the requirement to preserve the integrity of finanical infrastructure for *ALL* retail payments. We did detailed end-to-end vulnerability and exploit studies of various kinds of payments and eventually wrote a standard that slightly changes the current paradigm ... and eliminates the ability of crooks to use information from previous transactions, records and/or account numbers to perform fraudulent transaction. As a result it is no longer necessary to hide/encrypt such information ... either in transit and/or at rest (somewhat negating the earlier work with SSL for electronic commerce). dual-use metaphor; transaction account number is used for business processes and must be readily available for scores of business processes and millions of locations around the planet. at the same time it is used for authentication&authorization and therefor must *NEVER* be divulged. The conflicting requirements has resulted in us observing that even if the planet was buried under miles of information hiding encryption, it still wouldn't stop information leakage security proportional to risk metaphor; value of transaction information to merchant is profit from the transaction ... possibly a couple of dollars (and value to infrastructure operators a few cents) while the value of the information to the crooks is the account balance and/or credit limit. As a result, the crooks may be able to outspend attacking the system by a factor of 100 times what the defenders can afford to spend. Part of the issue now is there are lot of stakeholders with vested interest in the unchanged paradigm. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
