Tackling the Top Mobile RisksStrategies for Defending the Mobile Environment
The two greatest threats facing mobile banking today come from the risky behavior of mobile users, and their download of third-party applications.
And while banks and credit unions have little control over users and third-party apps, mobile expert Tom Wills says institutions can take steps to mitigate their risks. Among his top recommendations: mobile transaction limits, enhanced authentication, device fingerprinting and fraud analytics.
Wills, a senior security and financial fraud analyst at Javelin Strategy & Research, says mobile security boils down to the risk assessment. "In your risk assessments, cover the whole mobile ecosystem," he says in an interview with Information Security Media Group's Tracy Kitten [transcript below].
"For those areas where you have no control, come up with a system of compensating controls," Wills says.
The key to risk assessments is regularity. And in the mobile world, because of ever-evolving technology and threats, ongoing risk assessment is critical.
"In a standard enterprise environment, where it might be recommended for you to do the assessments once every year, I would say in a mobile banking and payment ecosystem, every six months or even every quarter wouldn't be too much," Wills says.
During this interview, prepared as a complement to Wills' new webinar, Mobile Banking: Emerging Threats, Vulnerabilities and Counter-Measures, he discusses:
- Top threats the global mobile e-commerce platform poses for financial institutions;
- Why mobile platforms such as Android offer benefits and security risks;
- How banking institutions should assess their mobile banking and payments risks.
Wills is senior analyst of security and fraud at Javelin Strategy & Research and managing director of Secure Strategies Pte. Ltd. A veteran product developer, analyst and strategist in the field of security and risk management for payments, banking and e-commerce, Wills for nearly two decades has helped organizations navigate the challenges of building and maintaining trust in their mobile products.
Emerging Mobile Threats
TRACY KITTEN: We've heard about MITMO and other mobile malware attacks, but what other emerging mobile threats should we be concerned about?
TOM WILLS: The first is attacks against the mobile networks themselves. The telcos take security, I'd say, more seriously than the app-store vendors, but less seriously than the banking industry. They fall in-between those two. There are some security holes in the mobile network. For example, cell towers can be spoofed. There's a well-known man-in-the-middle attack that's possible between the phone and the cell tower. SMS [short message service] and USSD [unstructured supplementary services data] gateways very often have poor security; so it's often possible to harvest transaction data from them if you've had an insider at the telco who wasn't supervised well, for example. This falls into the realm of things that, as a bank, you have no control over. Compensating controls, like transaction limits, good authorization systems, device fingerprinting, fraud analytics and things of that nature are going to help.
Then there's the whole aspect of mobile banking and payments, the back-office aspect, which again raises the possibility of insider fraud device fingerprinting. We don't want a situation where a bank employee or a call-center employee is able to get access to the general ledger function of a mobile banking account at the back-end and, for example, create accounts for themselves or for accomplices that they're able to fund fraudulently. That's a concern. To protect against that, you need good, all-around, information security: strong authentication, dual controls, background checks, things of that nature. There's nothing new or unique here, but it's very important to secure the back-end as well as the front-end.
KITTEN: What types of threats are some of the international markets facing that could help institutions in the U.S. prepare?
WILLS: I've worked on mobile banking and payment systems, both inside and outside of the U.S., on four continents at this point, and I would say that so far threats against mobile-banking services are pretty uniform globally. There's nothing really special to report here, and that's because the technology is pretty uniform. You have four or five different vendors, and those vendors are selling into Latin America, Asia and into the United States, too. The attacks against those systems are going to be fairly uniform. I would say it's a global issue on how to secure mobile banking systems.
Top 3 Best Practices
KITTEN: What are the top three best practices institutions should implement for risk assessments?
WILLS: If you want to boil it down to three things, I would say the first one would be, in your risk assessments, cover the whole mobile ecosystem. For those areas where you have no control, come up with a system of compensating controls. Secondly, with your risk assessments, repeat them often. We're in an environment where technology is changing and evolving very quickly, and so is the threat environment. In a standard enterprise environment, where it might be recommended for you to do the assessments once every year, I would say, in a mobile banking and payment ecosystem, every six months or even every quarter wouldn't be too much. Thirdly, be sure to treat the mobile device - the consumer device - as untrusted. Come up with some appropriate compensating controls for that. Those would be the top three.
Vulnerable Mobile Devices
KITTEN: Are there certain mobile devices, such as Android, that institutions might want to avoid?
WILLS: I don't think that limiting devices or operating systems is a very good strategy, especially given that Android has the biggest market share. If you cut out Android and Android devices, you're essentially cutting out your whole market. That's probably not the best approach.
In the mobile world, it's always been the case, and the challenge, that you have to cater to multiple devices and multiple operating systems. ... I'm going to go back to that same old mantra of using compensating controls - your transaction limits, authorization, device fingerprinting, analyze transactions - and look for risk there. On high-risk transactions, keep them low. But do that as opposed to a broad-brush approach of eliminating a given operating system or device.
KITTEN: You've mentioned Android, and I wanted to ask a little bit about Android concerns. Are there worries that we should share with consumers about personal data being saved in cloud-based servers? And if those servers are hacked or some type of personal information is breached, could the bank be held responsible?
WILLS: Android is unique in that it's an open-source platform. From a security standpoint, it's designed to be self-policing, which is probably good if you're a game developer. But if you're developing and you're deploying financial applications like banking and payments, it's not so adequate. When an Android application gets downloaded and activated, there are a number of permissions that have to be set up by the user with respect to what data can be exposed from the application. Given that most device owners and consumers aren't terribly savvy about security and privacy, it's easy for them to skip over the right decisions or even to be fooled into making the wrong decisions about their data. That sort of leaves things open for phishing and social-engineering-type scenarios.
As far as liability goes, in a case of a breach, I'm not a lawyer; but I wouldn't be at all surprised if we saw class action suits down the road coming from consumers who feel that they've had their privacy violated in some way when their PI [personal information] was harvested off their mobile device. That's simply because mobile devices enable a new kind of eavesdropping capability that never existed before; so we're really in new territory here. As usual, the technology innovation is way far ahead of regulation and even development of best practices. I think we're going to see a lot of activity and a few incidents, a few breaches, things going wrong, probably from legal activity, and then some movement toward regulation in that area.
KITTEN: Is there one mobile platform that's more concerning than another, where consumer privacy issues are concerned?
WILLS: Absolutely. The answer is Android. We're in this dilemma because Android is the biggest operating system. They keep getting bigger, with respect to market share, and, again, it's because Android features this system of permissions that the user gives when the application gets installed. And because of the way people behave, I believe that's going to raise some privacy issues. Google, which developed Android, made a conscious choice to build the platform that way and not to have heavy security built into it, even though it's been their position that they were adequately secure. But really, when Google designed Android, I don't think they designed it with mobile banking in mind. I think they designed it for a lot of other things in mind, so that's a concern and will continue to be one.
KITTEN: What can institutions do to ensure that mobile banking and payments applications have security baked in?
WILLS: Absolutely. It involves negotiating contracts with app developers to have them include more stringent security requirements, like following a security development lifecycle, complying with the OWASP [Open Web Application Security Project] guidelines, and doing security testing and code reviews prior to release. In my experience, most developers are going to enthusiastically resist this because it pushes up their cost. But banks are the customers here; as an industry, we need to put ourselves in the driver's seat with respect to security. It might be that we need to pay more in the end for these more secure apps; but think about the cost of more secure software against the cost of one-third of your potential customers not going to mobile banking at all because they're concerned about security. It seems like a prudent investment to me.
Outsourcing App Development
KITTEN: How concerned should the industry be about the outsourcing model for app development?
WILLS: We should be very concerned about this. It's an area that hasn't gotten nearly enough attention in the industry, and it has created something of a vacuum for the hackers to rush into. When hackers find a weak point in the security chain, they're always going to jump in and exploit that. The first tech example that I gave in the presentation is proof that malicious app developers are out there and they can and will exploit weaknesses in the app store, and even if you have a big branded offshore development house that's totally legitimate and it's a good company, you still might have a rogue employee that exists in that organization who puts a trap door or a backdoor, like a logic bomb, into the code. That developer could leave the company and then go back later on and accesses it. The way to control that is to implement a code-signing process.
KITTEN: Explain a bit more about code signing and steps institutions can take to protect customers from fake apps.
WILLS: Code signing is the process of digitally signing a software application, and from a security point of view, it does two valuable things. One, it confirms who the developer of the software is. Two, it guarantees that the software hasn't been altered. In an app-store environment, if you code sign your mobile banking app and you make it clear that you've done that and then the digital signature you have checked is part of the software-distribution process, either by the app store, as I continually recommend, or when it gets downloaded, then it makes it harder for that fake banking app to be posted on the app store in the first place.
I should say here that just like any other security controls, code signing isn't perfect; it can be defeated with enough technical expertise and determination, so you can't rely on code signing by itself. You need to have the full constellation of security controls working together. For example, users can be tricked through social engineering into running unsigned code, or even into running code that refuses to validate. If private keys are compromised, then the system isn't secure any longer. It's one control that should be used among many. It's also important to understand that code signing doesn't protect the end user from any malicious activity or unintentional software bugs. It just ensures that the software hasn't been modified by anyone other than the legitimate author.
KITTEN: What are the third-party risks, especially as more non-financial players offer mobile payments or services that touch mobile banking?
WILLS: You have to be aware of the risks that are introduced into your own service by other players in the ecosystem and by the networks that link these players together, like the mobile, GSM [Global System for Mobile] or cellular network, for example. And once again, unless you have a contractual relationship with the company involved, there's not a lot you can do to influence their security practices. And because you're a bank and they're not, it's almost a given that they're going to have less security than you do. All you can do in that case is consider those entities and those networks as untrusted and use compensating controls. Do what you can to avoid sending sensitive data across sensitive networks, either by encrypting, caching, tokenizing your sensitive data or some of the other things that I mentioned earlier, like device fingerprinting, analytics, transaction limits and so forth.