[EMAIL PROTECTED] wrote: > Also remember that we now, unfortunately, have to protect data from > possible internal threats as well. I read of one recent event where an > ex-employee was attempting to extort money from his old employer by holding > backup tapes with data on them and threatening to let it all go on the > internet. So building your encryption systems such that the keys are > either hidden from or split amongst multiple employees is important.
for a long time, insiders have been considered the major source of fraud. in the early 80s, sytems were evolving that required more than one person for performing an operation ... and one of the constant issues then involved countermeasures for collusion involving multiple authorized parties. the internet has somewhat defocused attention from the major source of fraud (insiders) with the possibility that attacks might have originated by outsiders. however, within the last two years or so, there was a study published finding at least 70percent of the data breache incidents (around identity theft) involved insiders. misc. collected posts on subject of fraud, risks, vulnerabilities, etc http://www.garlic.com/~lynn/subpubkey.html#fraud one of the issues that we faced in x9a10 working group ... that had been given the requirement to preserve integrity of the financial infrastructure for all retail transactions ... was how to address the issue. one of the major issues with retail transactions is the account number leakage resulting in fraudulent transactions http://www.garlic.com/~lynn/subpubkey.html#harvest the work on the original payment gateway for e-commerce involved hiding account number transactions during transit on the internet using SSL http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 however, it was recognized that account numbers were required to be available (and therefor exposed) in a sizeable number of business processes (not just the original transaction). the conclusion was soemwhat that even if you buried the planet under miles of cryptography, it still wouldn't prevent account number leakage. the resulting x9a10 standard work for x9.59 transactions http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#x959 resulted in following standard specification: 1) x9.59 transactions are strongly authenticated (using dynamic data) 2) information (including account number) used in x9.59 transactions could not be used in non-authenticated, non-x9.59 transactions. a major threat in payment card retail transactions has been the account numbere leakage/harvesting and then using the information in a form of replay attack (using the same information to perform a fraudulent transaction). the replay attack vulnerability effectively forces the account number into being treated as a form of shared-secret (if it is known than it is possible to perform a fraudulent operation, akin to stealing passwords). the x9.59 standard includes replay attack countermeasure ... none of the information from an x9.59 transactions can be harvested and then turned around to be used in fraudulent transaction. this eliminates knowledge of the account number as a vulnerability. evesdropping, data breaches, and/or havesting attacks involving (x9.59) account numbers no longer result in fraudulent transactions. this in turn gets back to the assertion about non-x9.59 account transactions, that even burying the world under miles of crypto is not sufficient to prevent account number leakage ... in part because of the large number of different business processes requiring the account number (as well as the insider vulnerability issue). ---------------------------------------------------------------------- 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
