What To Do When Your Company Tells You They're Making a Mobile App, Part 1

Whether it’s to support existing services or to push into new markets, lots of organizations are spinning up mobile applications. How many? Research shows that the mobile app space is growing at a rate that’s on par with the home computer Internet explosion of the mid-1990s. Allied Market Research predicts that this market will hit a compound annual growth rate of 19.2% by 2023, making it a $311.2 billion business market¹.

Just as we saw in those frontier days of Windows 95, the security on mobile devices is still in its infancy. Mobile app deployments are even worse: not only is their security similarly immature, their security issues open new attack avenues into the very heart of organizational infrastructures. This is why, when a company declares its intention to enter the mobile application space, it’s the security team that tries to pump the brakes.

In the F5 Labs 2018 Application Protection Report, one of the questions we asked thousands of security professionals was: What’s holding organizations back from having better application defense? The number four response was "Proliferation of mobile devices" (41% of respondents). CISOs know mobile is a problem.

The natural inclination is to respond by adopting a ”Doctor No” strategy and try to block, delay, or deprioritize mobile rollouts. The reasons are the same every time. “It’s insecure.” “We’ll fail audit.” “Our customers will get hacked.” “We’ll be humiliated in public.” Yap, yap, yap.

But we all know very well that “no” is a losing strategy—the business will do what the business will do, no matter how loud the InfoSec geeks howl. So how can we can we flip this from a problem into an opportunity to serve the business?

This series of articles lays out a strategy to guide your organization through a safe and sane journey into the mobile world. At a high level, the strategy will look awfully familiar:

1. Investigate the scope,
2. Create a risk analysis,
3. Figure out the security requirements,
4. Align the security processes with development and operations, and
5. Verify your work.

In this part, we’ll cover how to build and analyze the scope of the mobile project. In part two, we’ll look at creating security requirements, and part three will cover developer training and operational planning.

Step 1: Ask “What do you mean by mobile?”

When the business comes to you and says, “We want to roll out a mobile app,” first ask them to define exactly what they mean. “Mobile app” can mean many things, especially to a non-techie. Their idea of mobile may be far from what you were expecting. It could mean writing an app from scratch, or that they’re partnering with someone else (and you’ll have to integrate). They could simply mean they’re adding mobile capability to the primary web site. Find out before proceeding further.

A lot of basic business questions need answering before you even begin to think about formulating a response. What will the app look like? What will it talk to? What is the business goal? Who will be its users? What is the timeline? What is the budget?

To give you an idea of what is going on in the world at large, check out Figure 1 below. It spells out the responses for the 2018 App Protect Report survey on Mobile App Usage in the Enterprise. As you can see, communication and social apps are in heavy use in corporate environments.

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.