The Mobile Secure Un-Development Life Cycle

The Challenge

Developing apps for the mobile platform has more twists and turns than anyone would possibly want.   As a developer of mobile applications, I fully understand the challenges.  Apps are far and away more difficult to manage (security wise) than just your typical website.  In the case of iOS, it’s easy to think, “well, I’ll just test the mobile app for vulnerabilities, shove that puppy into the App Store and I’m good to go”, but that’s not how it works in the real world.   It’s easy for a programmer to focus solely on their super awesome, clean, tight code, while the biggest challenges come from changes to those parts of your app that you do not control. 

 

Backend API Updates

An easy example is a change or update to the  application's backend API or website.  Developers are most familiar with this scenario and, in some cases, might even have control over API updates in their organization.  In the case of one of my apps I did not have control, since it integrates with third-party party services.  If they updated, I’d have to update (and quickly), then do a new round of security testing and rush the update into the App Store.

 

Development API Updates

Now, factor in the frequent Xcode updates. These updates contain new features and bug fixes, as well as security updates. Take a look at the frequency of these updates:

 

Xcode Version

Date

4.3

February 2012

4.3.1

March 2012

4.3.2

March 2012

4.3.3

May 2012

4.4

July 2012

4.4.1

August 2012

4.5

September 2012

4.5.1

October 2012

4.5.2

November 2012

4.6

January 2013

4.6.1

January 2013

5.0

September 2013

 

 

As you can see, there is an update almost every month or two, not including the big push for the iOS 7.0 release.  In order to get the newest features and fixes for your app, it’s necessary to recode, rebuild and retest.  The decision to update is yours, but there is always pressure to be on the latest version and keep up with fixes and compatibility with the latest firmware updates.

 

Firmware Updates

Speaking of firmware updates!  These, though less frequent, are still another factor to take into account.   Take a look at frequency of the recent iOS firmware updates:

 

Firmware Version

Date

5.1

March 2012

5.1.1

May 2012

6.0

September 2012

6.0.1

November 2012

6.1

January 2013

6.1.2

February 2013

6.1.3

March 2013

7.0

September 2013

7.0.2

September 2013

 

This is an aspect that is out of your control.  Customers will download the latest firmware when they are ready - your app better work and better be secure.  So, here we go again. Code, retest and push it out.

 

App Store Review Process

Finally, there’s the App Store review process to factor in.   This is another aspect that is out of your control and is probably the most frustrating to me, personally.   A typical app takes between 5-8 days for Apple to review your app.   You can ask for an expedited request, but have a good reason (that they agree with) and don’t ask often or your request may be denied.   While waiting for approval any of the previously mentioned changes could take place.  The decision must then be made to go ahead and ship or reject the binary, apply the fixes, retest and submit the app again.  If the choice is made to reject the binary 4 days into the review process, you could now be 3 weeks behind the original target date.  In the case of security fix releases, you need to make the decision to accept the risk (while you apply new fixes) or ship out what you can immediately then rinse and repeat.

 

Mobile Secure SDLC

You can see how the Secure SDLC becomes incredibly difficult to manage when it comes to mobile.  There are quite a few moving parts that affect the security posture of your apps, which you will not always have control over.   Each one of the moving parts introduces risk - deciding how and when to address them is a difficult task.   The best you can do is keep up with early drops of backend APIs, firmware and development API updates.  However, this takes away time from new features for your app, so you need to balance carefully and plan the best you can.

 

References

For more info on the Secure SDLC, check out the Secure SDLC OWASP page.

 

The Author

Ray Kelly is the Mobile Security Team Manager with Fortify on Demand, and can be reached on Twitter @vbisbest

 

 

 

 

 

Tags: mobile| SDLC| security
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.