Invisible Mobile Banking Channel Security

Transcription

1 Invisible Mobile Banking Channel Security

2 Table of Contents Introduction 1 A brief review of today s evolving threat landscape 2 Understanding RASP 3 Acquiring information to make the best security decisions 4 The role of behavioral biometrics 5 A layered approach to risk 6 Assembling a risk score 7 Summary 9 Copyright 2017 VASCO Data Security. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of VASCO Data Security Inc. Trademarks MYDIGIPASS.com, DIGIPASS & VACMAN are registered trademarks of VASCO Data Security. All other trademarks or trade names are the property of their respective owners. Any trademark that is not owned by Vasco that appears in the document is only used to easily refer to applications that can be secured with authentication solutions such as the ones discussed in the document. Appearance of these trademarks in no way is intended to suggest any association between these trademarks and any Vasco product or any endorsement of any Vasco product by these trademarks proprietors. VASCO reserves the right to make changes to specifications at any time and without notice. The information furnished by VASCO in this document is believed to be accurate and reliable. However, VASCO may not be held liable for its use, nor for infringement of patents or other rights of third parties resulting from its use.

3 Introduction As more banking customers make use of mobile devices and apps, the opportunities for fraud increases. Mobile apps broaden the attack surface to devices that often have limited security measures. This is because keeping a mobile device updated with the latest OS and security patches is a lot more difficult than maintaining a collection of desktops, especially when mobile devices are in the hands of customers or partners and not employees. Mobile apps are also harder to secure than desktop apps because they are often written without any built-in security. Plus, most users are used to just downloading an app from the major app stores without checking to see if they are downloading legitimate versions. And as enterprise developers become more agile, mobile apps are constantly changed or updated, making the possibility of coding errors, that can open the doors to attack, a near certainty. In the past, banks have chosen features and usability over security because of perceived resource limits on mobile app developers time. What happens is that often the easier the app is to use usually means the less securely it is written. But it doesn t have to be an either/or, mutually exclusive trade-off. In this white paper, we want to show a different path, whereby mobile banking apps can be successful at satisfying the twin goals of usability and security. Usability doesn t have to come at the expense of a more secure app, and security doesn t require making an app more complex to use. The net result is that cyber-criminals and other attackers can be neutralized with the right choices that are both usable and secure. But before we describe these methods, let s first look at the current threat landscape. Besides security, mobile apps have a second challenge: to be as usable as possible. Part of the issue is that the usability bar is continuously being raised, as consumers expect more from their banking apps. It used to be that a banking app had minimal features. However, consumers expect more: they want to make quick payments to individuals, scan and deposit checks, set up alerts under specific circumstances to track their account usage, and other things. This puts app developers in between two difficult positions. On the one hand, they have to build better and more usable mobile apps and keep up with feature parity of many banking and payment startups. On the other hand, they have to keep up with the latest security techniques and technologies to eliminate fraud and abuse. App developers need to build better & more usable mobile apps AND keep up with the latest security techniques & technologies. 1

4 A brief review of today s evolving threat landscape In today s environment, threats are becoming cleverer and more insidious. Keyloggers can capture logins and other user account information and use that information to create man/browser-in-the-middle attacks from halfway across the globe, without the targeted user being any wiser of what is happening. Mobile devices can be rooted or jailbroken (in some markets this is more likely than devices that are intact), and then remote access Trojans are installed to capture data. Even multi-factor authentication methods are at risk: numerous articles over the past several years have documented how users have had their phones compromised with a simple social engineering call to a cell provider to change the legitimate owner s SIM card number. Malware used to be more easily detected through residues of files or simple signatures that were an obvious sign of infection. Those days are sadly gone. Modern malware operates more on stealth. Called fileless, they can gather small bits of code that is already written and memory-resident. Using techniques such as return oriented programming, malware can execute standard DLLs and other executable sequences of code that can compromise an otherwise uninfected system. This means that apps themselves even ones that have been carefully crafted -- can be a threat. 2

5 Understanding RASP To solve some of these issues with insecure apps, the first step is considering the security of the mobile app source code itself. This calls for a new kind of app protection, something that works from inside of the apps themselves. This is the concept of runtime application self-protection or RASP. The idea is quickly catching on. Some RASP vendors offer specific features that are mapped to threats (such as a feature that detects and blocks the SSL Heartbleed compromise). This helps the security team show particular compliance and can make a RASP product more appealing to management. RASP is the first step in acquiring data about a user s application. It should be checking for suspicious actions and whether the app has maintained its integrity or has been modified by a bad actor. 3

6 Acquiring information to make the best security decisions Once RASP is in place, the next step is to collect all sorts of data that can be useful in making a security decision to detect and prevent fraudulent use. The idea here is to use this data acquisition effort in the background, so that a user isn t presented with a series of annoying please verify who you really are kinds of dialogs. Instead, a user is constantly being evaluated in terms of what he or she is actually doing with their phone, their mobile apps, and other circumstances such as geolocation and network address. What types of data should be collected? Lots. Examples include: The device the customer uses for banking activities such as their laptop or mobile phone. This step looks more closely at the endpoint mobile device itself. In the past, apps used simple web cookies to mark a machine as trusted. That isn t sufficient and a more complete profile of the endpoint is needed. Today s apps examine many other details, such as: Is it running the most current OS version? Are there any suspicious processes that have been injected into the device s memory? Is the device jailbroken? Is it running over an open wireless network or from a fixed IP address? The use of authentication data, such as passwords, PIN codes, and multi-factor authentication. In the past, this kind of information was used as the foundation for assessing whether a valid account holder was using a particular banking app. Again, this information is just a starting point and needs additional techniques and data. And while using SMS texts as an additional security factor is better than not using any additional factors, it still can be compromised in a number of ways. All of this data is then used to assemble a relative risk score that is used to make a security assessment. But before we can assemble this score, we need some additional input from the actual user. The first step is considering the security of the mobile app source code itself. 4

7 The role of behavioral biometrics We mentioned in the last section a growing dissatisfaction with some of the one-time password types of authentication methods, such as sending SMS text messages. Certainly one of the loudest complaints is how multifactor methods tend to lower usability. This is because a user has to stop whatever they are doing, wait for the SMS text to appear and then enter this code on their device to continue with their mobile banking activity. This has brought about an entirely new field of research and products, surrounding what is called behavioral biometrics. The idea is to examine how a user actually behaves with the app and with his or her device, and to take this information and incorporate it into the risk assessment and authentication processes directly. This is much more advanced than traditional biometrics, which in the past was treated as just another set of authentication factors like a one-time password. However, this approach created problems, because biometrics has many subtleties and the process of verifying voices, fingerprints and other biological factors isn t a simple binary yes/no decision. Instead, it involves more discrete observations of human behavior. To be useful, biometrics will require more effort to obtain large samples of a user s data points and sift through these data points in a meaningful fashion. The key word here is meaningful: often the sampling process can be flawed. For example, a voiceprint recorded in a noisy room is less useful than one done in isolation from other sounds. Additionally, non-native speakers of a particular language might have thick accents that prevent a solid match. This means that many biometric factors will require significant training to be effective. So while better data sampling is a good start, it isn t the only innovation. The real secret of incorporating biometrics is being able to track and sense the end user s behavior, not just judging whether their eyeballs or fingerprints match a stored biometric template. Here are some examples: The way the user navigates around the app. This is measured in terms of both pressing on particular menus and buttons, and how a finger swipes across the screen surface. Other information such as the choice and sequence of menus, the way the user s fingers touch the screen or their cadence typing on a keyboard is also important. Tracking the frequency and timing pattern of logins, transactions, and the sums of money that are involved in the transactions themselves. People have usual habits about how they perform this navigation and interaction, and these details are critical to understand if the device is in, quite literally, someone else s hands. This is a relatively new field, but there are products that can take advantage of the huge collection of sensors now found in the average smartphone, such as gyroscopes, touch ID, geo-location positioning and how people swipe their phone screens with their fingers. These latter actions can be as unique as a fingerprint, so it isn t what you type but how you move your fingers. The best and most effective way is for biometrics to be integrated into the authentication process, so that users don t have any interruptions in their banking activities. VASCO has partnered with leading behavioral biometrics security provider, BehavioSec, for this precise reason. 5

8 A layered approach to risk If you look at the kinds of data that we have collected here, you can see we have collected a great deal: what device the user is running, how they are navigating their mobile apps, and what actions they are performing in the app itself. We have determined whether any malicious activities have been observed on the device itself. While that seems daunting, in reality it is just a series of data layers that are used to build our risk model. This is similar to what many enterprises have with a layered approach to protecting their networks. These include: Compare this to the earlier security methods, where a username/password combination usually was sufficient to run a banking app. There was complete access to every function of the app with just this simple authentication process. The device was automatically trusted, without any further vetting. Those simple days are over. The physical device layer, The navigation of the app layer, The user actions layer, and The collection layer. 6

9 Assembling a risk score Once we have compiled all these layers of information, we next need to pull it all together and see the overall implications of what is going on, and whether our banking customer is a legitimate user or a criminal masquerading as one. Here, context is everything. The checklist process is illustrated in a sample client report below, showing select criteria that are being evaluated for the risk score. Now it is time to determine from all this information the overall relative risk. And this is where the true innovation and frictionless implications come to play. We want to be able to match the risk scored by this analysis with what the user is attempting to do with their app. What this means is that not every action by a user has the same impact in terms of balancing security and risk. This scoring process sounds complex, but in reality, it produces a very simple profile that can be used to decide whom to trust and what device is trustworthy. It strengthens the overall authentication chain from app through device and out to the Internet and other channels of communication. It can easily be used to augment existing risk management systems, and improve them with better knowledge about what a particular user is doing and when someone has been compromised. 7

10 To be effective, risk-based assessments have to happen in real-time and in the background, so that a frictionless user experience is preserved and that a user doesn t have to interrupt their banking activities. This means that the folks setting policy actions need to match the associated risk with the activities to vet them and make some assumptions about the hurdles that a particular transaction needs to go through before being accepted and trusted. dynamic series of circumstances that can result in multiple authentication factors to be satisfied. Instead of passing all access through a onetime password, there are different situations that can allow particular actions, depending on the type of risk that is involved. Access to a particular task goes through a series of trust hurdles, with riskier ones requiring more security or a more thorough authentication process to balance out the risk. For example, an account balance inquiry doesn t carry the same risk as setting up a new payee in your account. This means that any account access decision is based on a There are numerous solutions available that implement these techniques, such as VASCO s IDENTIKEY Risk Manager. 8

11 Summary As better mobile apps are created for other purposes, banking apps have to keep raising the bar on usability to stay competitive and keep their own apps as frictionless as possible to drive mobile channel growth and customer loyalty. Often, banks choose usability over security in their app design. They are driven to make their apps more consumer-friendly, and this often comes at the expense of building a more secure app. The net result is that droves of hackers and cyber-criminals are flocking to mobile banking apps because of their target-rich environment, given these security weaknesses. In this paper, we show how it is possible to build a very secure app and at the same time make it very usable, since the security measures are hidden from the user s view and do not impede any user actions. Clearly, this is the way of the future for all mobile apps, not just for banking. 9

12 About VASCO VASCO is the world leader in providing two-factor authentication and digital signature solutions to financial institutions. More than half of the Top 100 global banks rely on VASCO solutions to enhance security, protect mobile applications and meet regulatory requirements. VASCO also secures access to data and applications in the cloud, and provides tools for application developers to easily integrate security functions into their web-based and mobile applications. VASCO enables more than 10,000 customers in 100 countries to secure access, manage identities, verify transactions, and protect assets across financial, enterprise, E-commerce, government and healthcare markets. Learn more about VASCO at or visit blog.vasco.com 10