Hal Merritt wrote: > Here is compelling evidence why auditors should *never* be permitted to > make security 'requirements'. Never. Only see that due diligence is > done.
in addition to working on x9.59 financial industry retail payment standard ... http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#x959 was recently one of the co-authors of the financial industry x9.99 privacy impact assesement (PIA) standard ... basically defining a standard for auditing infrastructure. part of the challenge was to define an assesement standard that could accomodate a variety of different jurisdictional regulatory and legislative requirements. Part of it was keeping in mind that possibility of promoting x9.99 to international/ISO standard ... so the breadth and range of regulatory and legislative differences wouldn't just involve US jurisdictions ... but might span the whole world. the other issue was to attempt to avoid having PIA standard becoming obsolute not only with multi-jurisdiction but also changes that might occur over time. we were asked to come in and do some work on the cal. state electronic signature legislation http://www.garlic.com/~lynn/subpubkey.html#signature and then later the fed. electronic signature legislation. one of the participating industry groups was also working on various privacy issues and had done a survey of the primary driving factors behind privacy regulation and legislation. they found one of the primary driving factors behind privacy regulation and legislation was id-theft. for some topic drift ... there has been an attempt to differentiate id-theft where a crook harvests account numbers and uses the information for fraudulent transactions against existing accounts ... from identification theft where somebody uses personal information for opening new accounts. the previously mentioned work on x9.59 was to use strong authentication and business rules to drastically reduce the vulnerability associated with account numbers. there is a security model called PAIN P - privacy (or confidentiality) A - authentication I - integrity N - non-repudiaton in the case of account fraud, frequently knowledge from a previous transaction is sufficient to enable a future fraudulent transaction. This can somewhat be viewed as a from of replay attack. Account numbers effectively then have to be treated as a form of secret or password http://www.garlic.com/~lynn/subpubkey.html#secret a lot of attention has been focused on using privacy (hiding and/or encryption) as a countermeasure to account fraud ... by attempting to drastically limit means for obtaining knowledge of account numbers. the x9a10 standards work observed that the account number is needed in so many business processes that it practically impossible to prevent account number information leakage. http://www.garlic.com/~lynn/subpubkey.html#harvest as a result, the x9.59 approach was to use *strong authentication* (instead of privacy) as a countermeasure to account fraud (knowledge of previous transactions and/or account numbers is no longer sufficient for performing fraudulent transactions). previous post http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found minor digression, as part of doing the work on x9.99 PIA standard, I attempted to pull together a privacy merged taxonomy and glossary, drawing heavily on earlier work on payments, financial, security, etc http://www.garlic.com/~lynn/index.html#glosnote for even more topic drift ... the *electronic* signature legislation differed significantly from earlier work on *digital* signature legislation. there was some conjunction that semantic confusion arose because the term *human signature* and *digital signature* both contain the word *signature*. the issue is that *digital signature* business process is used for authentication (and integrity). *human signature* (and *electornic signature*) attempts to address the issue of human reading, understanding, aggreeing, approvaing, and/or authorizing. I've actually explored in some number of postings the issue of creating systemic risk when there is an attempt to use *digital signatures* for both authentication purposes and also confused with *human signature*. some number of postings on dual-use attacks and/or what does a *digital signature* represent: http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor http://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards? http://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family? http://www.garlic.com/~lynn/2004h.html#47 very basic quextions: public key encryption http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets http://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows http://www.garlic.com/~lynn/2005e.html#43 Actual difference between RSA public and private keys? http://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards http://www.garlic.com/~lynn/2005l.html#7 Signing and bundling data using certificates http://www.garlic.com/~lynn/2005l.html#25 PKI Crypto and VSAM RLS http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys) http://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols http://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for CISSP exam ? http://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA http://www.garlic.com/~lynn/2005m.html#27 how do i encrypt outgoing email http://www.garlic.com/~lynn/2005m.html#45 Digital ID http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution http://www.garlic.com/~lynn/2005n.html#39 Uploading to Asimov http://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack http://www.garlic.com/~lynn/2005o.html#6 X509 digital certificate for offline solution http://www.garlic.com/~lynn/2005o.html#17 Smart Cards? http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc http://www.garlic.com/~lynn/2005p.html#33 Digital Singatures question http://www.garlic.com/~lynn/2005q.html#13 IPSEC with non-domain Server http://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called) http://www.garlic.com/~lynn/2005q.html#29 IPSEC wireless router ? http://www.garlic.com/~lynn/2005s.html#42 feasibility of certificate based login (PKI) w/o real smart card http://www.garlic.com/~lynn/2005s.html#43 P2P Authentication http://www.garlic.com/~lynn/2005s.html#52 TTP and KCM http://www.garlic.com/~lynn/2005t.html#32 RSA SecurID product http://www.garlic.com/~lynn/2005t.html#52 PGP Lame question ---------------------------------------------------------------------- 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
