INVISIBLE MOBILE BANKING CHANNEL SECURITY WHITE PAPER

Transcription

1 INVISIBLE MOBILE BANKING CHANNEL SECURITY WHITE PAPER

2 TABLE OF CONTENTS Introduction 3 A brief review of today s evolving threat landscape 4 Understanding RASP 5 Acquiring information to make the best security decisions 6 The role of behavioral biometrics 7 A layered approach to risk 8 Assembling a risk score 9 Summary 11 INVISIBLE MOBILE BANKING CHANNEL SECURITY SHARE THIS 2

3 INTRODUCTION App developers need to build better & more usable mobile apps AND keep up with the latest security techniques & technologies. 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. 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. 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 cybercriminals 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. INVISIBLE MOBILE BANKING CHANNEL SECURITY SHARE THIS 3

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. INVISIBLE MOBILE BANKING CHANNEL SECURITY SHARE THIS 4

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. INVISIBLE MOBILE BANKING CHANNEL SECURITY SHARE THIS 5

6 Acquiring information to make the best security decisions The first step is considering the security of the mobile app source code itself. 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 geo-location 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. INVISIBLE MOBILE BANKING CHANNEL SECURITY SHARE THIS 6

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 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. OneSpan has partnered with leading behavioral biometrics security provider, BehavioSec, for this precise reason. 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: INVISIBLE MOBILE BANKING CHANNEL SECURITY SHARE THIS 7

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: The physical device layer, The navigation of the app layer, The user actions layer, and The collection layer. 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. INVISIBLE MOBILE BANKING CHANNEL SECURITY SHARE THIS 8

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. 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. The checklist process is illustrated in a sample client report below, showing select criteria that are being evaluated for the risk score. INVISIBLE MOBILE BANKING CHANNEL SECURITY SHARE THIS 9

10 The checklist process is illustrated in a sample client report below, showing select criteria that are being evaluated for the risk score. 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. 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 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. There are numerous solutions available that implement these techniques, such as OneSpan s Risk Analytics. INVISIBLE MOBILE BANKING CHANNEL SECURITY SHARE THIS 10

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 consumerfriendly, 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. OneSpan enables financial institutions and other organizations to succeed by making bold advances in their digital transformation. We do this by establishing trust in people s identities, the devices they use, and the transactions that shape their lives. We believe that this is the foundation of enhanced business enablement and growth. More than 10,000 customers, including over half of the top 100 global banks, rely on OneSpan solutions to protect their most important relationships and business processes. From digital onboarding to fraud mitigation to workflow management, OneSpan s unified, open platform reduces costs, accelerates customer acquisition, and increases customer satisfaction. CONTACT US For more information: info@onespan.com Copyright 2018 OneSpan North America Inc., all rights reserved. OneSpan, DIGIPASS and CRONTO are registered or unregistered trademarks of OneSpan North America Inc. and/or OneSpan International GmbH in the U.S. and other countries. All other trademarks or trade names are the property of their respective owners. OneSpan reserves the right to make changes to specifications at any time and without notice. The information furnished by OneSpan in this document is believed to be accurate and reliable. However, OneSpan may not be held liable for its use, nor for infringement of patents or other rights of third parties resulting from its use. All rights reserved. Last Update July 2018