Customers Want Out-of-Band AuthenticationMitigating Risk Requires Multiple Security Layers at First Midwest
Jorge Solis doesn't have a crystal ball, but he's doing a pretty good job of predicting what it will take to thwart tomorrow's attacks on Internet banking.
As the senior vice president of security for Itasca, Ill.-based First Midwest Bank [$8.4 billion in assets], Solis is constantly analyzing security risks to ensure First Midwest's systems are prepared to thwart an attack.
"It all starts with the risk assessment," Solis says. "I don't look for that silver bullet. No solution is going to stop everything."
That's why layers of security and controls are necessities, as is the need for information security officers to never get overly confident or too comfortable with one or two modes of protection.
FFIEC: Attaining and Maintaining Compliance
As January looms, financial institutions are tightening their controls to ensure compliance with the Federal Financial Institutions Examination Council's updated online authentication guidance.
For some, that means investments in new authentication technologies - solutions that rely on in-band and out-of-band modes of verifying online users. For others, like First Midwest, compliance is just an afterthought to a strategy that has become part of everyday business. "It's not just about compliance here," Solis says. "For us, it's about the best way out there to protect our customer."
Compliance and security ultimately starts understanding the modes of attack. "We've set up controls based on the specific methodology these fraudsters have used to attack our online users," he says. "For Internet fraud through ACH and wires, you have to analyze the attacks to know how to prevent them. We've done a pretty good job of that. ... We've stayed on top it from the beginning and evolved our monitoring."
In fact, First Midwest has been attacked, but none of its customers has ever suffered a loss because of an online breach. "The attacks that I see and hear from other institutions, the losses can be anywhere from between $5,000 to hundreds of thousands of dollars," Solis says. "Even with all of that, these attacks just don't get through."
But that does not mean the bank can put down its guard.
First Midwest always has relied on back-end monitoring and multiple layers of authentication, such as regularly changing challenge questions for user log-in and online device identification through IP address verification. But in mid-2010, the bank decided it needed to invest in an out-of-band layer tailored for its commercial accountholders, which account for about 30,000 of the bank's 230,000 customers. "That's where we saw the highest risk," Solis says.
The bank started rolling out tokens, but within a couple of weeks, the tokens were compromised. First Midwest quickly halted the rollout and shifted gears.
Solis says tokens were the first option. They were easy to deploy and required no programming or additional backend support. But clearly, their vulnerabilities made them less than optimal.
So, Midwest went to plan B: an out-of-band transaction-verification solution offered by two-factor authentication provider PhoneFactor. "After the tokens were compromised, I looked directly at PhoneFactor," Solis says. "We wanted to be proactive. We did not want to wait."
PhoneFactor's solution, which verifies online transactions through automated phone calls, required some programming and integration. Migrating Midwest's commercial accounts took about eight months, and collaboration between PhoneFactor and Midwest's core processor, FIS, was part of the issue.
"It took a while to really understand what we needed to do from that whole programming aspect," Solis says. "There were a lot of programming issues we had to deal with."
Instead of going directly to the bank, Midwest's customers are routed through PhoneFactor first.
Once a customer visits the bank's website to initiate a transaction, the input information goes to PhoneFactor. Within seconds, PhoneFactor places an automated call to the customer. The customer then types in a PIN on the phone's keypad to approve the transaction. If the call is not answered, the transaction is canceled. And if the customer did not initiate the transaction, then a cancellation code is entered.
Since implementation, PhoneFactor has stopped all potentially fraudulent transactions on the front-end. "We have not had a single case come through or show up on our backend monitoring," Solis says.
Advice for Others
Based on risk, Midwest decided the additional programming legwork was worth it. "Part of our thought process there was, if the customer has a computer compromise, the chance of having a computer compromise and the phone compromised is not so likely," Solis says. "It's about building in layers and limiting risk, based on the risks you know."
Other institutions may decide they have different needs; but they must determine those needs upfront. "The key thing is that we made our decision based on the activity we saw," Solis says. "Other institutions should review what's out there and find out what the criteria are that fraudsters are using and build controls around that. Break it down to the simplest form."
Regardless of the solution, banking institutions must also dedicate time to customer training and education. "Anytime you implement something new, you have to explain it to customers," Solis says. "We enhanced our contracts with customers, and in those contracts there is an exhibit about the risks and controls that are required. We also sent out some pre-communication and told them what was coming and why."