We’re finishing up our series on what to do when your organization tells you they want to roll out a mobile app. In part one, we asked lots of questions so we could do a thorough risk and requirements analysis. In part two, we used that information to define security requirements and ensure that we know what “secure mobile” means. Now let’s use them to educate and guide our mobile development and operational teams.

Step 4: Do MobileDevSec

Remember all those scary threat scenarios we uncovered in part one? It’s time to make use of them as part of our developer training. As we roll out our security requirements, tie each one to the approriate threat scenarios. Make sure they understand how vulnerabilities in other apps could expose their data, and how to protect against that risk (for example, by preventing local storage of unencrypted data). Review any relevant regulatory information, and make a plan for how to build to those requirements. Why do we harden our authentication? Show them headlines–there’s a whole bunch of them in our API security article, like how the iPhone mobile device management API was found to be vulnerable to brute forcing or how Instagram’s API allowed an attacker to access user contact information. Because of this, you should also be security testing both the mobile app and the server/API that it talks to, as both will come under fire.

If you’ve already had a code review or application penetration test done on your mobile app, include those those tests as well. Nothing drives a lesson home like describing a SQL injection in your app, and then showing that the developers actually created that hole. I’ve had training sessions where developers got up and left the classroom to go back to their desk and patch the flaws. I take that as a big win. No one wants to put out a hackable app, especially its creators.

I like to begin MobileDevSec training with the basics. The OWASP has some excellent resources in their Mobile Security Project, with enough material to build a basic mobile app security class. In addition, the OWASP Proactive Controls list is applicable to training developers of both mobile and non-mobile applications. Since I’ve been mentioning OWASP so much, I’ll complete the trifecta and urge you to consider explaining the OWASP Mobile Top 10 as part of your developer training as well. This should give your mobile app development team a strong foundation and reduce the number of security flaws introduced in the production of the app.

Keep in mind that, even with training, no development effort is ever going to produce perfectly secure code. Most folks simply do not have the time or money to produce a perfectly secure app on the first try, so expect vulnerabilities. The trick is catch them early in the process and fix them before they get too expensive to repair.

Research from Cyentia and Veracode has shown that the sweet spot for most effective (fastest fix) and best coverage (most bugs caught) is to test weekly. Testing at this frequency implies that the development team is operating under a DevOps or DevSecOps model, with security testing as just another part of the code integration / deployment process.

Another useful way to roll out your testing is to tie it directly to your security requirements. Even better if Quality Assurance (QA) is on board—treating these security requirements like any other necessary product feature that needs to be met before release. This moves security from a “bolt on” to just another one of the things we always do as part of product development.

Remember that your security requirements should be tied back to threat model and risk analysis. When those things change, like when new technology or new threats are uncovered, the requirements (and therefore training and testing) will also be updated accordingly.

It goes without saying (but yet I must say) that your mobile application security tester should be mobile aware. Yes, some traditional application and web security testing methods are applicable but some of the previously mentioned unique mobile threats should also be taken into account. Once again, OWASP comes to the rescue with their OWASP Mobile Testing Guide.

If I learned anything in my three semesters of MBA school, it was that if you don’t measure it, it doesn’t count. Keep track of metrics measuring your application security efforts and report them back to show progress (or backsliding), and earn a few wins in the executive suit. Good things to track include:

• Vulnerabilities Present as a Percentage of Other Bugs
• False Positive Rate of Found Vulnerabilities
• Average Risk Weight Score (to ensure only relevant holes are being found)
• Average Time Between Scans
• Average Vulnerability Closure Rate
• Percentage of Security Requirements Met

Step 5: Prepare SecOps

Securing the mobile application development side is a good start, but don’t forget the Ops part of DevSecOps. Remember that most mobile apps will have a server/API component which puts it squarely in the Ops team’s wheelhouse. As we’ve seen in many breaches, mobile APIs are often left underprotected and are subject to all kinds of attacks. You should work with the IT operations team to ensure the mobile server API is secured against the threat of credential abuse (brute force is especially common here), content scraping, and denial-of-service attacks. Most of the attacks are carried out by bots, so a strong bot defense is a good thing to investigate.

Sometimes brute force or credential stuffing attacks can be so intense that, to the API service, it effectively becomes a denial-of-service attack. Bandwidth, memory, or compute resources can be so overwhelmed that the API could stop serving legitimate mobile application service requests. A good way to scrape off this unauthorized traffic is to ensure that all inbound connections to the API are actually coming from your app and not something impersonating it. This is why it’s a good idea to have the mobile app authenticate itself to the API even before beginning the user authentication session.