Then there are the technical questions that need to be answered. What data will be captured, shared, and processed? What mobile platforms will the app run on? What server-side platforms will it need to talk to? Internal platforms? Third-party services?

You also need to dig into the questions of expectations and dependencies. How important will this app be to users / customers? What mobile services can never go down? What data cannot be leaked or corrupted? How much of the organization reputation will be staked to this app? (One hint is how much of a PR / marketing push the company is putting behind the app rollout). All these are critical factors in your risk analysis and security requirements.

Depending on what industry you’re in, and the mobile service being rolled out, there may be some regulatory compliance implications. In fact, there are already very well-defined requirements for mobile applications in the following regulated industries:

• Banking and financial services via the FFIEC IT Exam Handbook – Appendix E – Mobile Financial Services
• Payment Card Processing via the PCI DSS standards for mobile
• Medical / Health information via FDA Guidance – Mobile Medical Apps

More than anything, you need to make sure you’re clear on who “owns” the mobile project. This will be your point person for discussing risks and compliance issues, making trade-offs, and getting buy-in for resources. It is worth noting that establishing the owner of an application can be a real challenge in many organizations. Responsibility can be spread between development, business units, and IT; but ultimately you need to be sure who is making the call for spending money, taking it offline to fix, or saying “no” to a risky feature.

Step 2: Build a Threat Model

Before we get into the nuts and bolts of building a threat model, we need to take a step back and look at the top threats to apps in general: access credential attacks and injection. It’s a safe bet that these will also be significant threats in the mobile app space. This raises the question: how different is mobile app security from application security? Or better yet, are there mobile-unique security problems? The answer is mostly “no” with some major “buts” included. So let’s investigate.

In theory, we should be able to be secure in the mobile app world by following the same security best practices we do in the traditional app world. But (and this is a big but) for the past couple of decades, we’ve been doing a pretty skimpy job following those traditional security best practice security things. The mobile threat landscape is far less forgiving of lackadaisically patchwork app security. We need to look again at all the things we should have been doing already, but sometimes skipped for expediency. Yes, things turned out mostly all right—at least the cyberworld hasn’t totally burned down yet—but in the mobile world, these oversights can create fatal weaknesses.

It’s worth studying the fallacies of distributed computing, a decades-old list of things that programmers stumble over. (In case you’re wondering, “distributed computing” is the grandmother of what we now call the cloud, but with mainframes.) Three of those old distributed computing fallacies are even more dangerous when we bring them into the context of mobile:

• Erroneously believing the network is reliable, because in the mobile world it really isn’t.
• Erroneously believing the network is secure, because it’s mostly wide open.
• Erroneously believing there is an administrator, because on a mobile there really is no admin whatsoever.

Another old-but-useful concept to consider in threat modelling a mobile app is Ross Anderson’s “Satan’s Computer.” This means assuming that not only is the network connection untrustworthy, but also that the computer the application runs on is potentially evil—as is the user. Indeed, in the mobile world, you must assume breach of the operating system itself, as it could be jailbroken or rooted. Your app may not operate in isolation from other local potentially evil apps, so watch what you store locally and how you handle your app data inputs.

Another problem in the mobile app world that we don’t encounter too much anymore in the realm of traditional apps is counterfeit apps. There have been quite a number of trojan-horse applications released recently that masquerade as the real deal. F5 Labs has published numerous pieces on evil apps used to steal banking credentials, commit fraud, or build DDoS botnets.

Another thing to consider is that unlike a desktop computer, a mobile phone is a very networked device. A typical mobile load-out includes ubiquitous connectivity for Bluetooth, NFC, USB, Wi-Fi, SMS, and of course cellular data. Not many of these protocols have robust (if any) security features. The device itself has other potential privacy-busting built-in technologies such as automatic uploading cloud storage, cameras, microphones, SIM card stored data, and GPS location tracking. If your app leverages any of these things, be sure to consider the privacy implications.

As mentioned at the start of this section, credential theft is a big issue for applications in general. The prevalence of local storage and insecure networking in the mobile space exacerbates this threat. Mobile clients often talk to hosted Internet services via APIs, which can themselves become targets of attack. It is folly to assume that if an API is put on the Internet for mobile connectivity that only mobile clients will attempt to connect to it. Once attackers discover that endpoint is there, they will brute force, credential stuff, man-in-the-middle, privilege escalate, and inject attack to their heart’s content. Attackers will also download your mobile app and decompile it looking for embedded access keys, passwords, and authentication certificates. If you look at the F5 Labs story on API security incidents, you’ll see that a lot of the incidents are tied to attacks on mobile APIs. Those attacks stem from basic security vulnerabilities related to authentication, injection, and weak permissions.

Finally, think about how much your mobile app will need to stand alone. That is to say, assume no one will actively administer the app to patch it, tweak its security settings, or lock it down once installed. We have already published security horror stories around IoT deployments that made assumptions that someone was going to lock down deployed apps but didn’t.

The risky business of apps

Now that we’ve got an idea about mobile app requirements, and a better picture of the threats to the app, we can do a risk analysis. Remember that risk includes the likelihood of bad things happening (the threats) and how badly those things happening will hurt us (the impacts to our requirements). Once we’ve got a good picture of risk, it’s time to look at how to mitigate them. We’ll cover security requirements and mitigation in part two. Stay tuned.