Last week we talked about the Patco vs. Ocean Bank dispute that arose from a "corporate account takeover." Incidentally, the media calls these ACH fraud but the role that the ACH plays is limited. While it speeds up the fraud, its rules provide for reversibility of transactions by default. The real problem is S.W.I.F.T. where the rules do not provide for reversibility by default. ACH works like checks, S.W.I.F.T. like cash.
We were hardly off the air before reports began to come out about a decision in Experi-Metal vs. Comerica Bank. While some of the facts are similar, in this final judgment, the court found for the customer. As the decision is different, and while last week's lessons still hold, there are new lessons here. We might as well, we might do well to, get them on the record.
In this case, the court has come down firmly on the side of the common law principle that banks are responsible for ensuring that transactions are properly authorized and to bear the cost of fraud.
However, what is important to us is that the trial rips open the kimono. We get to see the forensics. We get to see what we can never see in any other context. We get to see which controls were in place and which not. We get to see which ones worked and which ones failed.
As in Patco, Experi-Metal's banking credentials were compromised. However, in this case their machine was not compromised. Rather an officer responded to a bait message that appeared to come from Comerica, led them to a counterfeit of Comerica's web-site, where they compromised their credentials by using them to log on to the perpetrators system.
At one level this was simple a spoofing attack. It is not quite a man-in-the-middle attack but we have seen these. It was also a replay attack. Replay of the credentials would have been resisted by the token-based or out-of-band authentication that we discussed last week.
Press reports suggest that the criminals immediately began to transfer money, via Comerica's correspondent, JP Morgan Chase, to accounts in Russia and Estonia. After about four hours, Chase had identified the transactions as fraud candidates and notified Comerica. Comerica then disabled the compromised credentials but failed to terminate the continuing on-line session so the transfers continued for another two and a half hours.
Now, contrary to the popular and journalistic view, it is not only permissible but efficient to rely upon the controls of third parties to detect anomalous, not to say, fraudulent, activity. However, if I were the judge in this case, I would surely have asked myself why Chase was the first to recognize this activity as fraudulent.
In the early days of on-line banking, banks did not permit same-day transfers to arbitrary accounts. The destination account had to be setup in one step, confirmed in-band to the destination account, and out-of-band to the origin. Only then, perhaps several days later, could the transfers take place.
I was reminded of this while at Deloitte. A client, a private bank in Bermuda, questioned this control. The question was referred to me. It seems that some of the large depositors of this bank were asking to be able to make same-day transfers to new accounts. The bank wanted to find a way to accommodate them.
I suggested to them that there were alternative or compensating controls that they could employ, rather than the one that was then standard. For example, when a customer wanted to make a same-day transfer, the bank could involve an officer to approve and permit the transaction. The officer could confirm the transaction with the customer, out-of-band, by phone, e-mail, fax or combinations thereof. Because this is an expensive control, I suggested that the bank might want to have thresholds below which the control would not be invoked. However, clearly they should be invoked for the top ten percent of all transactions.
Indeed, if one is to believe the reports of this case, there were at least half a dozen things about this fraudulent activity that might have triggered alarms. The transactions were both numerous and novel, more than 90 transactions against an account that usually had a zero balance and had not had any in more than a year. They were same-day transfers to unconfirmed accounts. They were made using credentials that had never been used for that activity before. They represented a material portion of Experi-Metals deposits, and indeed of their net worth. They generated $5million in overdraft charges. The judge took that last one as evidence that the bank was not acting in good faith.
Part of what Chase picked up on was that, while the transactions into their accounts were Automatic Clearing House, ACH, transactions, funds for which Chase's customer was liable. Chase's customer was then forward wire transferring the funds, via S.W.I.F.T. , to foreign banks, from which recovery would not be automatic, perhaps not easy or even possible. It is not clear whether Comerica would have permitted transfers direct to such banks.
Last weeks lessons are still necessary but not sufficient. What are the new lessons here?
New lessons for the customer include always initiate connections to your bank in the same way, never by clicking on a link in an e-mail message. Always satisfy yourself that you are connected to your bank by recognizing your balance and recent activity. Be sure that the connection is properly encrypted by checking the browser "lock," the url, and, at least now and then, the SSL certificate.
An analyst at the Gartner Group has suggested that while bank controls are better now than in 2009, there is still room for improvement. New lessons in this case for banks should focus on policy, we protect and inform our customers, and back-room controls, the ones the have proved so successful in detecting credit card fraud. Their policy and controls must be based upon the assumption that, even with the best of intentions and training, some of their customer's credentials will be compromised.
We do not know how many successful corporate account takeovers have occurred, nor how most have been settled. What we do know is that more than half a dozen have resulted in suits against the banks. Perhaps that there are only a few such disputes can be taken as evidence that we are doing a better job for others than we have done for Patco, Experi-Metal, Ocean Bank, and Comerica but I would not bet on it.
We should not be as concerned with how the courts rule on these disputes, law and precedent will not make on-line banking safe, as with how well we serve our clients. It is no excuse to say that "we told them but they did not listen;" the failures in every profession say that. It is our job to ensure that our principles, banks or their customers, are not involved in such losses.
If we are to be worthy to be called professionals and get paid the big bucks, it is our job to recommend the appropriate controls and convince our principals to use them. In our professional development, we must work as much on our communication skills as on our technical ones.
Tuesday, June 21, 2011
Tuesday, June 14, 2011
Patco was the victim of a Trojan Horse attack using software called Zeus. The attack enabled the perpetrators to compromise the Patco's banking credentials and re-play them to transfer Patco's funds to themselves and even to draw funds against Patco's line of credit with Ocean Bank.
The fundamental common law principle is that banks are responsible for ensuring that transactions are properly authorized and that they must stand the cost of fraud. As individuals, we all rely upon this rule. So far, at least for consumer on-line banking, the banks have honored this obligation both for deposit and credit card transactions.
However, over time this principle has been eroded and limited by legislation, regulation, and contract, designed to encourage responsible behavior on the part of bank customers, particularly business customers.
Patco argues it did not authorize the transactions in question and that the bank should reimburse them for the losses. The bank argues that Patco's credentials were used for the transactions and that, therefore, under its agreement with the bank, Patco is liable.
Patco argues that the security mechanism offered to it by Ocean bank was inadequate for the application and environment. It seems clear, both technically and from the events in the case, that the mechanism failed. That is not in dispute. Patco argues that stronger, if more expensive, mechanisms are available, that they would have protected Patco, and that Ocean bank should have used them.
However, the magistrate finds that the mechanism chosen by the bank, i.e., UID and password with challenge-response based on three shared secrets, complies with regulation, is widely used and was agreed to by Patco. The magistrate finds that, as a matter of law, banks are not required to provide the best mechanism.
The regulation in question requires "two-factor" authentication. While this includes token-based or out-of-band authentication, which clearly resist the replay of the customer's credentials, it also includes weaker mechanisms such as challenge-response based on a set of shared secrets.
Note that challenge-response does provide some resistance to re-play, at least until all the shared secrets have been compromised. The findings suggest that the bank increased the likelihood that all three secrets would be compromised by lowering the threshold for invoking them to $1-.
Moreover, a decision that turns on Patco's agreement to the mechanism assumes that it, or any bank customer is in a position to judge whether or not the offering is secure for his purposes. I would assert that that is unlikely, that it is far more likely that the customer relied upon the bank.
There is nothing in the report to suggest whether or not, in choosing its method, the bank contemplated a key-logger attack as was used here. It is far more likely that, as Patco relied upon the bank, the bank relied upon its service provider.
As in most disputes, in this case there is plenty of blame to go around. The bank chose a weak security mechanism. Then, relying upon intuition, rather than knowledge, weakened it further by lowering the threshold. Patco did use a Zeus-contaminated machine. While the bank clearly wants its customers to resist contamination, it should have assumed that across all of its customers, at least some would be compromised.
Bad cases make bad law. I hope that this case will be settled, rather than appealed, so that it does not establish an anti-customer precedent. The common law principle is well-founded and we have an interest is preserving it.
We should not be surprised that banks want to transfer to the customer as much of the responsibility for secure on-line banking as possible. Neither should we be surprised that they prefer regulations and standards that reserve to them the greatest possible flexibility and choice. The banks should not be surprised that we will use them and their services only to the extent that we believe that we are safe when we do so.
As security professionals, we should be advising our small business clients to 1) resist Trojan Horse attacks by using a dedicated and locked-down machine for banking, 2) resist re-play attacks by preferring banks that offer either token-based or out-of-band authentication, and 3) use on-line banking to their advantage by reconciling their accounts and activity daily.
We should be advising our banking clients that they can improve both their competitive and security postures by employing token-based or out-of-band authentication. In a world in which all adults and many children carry mobile computing devices, the convenience of these mechanisms is improving and the cost is falling.
Neither Patco nor Ocean Bank were well served by the security profession. We must do much better if we want to be called security professionals and get paid the big bucks.