App Flap

With annual shipments of smartphones rising ever-higher, there is a push for companies to provide apps so consumers can use their wireless devices to do business. However, insurance providers who plan to outsource the development of mobile apps would be well-advised to ask their vendors some hard questions before using those apps to deliver customer-sensitive data.

“We are definitely seeing an increase in mobile apps being created by insurance companies,” reports Bruce Snell, cyber security and privacy director for Intel Security.

“What insurance companies are facing, and what companies all over the world are facing, is they are either driving towards embracing mobile or they are being pushed,” suggests Tom Mulvehill, mobile security strategist for IBM Corporation.

“If they are forward-thinking companies, they are looking for ways to better reach and provide products and services to their customers, and they know that using mobile applications is a great way to do that,” Mulvehill comments.

PRESSURE TO KEEP PACE

Vendors shipped approximately 334.9 million smartphones worldwide in the first quarter of 2016, International Data Corporation (IDC), a Massachusetts-based market research firm, notes in an April 27 press release. IDC further reported in March that the company is forecasting 1.5 billion smartphones will be shipped in 2016, up 5.7% from 2015, and that annual shipments will reach 1.92 billion units by 2020.

Insurance providers “look at what their competitors are doing and if they are not keeping pace, then there is a lot of pressure on them to competitively respond to embrace mobility,” suggests Mulvehill.

“In the rush to respond and, perhaps, to leapfrog the competition, many organizations are going very fast and focusing on feature function at the expense of security,” he points out. “But the risk is too severe and you have to account for mobile security risk. It’s as important as accounting for the security risk associated with your Web-based applications,” he cautions.

Many mobile apps “are not developed in-house,” Snell says. “They are using third-party vendors, so the key is when they start evaluating who they are going to use to develop their app, (companies) need to start asking questions about what security features the developers work with and do they have their source code audited by a third party for security vulnerabilities or security risk?”

Some firms who hire third parties to develop their mobile apps are making false assumptions, suggests Altaz Valani, senior research director for the application development practice of Info-Tech Research Group, an IT research and consulting firm based in London, Ontario.

“There is an assumption that the third-party developer I am going to be engaging with actually knows how to manage data security,” cautions Valani. “The truth is this actually requires more than just development skills. We are talking about domain analysis, security analysis and testing, so it goes beyond just the development domain,” he explains.

SECURITY CHECKS

Intel Security – which acquired anti-virus software vendor McAfee Inc. in 2011 – has a “malware zoo” of 500 million unique pieces of malicious software for desktop computers, Snell reports.

This vastly outnumbers the population of Intel Security’s malware zoo for mobile devices, he says, noting that the number of unique samples of mobile malware doubled, from 6 million to 12 million, between the start and end of 2015. “What that’s an indicator of is that cyber criminals are targeting mobile devices more heavily now,” he says.

“The malware mines for data and that means that you have to protect the data the app uses,” Mulvehill notes. “You have to make sure it’s encrypted,” he adds.

When outsourcing the development of mobile apps, insurers should have “stringent acceptance criteria,” Mulvehill advises.

Snell would likely agree. “The advice I would give is to make sure you are using a well-known app developer,” he says. “Everybody and their dog seems to be developing mobile apps these days, so definitely take the time to research who you’re using, make sure they have good references and really check and see what their secure programming policies are,” Snell advises.

“If you ask somebody whether they do secure code review and they give you a blank look, it’s probably best to move on. So many problems can be solved with good strong secure coding practices and code reviews before (mobile) applications are launched.”

Snell says that there are “vulnerability assessment companies” that insurance providers can use to review apps for security holes. “Take a little bit more time, make sure you have gone through multiple code reviews so when you launch, make sure you are not launching with a vulnerability,” he advises.

Mobile app developers should “review the system logs to understand what third-party code may be logging,” Hewlett Packard Enterprise Company (HP) advises in its paper, Mobile Application Security Report 2016, released March 1.

Based on a scan of more than 36,000 apps written for Google Inc.’s Android operating system and Apple Inc.’s iOS operating system, about 95% of those apps “included logging methods,” HP notes in a statement.

“During application development, logging can be a critical component of correcting buggy code,” HP reports. “But once an application is running on a user’s device, unnecessary logging can expose data to unauthorized third parties,” the report explains.

When contracting with third parties, insurers need to write policies and enforce them, Valani emphasizes. The Mobile Top 10 – an annual list of security problems compiled by Open Web Application Security Project (OWASP) – can be used as a guide, he suggests. OWASP is a non-profit organization focused on improving security of software.

For example a company that provides an app for its customers “might say, ‘We will create test cases from the OWASP Top 10 list,'” Valani says.

“A lot of the risk associated with the Mobile Top 10 has to do with data leakage,” Mulvehill points out. “We recommend, at a minimum, that organizations follow the OWASP guidelines,” he says.

Many products that allow companies to test the security of mobile apps “provide a report in terms of the risks associated with the OWASP Mobile Top 10,” Mulvehill says.

“If they do nothing else other than make sure there are no OWASP Mobile Top 10 vulnerabilities in their mobile applications, they will have done a lot of the legwork in terms of protecting their users’ data,” he suggests.

However, one problem with business-to-consumer apps, “is that they can’t manage the users’ devices,” Mulvehill points out. For example, users of Apple iOS devices often “jailbreak” their devices, he says.

Apple defines jailbreaking as making “unauthorized modifications” to iOS.

“When they do that, they are effectively bypassing the mobile operating system security controls,” Mulvehill says of jailbreaking. “They can go to a bogus app store and, suddenly, they have installed a malicious app. It chiefly mines for data. It tries to exfiltrate whatever it can, but increasingly there are instances where some of the information it captures are log-in credentials, user names and passwords, so the risk for an insurance provider would be there is malware on the mobile device, the insurance provider doesn’t know about that malware, that malware may try to capture the login credentials and, then, what the hackers do is they may use a Web channel to access the accounts,” he explains.

Consumers using insurers’ mobile apps need to be educated, especially about the risks of using public WiFi hot spots, suggests Valani. “I think the company that’s actually producing the app can help with some of the initial education, but at a certain point, you can’t rely 100% on the fact that an end-user will not go in there and hop onto an open network,” he says.

“I think it’s something that the app developers or companies should counsel their customers about,” Snell says of WiFi hot spots. “Maybe as part of the boot-up screen, or as you are connecting, give a little message in there that says, ‘Make sure that you are using a secure connection and not connecting from a WiFi access point that you don’t know or that you don’t trust,'” Snell says.

“There is no control over the user device and there is no control over the sophistication of that user, so it’s really incumbent upon the mobile app developer – in this case, our insurance company – to do two things,” Mulvehill recommends. “First, build it secure and, second, keep it secure. That’s really what’s in the scope of their control.”

Snell agrees a mobile app developer cannot guarantee privacy. “Somebody may have their operating system up to date with their mobile device, but maybe one of the applications that’s running has a vulnerability that allows somebody to get in,” he cautions.

“So it’s really difficult to verify that you have a secure operating system on a mobile. It’s out of the hands of the app developer.”