In part one, we laid out how we should react when our organization tells us they want to roll out a mobile app. Short answer: don’t say no, but instead ask lots of questions. After that, we built a threat model that includes the mobile-specific twists on traditional IT security problems. Using this model, we can do a risk analysis that provides us with a roadmap for mitigation. So let’s start on that roadmap by defining specific security requirements we can give to the developers.

Step 3: Define Security Needs

With a completed risk analysis in hand, you can enumerate the threats to your app. Begin by prioritizing the ones that will impact your specific business requirements and cause the most damage. Not every mobile threat is going to carry the same weight for every organization, so your specific situation will drive your security requirements. For example, if you’re creating a mobile app that pertains to financial transactions, controlling access to transactions is important—therefore robust authentication becomes a requirement. Protecting the confidentiality and integrity of the transactions will also be high priority items, whereas availability might not be a big deal (unlike a streaming audio app, or a communication app).

When presenting security requirements to the application owners (a.k.a. those who will open the purse strings or have the authority to drop features), provide tangible evidence and data showing why this requirement was written. If a threat is likely and impactful, show them the threat intelligence data, breach news stories, and lawsuits for other similar incidents. If there are regulations or contractual obligations, quote them. If customers care about privacy, produce the relevant emails, complaints, and sales documents. Your job isn’t to decide on security, it’s to communicate and interpret the security needs to the decision makers. Given that I’ve done this a time or two, here are a few suggestions on mobile appsec requirements you may want to consider.

Sample Authentication Requirements

• The mobile app should never, ever store authentication secrets, such as passwords or keys, on the local mobile device in unencrypted form
• Mobile app code must be authenticated to provide assurance it is from a known trusted source (code signed)
• If two-factor authentication is used, it should not rely on factors on the mobile device itself such as IMEI or MSI as they are weak and potential privacy exposures
• Enforce all of your usual best-practice authentication rules (lockout or delay failed logins, inactivity logout, least privilege) on both the mobile app and API server connections
• Validate the entire certificate chain to ensure revoked or expired certificates are properly rejected

Sample Storage Requirements

• Assume the mobile device will be stolen and its storage system accessed by unfriendly parties
• Assume the filesystem is compromised/rooted/jailbroken, and therefore never store anything you need to keep secret in unencrypted form on the mobile
• In reference to “local storage with respect to storage of secrets”, this should include cache data, log data, and the source code of the app itself (for example, don’t embed naked passwords or keys)

Sample Communication Requirements

• Be aware of the limitations of mobile communication methods, and encrypt all confidential communications on every channel
• Legitimate large downloads of confidential data are a very rare occurrence for a mobile app, so don’t allow it or at least place an alarm on it—because odds are that an attacker is abusing your API
• Watch out for man-in-the-middle, deserialization, and injection attacks on communication streams
• Make sure the server API that the mobile app uses is hardened against common attacks such as brute force, denial of service, and buffer overflow
• Validate and sanitize data input streams from third-party web services before loading them into the mobile app or API

Sample Operating Requirements

• Perform a version check on the mobile app start up and push down an automatic update if necessary (assume no administrator)
• Isolate the mobile app from any other app’s interference (assume Trojan horse attacks are present on the device)
• Manage the confidential data display, especially when app loses focus, so it doesn’t leak secrets
• Just because it’s mobile, don’t forget the “usual” app problems (XSS, SQLi, buffer overflow)

In Regards to Cryptographic Requirements

Like everything else in application security, encryption is a key control to keep prying eyes out. However, encryption implementation is something that’s easy to fail silently with: you can think you’ve done it right, but find out you didn’t at the worst possible moment. Even if you avoid the obvious pitfall of trying to invent your own crypto-cipher, you can also pick the wrong algorithm, use the wrong settings, or simply omit an important step.

Decades of programming (or even infosec) expertise can lead even the best of us into making bad assumptions about cryptographic implementation. Unless you’re trained and experienced in doing this, tread very carefully, check your work, and/or consult an expert.

Write this up and distribute

Hopefully we’ve given you enough pieces here to build your mobile app security requirements. Maybe not all of these are applicable to what you’re doing, or are phrased in language that your organization will understand. It’s up to you to make them fit and own these. Once you’re done with that and gotten buy-in, it’s time to roll these out to the folks that matter. We’ll cover that in the final part.