Only a few years ago, financial institutions were looking at the bring-your-own-device (BYOD) movement with trepidation because of concerns that their carefully constructed information security infrastructure would come tumbling down as loan officers and other employees tapped their way to needed data. Today, many banking organizations are not only tolerating employee use of smartphones and tablets but embracing it.
The shift in attitudes spans institutions of every size. Examples of adoptees include the National Banks of Central Texas, which has rolled out a mix of iPhones, iPads and Android devices to its 10 branch offices, and UK-based banking giant Barclays, which last November purchased 8,500 iPads to facilitate face-to-face customer interaction beginning with a new app enabling fast market-wide searches for mortgage loans.
Today, financial services organizations represents the highest mobile device adoption of any industry sector, accounting for 24% of all enterprise mobile device deployments and 30% of iPad activations.
The challenge is to manage both bank-owned and employee-owned mobile devices with the robust device, data and application security controls required to address the stringent governance, compliance and asset protection needs of the banking environment. Also critical is the ability to save money on recurring mobile expenses by monitoring device usage for voice, data or text overages.
Achieving these objectives requires admins to set mobile device policies as well as utilize tools like mobile device management (MDM) services to enforce them. Here are seven building blocks that banks can use as a foundation of a secure and cost-effective mobile program.
1. Determine which apps will be allowed and banned.
Core business apps like mortgage loan, business loan and wealth management programs clearly need to be accessible to mobile users, but some public apps should be off-limits on employee devices to avoid compromising security, productivity and/or legal or regulatory compliance as well as to reduce the risk of device infection by malware or other malicious code. Admins can dictate what’s allowed – and what’s not – by utilizing the whitelist and blacklist functions of the bank’s preferred MDM solution.
Whitelists should include all private in-house apps, which will be pushed to smartphones and tablets by IT staff; customer service apps like Salesforce CRM that are used by the bank; email and other applications from office suites like Microsoft Office and Google Enterprise; and other tools and databases that should be installed on the device for business use.
Blacklists might include social networks, gaming and movie/TV streaming services, apps with sexually suggestive or other objectionable content that might expose the bank to legal action, and unauthorized cloud storage apps that can cause data leakage. Admins may also want to restrict the use of some apps that come pre-installed on the mobile device. Blocking Apple’s iCloud storage service, for example, will prevent bank employees from backing up bank information to their personal cloud.
Blacklists can typically be configured in MDM software simply by checking boxes with unwanted categories and specifying additional undesirable apps by URL or keyword. While the ability to stop users from downloading blacklisted apps varies depending on the mobile OS, the MDM solution can issue a warning, lock the user’s email access or even selectively or completely wipe the affected device if it detects installation of an unwanted program.
2. Control app access by location.
Access control can also be enhanced – particularly in the case of employee-owned devices where admins have limited control over users’ app habits – by preventing employees from using certain apps on bank premises. Admins might want to disable device cameras inside the bank to eliminate the risk of mobile users taking a screenshot of a customer’s account; bar the use of game apps or media streaming at bank locations; and so on.
This can be accomplished by using the MDM solution’s geofencing capabilities to activate or deactivate mobile features and apps within specific geographic boundaries. The same geofencing functionality can also be used to automatically switch the mobile device from the carrier network to the bank’s WiFi connection as users enter the bank zone, helping reduce data bandwidth costs.
3. Establish device locking and user access control policies.
Whether the device is bank-issued or employee-owned, an important but often overlooked step is to establish user authentication controls via strong password policies. How frequently should they be changed? How many invalid logins should be permitted, and how long a period of inactivity, before the device is locked? And who can access what data using what mobile apps from what kinds of devices? Banks may want to limit mobile access to critical banking applications because of the higher risk of a data breach over unsecured mobile communication channels and potential infection by malware or rogue apps.
Once established, device locking policies should be deployed over-the-air (OTA) for easy mass distribution, and for easy on-the-fly changes of details such as password length, strength, complexity and reuse. (Policies that are stricter than those provided with the mobile OS will supersede the OS rules.) Admins should also be able to remotely reset forgotten passwords, and override passwords for lost or stolen devices in order to erase sensitive information.