In the first quarter of this year, McAfee Labs found 8,000 samples of mobile malware. The same time last year, this number was in the hundreds.

"A burglar cannot rob 300 homes in one night, but a cybercriminal can attack 300 mobile devices at a time," pointed out Dr. Markus Jakobsson, principal scientist, consumer security at PayPal, at the Mobile Banking and Commerce Summit in San Francisco last month. Not only are hackers more active and aggressive than ever, but consumers tend to be naive and trusting about applications on their mobile devices. "Consumers are oblivious to the threat of malware on smartphones," he says.

"People have gotten rid of their fear of downloading executables," which many people had in the early days of the internet, Jakobsson says. "People will install anything on a phone and do anything their friends suggest," he observes. He believes that for companies, traditional means of fighting mobile malware, such as server-side filters and signature-based detection, are no longer good enough. Behavioral detection, in which customer behavior is closely watched for signs something is awry, will be the more effective mechanism in the future.

"I think the biggest threat we'll see down the road is a growing up in the sophistication of attacks against mobile devices," concurs Andrew Hoog, chief investigative officer of viaForensics, a security firm that tests mobile applications for government agencies and companies for vulnerability to malware. "As mobile devices combine more personal and enterprise data, they become a more lucrative target. They're constantly connected to the internet and they're updated a lot. Mobile has all the information cybercriminals are looking for in one spot."

Apple's mobile operating system, iOS, has some fundamental weaknesses, Hoog says. "What we always say about iOS is it's a monoculture," he says. "In the Android world, you can slice and dice things different ways. Because Apple controls their environment strictly, when you find a vulnerability in the iOS space, once you've got it, you've got it everywhere."

viaForensics has posted a paper providing 42 tips for improving mobile application security. The first tip is, "Avoid storing sensitive data on the device"; the second is, "avoid caching app data on the device." These are mistakes for which the security firm has "failed" applications in the past. The best practices are all directed at developers, to help them create safer programs.

Some of the suggestions seem to run counter to newer things banks want to do with mobile banking. For example, tip 18, "use geolocation carefully," could seem at odds with some of the specific location-based mobile coupons and reward programs banks such as U.S. Bank are piloting - knowing that, say, the customer is in the paint department of Home Depot, that customer might be sent an offer for 30% off Sherwin Williams paint.

"Our point is not, 'don't use it,'" Hoog says. "Use it, but at the granularity you need." For instance, a bank might want to know the customer's phone is in Chicago for fraud detection purposes, but might not need the specific street address. And geolocation data doesn't necessarily need to be saved, on the phone or anywhere. "Geolocation is valuable to the consumer and to the bank in a very specific time and instance, but there's no value to saving that information on the phone itself," Hoog says. "That's where we see a lot of people making mistakes. It's one thing to say I give you permission to find out if I'm in Home Depot, But don't save where I was when and store it on my phone. If you really need to save it, tell the consumer and save it on your server in a secure fashion."

Developers tend to want to grab information and store it. "We say, don't do it just because you can, ask yourself why you're doing it and if you should," Hoog says. If you should, make sure you do it in a secure fashion."

viaForensics' main point is that developers have to write secure code for mobile apps. "They're not writing secure code today, that's why we have different issues," Hoog says. "The fundamental problem with writing secure code is education. In the mobile space there's a lack of understanding, education and knowledge that needs to be done to inform people on best practices."




Attention to detail in application design can help banks protect against mobile malware.




These are some important safeguards against mobile malware, according to security firm viaForensics.

1. Avoid storing sensitive data on the device. Nearly any data stored locally, even if encrypted, could be compromised. Only store essential, encrypted.

2. Avoid caching app data on the device. Developers can configure iOS to not cache web data.

3. Avoid use of query string for sensitive data. A major bank breach was executed with a simple query string modification "attack." Avoid using an unencrypted query string for meaningful data.

4. Avoid crash logs. If an app crashes, the resulting log can provide valuable information to an attacker. Ensure apps are built without warnings and are thoroughly tested to avoid crashes.

5. Fully validate SSL/TLS. Many apps do not properly validate SSL certificates, leaving them susceptible to man-in-the-middle attacks. Certificates should be fully validated by the client and signed by a trusted root certificate authority.

6. Institute local session timeout. Any time the app is not actively used for more than five minutes, the active session should terminate and the user should be required to re-enter credentials.

7. Disable debug logs. Debug logs can store sensitive data and should not be enabled in production build.

8. Hide account numbers and use tokens. Many apps store complete account numbers in various screens. Given the widespread use of mobile apps in public places, displaying partial numbers (e.g. ***9881) can help ensure maximum privacy for this information.

9. Use secure setting for cookies. The set-cookie headers should use the "secure" setting. If a cookie is marked as secure, it will only be transmitted if the session with the host is secure.

10. Limit caching of username. The customer's user name is private data that should be protected.