Best Practices for Building a Secure Mobile Application

Photo Credit: Code via Michael Himbeault cc

Compare Your Current Security Approach Against these Practices for Secure Software Development

These practices should not restrict a programmer’s momentum, but empower and guide them throughout the software design and development process. If you rush to release the application, then problems will most likely arise.

1. Appoint a Person to Security

The product idea is agreed upon. Now it’s time to code. But before moving forward, appoint a person to manage all security aspects throughout the software development lifecycle. Small teams may require the programmer(s) to claim responsibility for security aspects of their own software.

2. Model Threats During Software Development

You must instill security at the onset of development. An inefficient person develops the application and then stops, thinks about security, and returns to add security features/components after initial development.

Consider what your software does. What solutions does it provide for users? What data do you request from users? Is this or any of the user data valuable to malicious hackers? How would they steal this data?

Ask these and similar questions. Model common and current known threats. Keep the malicious hacker and security overall lingering in your thoughts as you design and code. Waiting till later to worry about security may cause significant delays and delays in the software development process.

3. Segment Code into Modules and Submodules

Segmentation with modules, submodules, and internal APIs creates isolation within the application. This enables programmers and auditors to more effectively analyze, monitor, and fix security issues and bugs.

Isolation is an important concept for in overall security architectures for network and systems security. This is the very reason network security experts may suggest the usage of host-based firewalls that separate larger networks.

4. Separate Critical Application Functions and Features

This suggestion emphasizes isolation as well. When developing an application with access to financial or sensitive data, create secure walls between critical functions. Add layers of authentication that require the user to login continually when executing different actions within the application.

Look at a banking application as an example. The first time logging in may require further authentication beyond the username and password. But security-minded banking apps should require authentication when transferring funds, accessing critical account information (account and routing numbers), and other actions that necessitate further action than simply viewing account balances and pending activity.

Isolation through authentication can slow down or stop intruders if they breach the first line of defense.

5. Opt for Tested Code Libraries

When researching code libraries to use, check for vulnerabilities and usage reports. Never take code at face value.

6. Account for Different Mobile Platforms and APIs

IOS, Android, Windows mobile OS, and other mobile platforms contain varying application programming interfaces (APIs) and built-in security features.

Research the security features and limitations. Map out how your application features and security coexists or compensates.

7. Passwords Aren’t Enough – Add Authentication

If you follow the TechRoots blog or read about media worthy security breaches, you should understand that passwords are often inept at keeping intruders out. Even if the a malicious hacker can’t breach the password entry, security questions don’t offer much resistance either. Both methods depend too much on the human element.

Add extra options for authentication, such as:

• Two-Factor Authentication
• IP address tracking and notifications
• Email or SMS messaging
• Biometrics

Additional authentication shouldn’t result in tolerating weak or reusable passwords. There’s no way to test for reusable user passwords, but you could require specific lengths, special characters, numbers, and aging password limits for users when the user creates an account.

Note on User Experience: Strike the balance between ease of sign up/login process with smart security measures. This considerations depends on the type of data accessed by the user and the services offered.

8. Minimal User Data Required

How much data access is enough? Does your application need permission to view photos/media/files, cameras, microphones, etc?

When designing, focus on requesting the least amount of data possible from users. Limit the data you acquire to reduce the data you must protect.

As the head programmer, ask yourself what you really “need to know” about the user for the software to function and succeed.

9. Server Security and Data Storage

After acquiring user data, what is stored on your servers? Is the data, such as usernames and passwords, encrypted?

The last thing you want to do is to overlook data and server storage security. Never store user data, especially login credentials, in plain text. Encrypt your data stored on the servers. Follow best practices for server security.

Users want to trust the applications holding their passwords, names, email addresses, and everything they hold dear.

10. Establish Trust with Users

Programmers may develop a secure and highly functioning application. But does the average user have any reason to trust that the application will keep their data secure? No. Application stores (i.e. “500,000 Downloads” and ✩✩✩✩ ratings do) establishes trust. Privacy policies create turst as well.

Outline your privacy policy, the company’s reactionary measures in case of a data breach or incident, and whatever else that will ensure users that security remains a priority.

Users want to enjoy applications while staying safe. Trust is imperative, especially with apps that utilize advanced, but potentially dangerous features, such as GPS,  cameras, and microphones.

(TESTING)

11. Consult with Security Auditors

TechRoots bloggers repeatedly stress the importance of penetration testers. The open source community provides an exceptional example of how independent reviewers are far more effective in identifying bugs and issues in software.

The investment proves worthwhile in this case. Consider employing an auditor on a consistent basis. Once isn’t sufficient.

12. Employ Security Analyzers

Application developers should include static code analysis as an essential part of the implementation phase in software development. These tools attempt to automatically identify security flaws in the code.

Open source security analyzer (static code analysis) tools include:

• FindBugs
• FxCop
• PMD
• RATS
• FlawFinder
• RIPS
• OWASP SWAAT
• VCG
• Google CodeSearchDiggity
• codesake-dawn
• YASCA
• RIPS
• DevBug
• CPPCheck

(POST APP RELEASE)

13.Listen to User Feedback

User and developer feedback could highlight areas for improvement. Don’t ignore feedback, even if it’s delivered in a critical manner.

14. Research and Stay Updated on Latest Exploits, Vulnerabilities, and Security Trends

Learn to listen to the industry news and alerts to become aware of the latest threats and how those threats may impact your software.

Several resources and methods enable you to accomplish this feat include:

1. Set up a Feedly account that aggregates industry leading news sites, blogs, reddit feeds, Quora, and other online forums. Feedly suggests shared content collections that help you discover new blogs, social media feeds, and online resources.
2. Create Google alerts for updates through Google Search and News.
3. Follow Panda Security updates for latest virus, malware, and security info.
4. Sign up for US-CERT alerts for current security issues, vulnerabilities and exploits.
5. Follow US-CERT current activity on the latest reported “high-impact” security incidents.
6. Refer to CVE’s database of documented vulnerabilities and exploits.

Additional Reading Resources

Although you may notice the older publication dates, both resources provide valuable information.

1. OWASP Secure Coding Practices Quick Reference Guide
2. NIST’s Security Considerations in the Software Development Lifecycle