commercially reasonable security

26 Mar 2013

Hot Topics Tom Hinkel 0 comment

Court rules in favor of Bank in account takeover case

Unlike the PATCO ruling, a district court in Missouri has ruled in favor of the bank in an account takeover case brought by one of its commercial customers. This case was very similar to the PATCO case with one important exception, which I’ll discuss shortly. But it also raises some interesting questions that could impact financial institutions.

First, the details. In March 2010, BancorpSouth received a request via the Internet to execute a wire transfer in the amount of $440,000 on behalf of its customer, Choice Escrow and Land Title. The Bank wired the funds, and the following day the customer contacted the Bank to notify them that they they in fact did not authorize the wire transfer. The company filed suit to recover the loss, claiming that the Bank did not use appropriate security measures. But their claim wasn’t that appropriate security wasn’t made available, but that there were several security options available and the Bank allowed the customer to select an inferior option. This is quite different from the PATCO case, where strong authentication was available to the Bank from the software vendor, but the Bank in that case decided not to offer it to their customer. In this case the Bank offered both single and dual-control authentication options, and the customer waived the dual-control option. This gave any authorized user of the software the ability to initiate and approve a wire without requiring a second user to approve and release the funds. Using malware, a hacker was able to gain control of the PC, record the user name and password via a keystroke logger, and send the fraudulent wire.

The PATCO case was decided in favor of the customer because the Bank failed to make strong, commercially reasonable, authentication options available to the customer even though the software vendor offered them to the Bank. But in this case, the judge decided just the opposite; stronger options were made available, but were declined by the customer. Remember, according to UCC 4A the risk of loss for an unauthorized transaction will lie with a customer if the bank can establish that its security procedure is a commercially reasonable method of providing security against unauthorized payment orders. So, advantage Bank. But again, the customer claimed that the Bank should NOT have offered the weaker option to them knowing that it was insufficient to address the risks. In other words, simply offering the weaker option to the customer was an implicit acknowledgement by the Bank that it was commercial reasonable. In the end this argument was rejected because the Bank had documentation that it offered, and the customer refused, the stronger option multiple times.

Although this case turned out OK for the Bank, the verdict does raise several questions for financial institutions:

Knowing that one option is better than another, should institutions even offer more than one authentication option to their customers? And what happens when a customer (or product) increases in risk? Do you require the users to upgrade?
Since the judge in both this case and the PATCO case referenced UCC 4A as the legal basis for their decisions, should the FFIEC be more prescriptive about exactly what constitutes “commercially reasonable” (and what doesn’t)? The 2003 FFIEC E-Banking guidance says that “whether a method is a commercially reasonable system depends on an evaluation of the circumstances.” But the updated 2011 FFIEC authentication guidance doesn’t mention “commercially reasonable” (or UCC 4A) at all. Why not? Specifically, why not include the “…the risk of loss for an unauthorized transaction will lie with a customer if…” language?
Are institutions putting too much faith in technical measures, and avoiding simpler, but more effective, controls? Anomaly detection is getting a lot of attention these days, but in this case Choice had a history of transfers with similar size and quantity, and anomaly triggers were not activated. Simple dual-authentication would have prevented this fraudulent transfer.
On the other hand, are vendors overlooking more effective technologies, such as out-of-band authentication and secure DNS?

In summary, there are still questions, but there are also a couple of lessons financial institutions should take away from this. First, the court determined that although dual-control was more labor intensive for the customer, it was also the more secure option, and as such Choice should have opted for increased security over the increased inconvenience. Lesson? Perhaps you should be less concerned about inconveniencing your customers with increased security requirements, and more focused on convincing (i.e. educating) them on why a little increased effort on their part is justified…i.e. security trumps useability. Second, customer awareness efforts and documentation made all the difference in this case. If the Bank had not made, and documented, multiple efforts to implement stronger authentication, this case could easily have gone the other way.

04 Sep 2012

Hot Topics Tom Hinkel 0 comment

Customer Awareness Education – 3 reasons it should now be a top priority (and how to address it)

By now everyone has at the very least completed their electronic banking risk assessment, and most institutions have probably gotten feedback from their primary examiner on their progress. So what’s next? Where should you focus your time and resources now? Or should you just wait to see where the regulators go next? Here are 3 reasons why I think customer education is the next logical step…and why you shouldn’t wait to address it.

The updated guidance expects you to enhance the customer awareness program you already have in place. This is the first challenge, because many institutions I speak to don’t have a formal customer awareness program in place to enhance. They may have done some one-off training here and there, but nothing formal. Make training your customers in information security best practices just as important as training your employees. Make it a part of your policies, require annual participation, and document those that participate (and those that don’t).
Customers are largely acknowledged as the least secure element in the electronic banking process. No amount of layered technical controls will prevent this risk. Using sophisticated anomaly detection may allow you to quickly detect and respond to an incident, but prevention is far better, and there are no fool-proof ways to stop someone from clicking, opening or downloading something they shouldn’t. Additionally, because your customers are probably from outside the financial industry, they have never been, and will never be, exposed to the same high level of constant security awareness as you and your employees are. Besides, doesn’t it just make sense to focus your resources on controls that have the lowest cost and highest degree of success? Awareness is the best preventive control.
Future “commercially reasonable” legal interpretation may favor those institutions that go beyond bare minimum requirements. According to the judges opinion in a recent court case involving an account takeover, if and when the security procedures are deemed commercially reasonable, the burden then shifts to the customer (merchant) “…to supervise its employees to assure compliance with the security procedure and to safeguard confidential security information and access to transmitting facilities so that the security procedure cannot be breached.” So beyond simply addressing regulatory expectations, a formal customer awareness program may just be that little something extra that establishes “reasonableness” in the eyes of the court.

So what should your customer awareness program include? Here is a quick summary of minimum requirements based on the FFIEC guidance:

Target both commercial and consumer customers. Focus on high-risk customers first, but then expand to everyone.
Are Reg E protections applicable on their account? What are the implications if so, and if not?
Under what, if any, conditions you might contact the customer and request their e-banking credentials. (Should be “never ever”, right?)
Strongly suggest that they conduct their own risk assessment. Consider providing a simple checklist to get them started. The PCI Security Standards Council has some self-assessment checklists that you may find useful. Modify as needed.
Unless you want the customer using you as their outsourced IT department, you should let them know where else to turn for support. Consider a partnership with a trusted local IT vendor.
A list of your employees names, email addresses and phone numbers that they can use if they suspect suspicious activity. Many security events happen off-hours. Can they reach you 24/7 if needed? And make sure emails are sent to multiple employees simultaneously so they won’t go unnoticed.

Additional Resources:

Microsoft has a very basic 10 question quiz:

http://go.microsoft.com/?linkid=9745641

The U.S. Chamber of Commerce also has resources to assist you:

http://www.uschamber.com/issues/technology/internet-security-essentials-business

Gladiator Technology has a service that addresses the customer awareness requirement, and provides an audit trail: http://www.profitstars.com/ProductBriefs/PSS_Gladiator_eCommercialSAT.pdf

16 Jul 2012

Hot Topics Tom Hinkel 0 comment

Commercially UNreasonable Security

So an appellate court has just reversed the PATCO court ruling, essentially deciding against the financial institution. They ruled that the banks’ security procedures were commercially UN-reasonable.

To summarize, a commercial e-banking customer (PATCO Construction) experienced a financial loss due to an account take-over. They sued the bank to recover the loss, claiming the bank used poor security. The original ruling was in favor of the bank. This ruling was in favor of the customer, and has major implications for all financial institutions as they navigate their way through the increasing risk and increased regulatory requirements of Internet banking.

The entire ruling is worth a read, but here are a few of the highlights from my perspective:

In the end, it wasn’t just a single control failure, but a series of failures on the part of the Bank that led to the ruling. One example is that the Bank lowered the alert trigger for challenge questions from $100,000 to $1, effectively requiring all transactions to require an additional authentication step. The Bank undoubtedly felt they were increasing the safety of all transactions by taking this step, but it actually had the opposite effect. By requiring challenge questions for all transactions they substantially increased the number of chances the criminals had to intercept the correct challenge responses.
The on-line banking product (NetTeller Premium) and provider (Jack Henry & Associates) offered adequate options for on-line transaction security, but not all options were enabled by the Bank. And…
…of those security options offered by the Bank, not all were accepted by the customer. And…
…of those offered and accepted, some were ignored. For example the anomaly detection capabilities worked properly, and automated risk profiling correctly generated abnormally high risk scores for the fraudulent transactions, but no action was taken by the Bank to block them.
The definition of “commercially reasonable” has evolved from the initial ruling favoring the customer, to the most recent one. Both rulings make several references to Article 4A of the UCC (Uniform Commercial Code). The initial ruling stated that because the customer signed the agreement, they implicitly agreed to the security measures, effectively rendering them commercially reasonable. However the most recent ruling quotes from UCC 4A and states “[t]he standard is not whether the security procedure is the best available. Rather it is whether the procedure is reasonable for the particular customer and the particular bank.” Therefore…
…a “one-size-fits-all” approach will not work, institutions MUST tailor their controls to the risks of the transaction.

But here is the most significant take-away for me, and the one with the biggest implication for financial institutions. The judge ruled that based on the UCC 4A official comments on Section (1)(b), if and when the security procedures are deemed commercially reasonable, the burden then shifts to the customer…

“…to supervise its employees to assure compliance with the security procedure and to safeguard confidential security information and access to transmitting facilities so that the security procedure cannot be breached.”

So, all you have to do is risk assess the customer and transactions and employ layered security suitable to the risk, and then the legal and financial liability shifts to the customer, right? Maybe not. According to the FFIEC Internet Authentication update, one of the controls an institution may include (translated from ‘FFIEC-speak’ as SHOULD include) in its layered security program is a “Customer Awareness and Education” program. Which means you are still on the hook unless you can document that you also maintain a customer awareness program AND your customers are actually being trained. (As I mentioned here, you may also want to add a summary of your customer awareness program to your annual report to the Board of Directors).

I’m certain we’ll see more lawsuits on this matter and future rulings may go either way, but the risk is real and immediate so don’t wait for the courts to sort things out. Here is what you need to do:

Complete the risk assessment if you haven’t already. Define high risk transactions, and identity high risk customers.
Implement a layered security program. Make sure you know and understand all of the controls available from your e-banking product vendor. Vendors are adding controls all the time to address the evolving threat environment.
Make sure your customers know and understand all of the controls you’ve made available to them. If they resist or refuse a particular control that you’ve recommended, have them sign-off that they understand and accept the increased risk.
Educate your customers, initially and periodically throughout the relationship, and regardless of whether they resist. Regardless of the quantity and sophistication of your technical controls, the customer is, and will always remain, the weakest link in the security chain.

17 Feb 2011

Hot Topics Tom Hinkel 0 comment

Mythbusting on-line security

As I write this (2/2011), we are expecting updated guidance from the FFIEC any day on on-line authentication and security. It is way overdue, as the last release was way back in 2005. It is supposed to address the changes in the security landscape since then, and hopefully it will even raise the bar a bit, but I’m afraid that it won’t do enough to dispel the 5 biggest myths regarding on-line security:

“My software vendor provides all the security I need.”
“My multi-factor hardware tokens provide all the security I need.”
“If I follow FFIEC guidelines, my measures will be considered ‘commercially reasonable'”.
“Multi-factor authentication is adequate”.
“The customer assumes partial responsibility for security (at least contractually)”.
“Unless Reg E is extended to commercial accounts, my financial liability is limited”.

I’m going to address why all these are false in future posts, but for now make sure your risk assessment doesn’t rely on any of them.

09 Feb 2011

Hot Topics Tom Hinkel 0 comment

Top 5 Compliance Trends for 2011 – Part 5

As I write this, the only case to go to trial of a Bank suing the Merchant over account takeover losses is awaiting the jury’s decision. The result may redefine the liability, and by definition the roles and responsibilities, of both the financial institution and the merchant when it comes to securing electronic transactions. It may also finally determine what is considered “commercially reasonable” security, or (I hope) even toss out the use of this murky term altogether. I believe there is a perfect storm brewing over this issue, with several factors converging simultaneously to produce my final compliance trend for 2011:

Corporate Account Security (merchant capture, remote ACH and remote wire transfer).

Here are all the converging elements and their implications:

The aforementioned lawsuit between EMI and Comerica- The trial just ended on 1/26 and it’s now in the hands of the jury. We’ll see how this plays out, but it will have implications either way particularly if (as I suspect) the merchant prevails.
The upcoming FFIEC update to authentication guidance – We are expecting final guidance on this from the FFIEC any day, but whatever the final requirements, increased scrutiny of authentication mechanisms will be the result. New guidance always results in increased regulator focus, even if it is only an update to existing guidance. Additionally, I suspect that the update won’t go far enough to address preventive measures.
The tendency for affected institutions to under report incidents – Because of the potential for reputation risk, financial institutions are reluctant to report account takeover incidents. That is the primary reason that most institutions choose to settle with customers rather than take the case to court (there have been only 2 cases brought to court so far). In the meantime, we know that online crime complaints have increased substantially each year since 2005, resulting in losses of hundreds of millions of dollars.
A fundamental misunderstanding by both merchants and financial institutions of their respective responsibilities – BankInfoSecurity.com recently interviewed a bank CEO affected by an account takeover incident. In the interview, he reveals that he believes that remote transactions should carry a lower degree of perceived protection than transactions carried out inside the Bank’s security perimeter. He also expected the third-party vendor that provided the remote ACH software to have done more to keep the bank secure. In the meantime, merchants expect the transactions they initiate remotely to be just as secure as those initiated inside the physical confines of the bank.

Here is how this trend differs from the others...regardless of whether or not regulators increase focus on this issue in 2011, I believe institutions absolutely must. The guidance is behind the curve on this issue, and institutions simply have too much to lose. It is clear that the minimum requirement is not sufficient, you must go further. Implement additional preventive controls at the merchant side, and educate everyone on basic security best practices.

14 Jan 2011

Hot Topics Tom Hinkel 4 Comments

FFIEC to issue updated authentication guidance?

I’ve been hearing this rumor for a while now, but we may actually be seeing something new from the FFIEC soon. Gartner is the latest to suggest that an update to the 2005 guidance on authentication is imminent.

In addition to updating it for technological advances since 2005, (Facebook and LinkedIn were in their infancy, and Twitter hadn’t even been launched), I hope it also addresses the increasing responsibility held by the customer, (both commercial and consumer) for data security. I continue to believe that there should be shared responsibility, and liability, for establishing and maintaining a secure electronic banking environment.

Reg. E protects the consumer, and so far the courts have held overwhelmingly in favor of the commercial customer as well. Will regulators extend Reg. E to commercial accounts, or place more responsibility on the customer? Could the new guidance further define “commercially reasonable”?

My guess is that we may not see much clarification on these issues, but we are likely to see additional burdens placed on the financial institution. For example, don’t be surprised to see customer education become more prescriptive, with the financial institution being responsible for it.

Stay tuned!