The April edition of J. Internet Banking and Commerce is out and includes an essay on "Security Revisionism" that addresses outstanding questions from an economics pov:
Security isn't working, and some of us are turning to economics to address why this is so. Agency theory casts light on cases such as Choicepoint and Lopez . An economics approach also sheds light on what security really is, and social scientists may be able to help us build it. Institutional economics suggests that the very lack of information may lead to results that only appear to speak of security.
Other than my opinions (and others), here's the full list:
Economic analysis neglects attacks by psychopathic criminals. No matter how large the economic asymmetry between paying for a service/object _versus_ stealing said, some people persist in the pursuit of theft.
Posted by: darren at May 10, 2006 06:52 AMwith respect to comment about doubling costs:
> Adi Shamir suggests that to double security we have to
> double costs [ 11 ]. The specific failings of the '90s
> generation were an over-attention on a perfect security
> model, which resulted in usability issues on the one hand,
> and crowding out other ideas primarily with public key
> infrastructures ("PKIs") on the other. We will pay the
> price for this in phishing for the next couple of years,
> until PKI is overcome.
in the mid-90s, when x9a10 financial standards working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments (in the work on x9.59 standard) ... one of the questions was can you eliminate the vulnerability ... as opposed to providing stronger security as a countermeasure to the vulnerability.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subputkey.html#x959
at the time, skimming was well-established ... harvesting static data for use in replay attacks. at the time, part of this was that the account number was effectively overloaded with both account lookup function (used in large number of different business processes) and effectively, also, as form of authentication. x9.59 addressed the opportunity by establishing that account numbers had nothing at all to do with authentication ... and that that there needed to be dynamic data authentication that was not subject to skimming and replay attacks.
the other thing that was fairly well recognized was man-in-the-middle attacks, especially where authentication were used to bracket some number of operations or transactions. The operations/transactions themselves were performed w/o being directly authenticated. x9.59 required that dynamic data authentication (countermeasure to skimming and reply attacks) be applied directly to all operations (countermeasure to man-in-the-middle attacks).
eliminating the vulnerabilities was a significant better approach to providing for cost-effective security, as opposed to attempting to pile-on ever increasing amounts of security to cover up problems. this is somewhat my past serious of posts mentioning that burying the planet under miles of cryptography would never be the solution for several of these vulnerabilities (note that at the time the x9.59 work was starting, there was still quite a bit of gov. & jurisdictional issues around the world with the use of crypto for hiding information, x9.59 changed the paradigm so it was no longer necessary to hide the transaction for fraud prevention):
http://www.garlic.com/~lynn/aadsm15.htm#21 Simple SSL/TLS - Some Questions
http://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
http://www.garlic.com/~lynn/2005k.html#56 Encryption Everywhere? (Was: Re: Ho boy! Another big one!)
http://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005p.html#24 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
http://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
http://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006h.html#26 Security
re:
http://www.garlic.com/~lynn/aadsm23.htm#28 "Security Revisionism"
> Adi Shamir suggests that to double security we have to
> double costs [ 11 ]. The specific failings of the '90s
> generation were an over-attention on a perfect security
> model, which resulted in usability issues on the one hand,
> and crowding out other ideas primarily with public key
> infrastructures ("PKIs") on the other. We will pay the
> price for this in phishing for the next couple of years,
> until PKI is overcome.
and with respect to the above comment about the failings of the 90s ... was that some number of these fledgling, new startups calling themselves certification authorities ... had approached the financial industry with a business proposal for "certificate manufacturing" ... a term we had coined at the time
http://www.garlic.com/~lynn/subpubkey.html#manufacture
the financial institutions would register public keys for each of their accounts and transmit the updated master account file to one of these fledgling, new startup certification authorities. the certification authority would manufacture a digital certificate based on the information in each account record and return the results to the financial institution at only a charge of $100/account/annum. This represented a minimum of $20b/annum transfer of wealth from financial infrastructure to these fledgling certification authority startups.
many in the industry had been convinced that the only security was provided by validating digital signatures using public keys taken from appended digital certificates *and*( there was absolutely no security provided by validating digital signatures using on-file public keys taken from account records (even in cases where the digital certificate content had been totally derived from the same account
record).
my observation that this minimum $20b/annum costs for something that provided no incremental security (over using the same information directly from the account record) created a significant barrier to market entry.
one indication of such pervasive belief in the requirment (for digital certificates for digital signature validation), was an effort in the financial standards group on compressed digital certificates. the problem was that typical payment transaction was on the order of 60-80 bytes ... even for relying-party-only certificate infrastructure
http://www.garlic.com/~lynn/subpubkey.html#rpo
would contribute an appended 4k-12k bytes resuling in a transaction payload bloat of 100 times (thousands of bytes rather then tens of bytes)
the objective of the compessed digital certificate effort was attempting to get the appended overhead down on the order of 300 bytes (initially by removing non-unique fields in every certificate). However, I suggested that even a better method was to remove every field that was already in the possession of the relying party. For the situation where the digital certificate been totally derived from the financial institution account record, it was trivially possible to demonstrate compression of a digital certificate to zero bytes. misc. past posts mentioning the enormous payload bloat of normal digital certificates and the significant payload bloat reduction by appending zero-byte digital certificates:
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#10 X.500, LDAP Considered harmful Was: OCSP/LDAP
http://www.garlic.com/~lynn/aadsm17.htm#4 Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#41 Yahoo releases internet standard draft for using DNS as public key server
http://www.garlic.com/~lynn/aadsm17.htm#54 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#5 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#27 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#31 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#52 A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
http://www.garlic.com/~lynn/aadsm19.htm#11 EuroPKI 2005 - Call for Participation
http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
http://www.garlic.com/~lynn/aadsm19.htm#40 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#5 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#3 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#4 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
http://www.garlic.com/~lynn/2003g.html#47 Disk capacity and backup solutions
http://www.garlic.com/~lynn/2003k.html#66 Digital signature and Digital Certificate
http://www.garlic.com/~lynn/2004g.html#5 Adding Certificates
http://www.garlic.com/~lynn/2004h.html#51 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
http://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#9 Smart card Authentification
http://www.garlic.com/~lynn/2004m.html#23 Help! I'm trying to understand PKI - especially CA's role
http://www.garlic.com/~lynn/2005e.html#22 PKI: the end
http://www.garlic.com/~lynn/2005e.html#38 xml-security vs. native security
http://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
http://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
http://www.garlic.com/~lynn/2005g.html#45 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005h.html#25 couple more Q's on basic public key encryption techniques
http://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of certificates & public keys securely
http://www.garlic.com/~lynn/2005i.html#4 Authentication - Server Challenge
http://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet
http://www.garlic.com/~lynn/2005l.html#7 Signing and bundling data using certificates
http://www.garlic.com/~lynn/2005l.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#23 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for CISSP exam ?
http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation?
http://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance
http://www.garlic.com/~lynn/2005t.html#6 phishing web sites using self-signed certs
http://www.garlic.com/~lynn/2006b.html#37 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#8 Beginner's Pubkey Crypto Question
http://www.garlic.com/~lynn/2006e.html#42 SSL Certificate Signing
http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#28 confidence in CA
http://www.garlic.com/~lynn/2006i.html#13 Multi-layered PKI implementation
for your reading pleasure
Security Absurdity: The Complete, Unquestionable, And Total Failure of Information Security.
http://www.securityabsurdity.com/failure.php
and of course, old post on thread between information security and risk management
http://www.garlic.com/~lynn/aepay3.htm#riskm
and security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61
with respect to one of the references in the above article, some old news items (not sure if they are all still active):
Cybercrime Profits Outpace Drug Trafficking
http://www.ecommercetimes.com/story/47559.html
Expert: Cyber-crime Yields More Cash than Drugs
http://www.eweek.com/article2/0,1895,1893592,00.asp
Expert: Cyber-crime Yields More Cash than Drugs
http://www.extremetech.com/article2/0,1697,1893916,00.asp
Cybercrime now outstrips drug trafficking
http://www.cw360asp.com/Articles/2005/11/29/213190/Cybercrimenowoutstripsdrugtrafficking.htm
Cybercrime 'more lucrative' than drugs
http://www.theregister.co.uk/2005/11/29/cybercrime/
Cybercrime profits exceed those of drugs, expert says
http://www.globetechnology.com/servlet/ArticleNews/TPStory/LAC/20051129/RTICKERB29-2/TPTechnology/
Cybercrime yields more cash than drugs
http://news.com.com/Cybercrime+yields+more+cash+than+drugs/2100-7348_3-5973918.html
Cybercrime 'more lucrative' than drugs
http://www.theregister.com/2005/11/29/cybercrime/
Cybercrime 'more lucrative' than drugs
http://www.channelregister.co.uk/2005/11/29/cybercrime/
Cybercrime more profitable than illicit drug sales?
http://arstechnica.com/news.ars/post/20051129-5648.html