In my previous post, Business Model Drives Security, I indicated that security requirements should follow from the business model - in the sense of the value proposition of the business.
In his latest post, In Person Credit Card Scam, Bruce Schneier reports a fraud involving a fake credit card and a trick telephone call, and remarks that "Anyone reading this blog would know enough not to call a number given to you by the potential purchaser, but presumably many store clerks don't have good security sense."
Some of the comments to Bruce's blog point to alternative solutions with varying levels of reliability - involving training, use of known telephone numbers, use of the number printed on the (fake) card - while some comments indicate related scams and vulnerabilities.
But perhaps the real answer lies further back. The basic retail process has evolved over centuries, from letters of credit and cheques to the modern credit card. Various security mechanisms have been added on, often intended more to protect the bank from the dishonest merchant than to protect the merchant from the dishonest customer. If you were going to design a secure system from scratch you wouldn't want to start from the current mess, but that's what we are faced with. So does SOA have a useful contribution here?
Clearly one of the key roles in this collaboration is communications, and the key vulnerability in this particular example is the fraudster's ability to direct the merchant's communication to an imposter bank. As it happens, Bruce Schneier's security monitoring company Counterpane is now part of British Telecom. So one obvious opportunity for Bruce's team is to design security services that BT can deliver into this ecosystem, both protecting honest merchants against known threats and detecting new threats.