Cyber-Security Lessons from Wells Fargo


Allie Williams, IOM
Executive Director, CRA
Executive Director’s Report – October 2016

After more than 5,000 Wells Fargo employees lost their jobs, and the CEO took both a grilling on Capitol Hill and has since resigned, one question is raised about whether better cyber-security practices could have prevented, or at least detected, the rampant fraud. What lessons we can learn about cyber-security from the Wells Fargo incident?

In this case, the company sought to incentivize employees to have customers open more accounts, from which the bank could then generate more user fees, late fees, or low balance fees. More accounts equaled more money for the bank, and employees could receive substantial bonuses from this transaction as well. The incentive program quickly morphed from the simple act of persuading customers to open accounts to employees themselves opening accounts without customer involvement at all—fraud.  What’s important from a security standpoint is the ease with which employees could open new accounts (not surprising) with new email addresses (surprising). Many hacking cases involve the compromise of identities or credentials. Typically you want credentials to involve what is called MFA—Multi Factor Authentication. So before you can change a shipping address at Amazon, they will send a letter to the email address you have on file. Before you can access your Gmail account from a new location, you get a text message on your phone. Separate and validated channels. Great idea.

But there’s a flaw. A friend once had their credit card rejected at a store because the card wasn’t signed. He borrowed a pen and quickly scrawled his name on the card and represented it. The cashier then compared that signature to the one he just signed on the PIN pad. Now that’s security! Wells Fargo allowed users to create new bank accounts AND new email addresses at the same time without confirming this with the old email address, phone number, or anything else. That’s a process problem and a security problem. We engage in a host of authentication processes when people OPEN an account, we need to continue those practices when they USE or change their accounts. Multi Factor Authentication works when properly implemented. Otherwise, not so much.

A second security lesson learned from the Wells Fargo case is the impact of incentives—for good and for bad. If you reward teachers by how much improvement their students make toward standards, we just lower the standards, teach to the test, and finally cheat. Whatever incentives you create, people will “game” the system. That can be used to create incentives for finding and fixing security vulnerabilities (bug bounties are one example), but these again must be well designed and monitored. On July 12, 1979, the Chicago White Sox held a “disco demolition night” between games with the Tigers at Comisky Park. Great idea, with results that were, in hindsight, totally predictable. That’s the problem with hindsight—it only works in reverse. So consider the impact of decisions on security, accessibility, etc.

Finally, there’s a lesson for management. If you were measuring the number of bank accounts at Wells Fargo before and after the incentive program, you would find it a great success. If you were, on the other hand, measuring the number of customer complaints ABOUT the number of bank accounts—well, that’s a different result altogether. With security, it’s not just about monitoring and measuring; it’s about monitoring and measuring the right things and correlating them together. That’s the promise of big data.

This is not to say that better security (including data loss Prevention) would have—or could have—prevented what happened at Wells Fargo. We typically bifurcate the “fraud” and “security” functions, and the “security” and “IT Security” functions as well. But the same monitoring and management tools that we use to find hackers (e.g., looking for unusual activities and data aggregations) might have found the fraud pattern as well. It’s worth a shot.

Posted October 28, 2016 in CR Blog