Today, many financial services organizations are using mobile apps to amp up customer service and efficiency. These same apps, though, are probably a security problem waiting to happen. Fortunately, smart development teams can mitigate the risk by asking the right questions.

The new mobile landscape

Five years ago, there just weren’t that many cloud or mobile applications. Certainly, we had plenty of SaaS running on cloud infrastructure, but the experts tell me today’s cloud is different. And that means our risk is different.

Clearly, mobile apps are the thing of here and now. Today, almost every major company has a mobile application, often several of them: financial service organizations, restaurants, and retail merchants. Even my house alarm and door locks can be controlled by a mobile app from an alarm vendor (you’d think that my experience in the application security space would deter me from doing so).

“Way back” in 2008 (a mere five years ago), most development teams for the types of organizations listed above were either writing web applications or internal non-Internet connected applications. Each development team essentially focused on a single platform and a single development language. In the subsequent half-decade, companies embarked on the mobile business strategy, but unfortunately, a secure mobile development strategy lagged. Those same development teams were being asked to “port” their applications, for which they know the business logic very well, to the mobile platforms: iOS, Android, Windows Mobile, and BlackBerry (sad story on that last one; hope they survive.)

Each mobile platform has unique hardware, not to mention unique development languages. Sure there are some similarities: ObjectiveC has similar constructs to C, for example. However, there’s plenty of Smalltalk-style messaging and it’s object-oriented where C isn’t. Meanwhile, for Android one writes Java code, but it’s closer to J2ME and not the J2EE most web developers know. And BlackBerry and Windows Mobile development are completely different than the other two and unique to themselves.

Mobile app gap

The result is that developers are now writing four or five different applications and deploying to three or four new platforms compared to the one application and platform they previously moved. It is a recipe for disaster: This new reality has opened brand new attack points into your systems. Worse yet, chances are those first and second generation mobile apps don’t have good security elements baked into them? Why? There are three main reasons:

• Developers are rushed to get features and apps out the door
• Lack of good (or really any training back in 2008 to 2009) mobile security training for developers
• Barely 40 percent of companies train their developers for security in 2013

In a 2012 Ponemon study on Application Security Gaps, one disturbing data point that I thought I initially misread is that 60 percent of security professionals and 65 percent of developers stated that they do not test mobile applications in the production, development, or Q/A process. That’s not security testing; it’s any testing. And I’d like to highlight that the research study was comprised of only enterprise organizations, eliminating the one- and two-person teams that create applications for the iTunes Store and Android Market.

So we’ve got a situation where we’ve got insecure mobile applications, built by mostly novice developers (for those platforms) connecting to corporate datacenters and processing financial, personal, and other sensitive data. For Mr. Regional Bank that has just rolled out a new mobile application without considering the nuances specific to not just the mobile platform, but the specific mobile operating system and associated technologies: There are several nasty vulnerabilities that an attacker can choose from to exploit, escalate their privilege level, and steal your data!

Getting smart about development

For proactive financial services (and other) organizations that are not in denial with respect to the risk mobile applications inherently carry, below are some questions to ask yourself to better understand the maturity level of your secure mobile development program:

• Are we conducting threat models on our mobile applications so we can make sure the high-risk threats take top priority?
• Do our architects, developers, and testers understand the inherent risks to the mobile platform, how mobile applications are typically attacked, and how to implement design and coding countermeasures for the mobile platform?
• Are we (or a qualified third party) security testing our mobile applications before we deploy them?
• Are we performing data flow analysis to determine how/when/where/if we allow our data to be accessed/processed by mobile apps?