Mobile Security (Part 2)

Device security 

Security at the mobile device layer is usually where the traditional IT security and administrative practices start to break down, and it becomes even trickier to uniformly implement when workers have essentially free reign to purchase and configure their devices as they choose. 

As a result, a myriad of Mobile Device Management (MDM) suites have entered the market in recent years in response to the growing security and administrative headaches that BYOD practices have caused for businesses. MDM software such as Good for Enterprise, AirWatch, Zenprise, and MobileIron all offer solutions that allow an organization’s custom applications, e-mail, and network access to be secured and distributed to smartphone users. Some applications, such as Good Dynamics, even provide APIs for in-house developers to use that allow applications managed through the MDM to share data and communicate between one another (a practice that is usually made difficult or impossible by the sandboxing model implemented by most mobile operating systems). Additionally, most MDMs will provide some sort of remote wiping capability to mitigate the risk of data breaches resulting from a lost or stolen device.
MDM solutions are certainly an attractive option for enterprise customers that have their own developers and IT staff to manage them, but they can be prohibitively costly and complex for smaller organizations to implement. For traditional mobile apps that are developed outside of an MDM solution, having security tightly woven into the application architecture becomes paramount.
Application security
Fortunately for mobile app developers, the same security best practices that have traditionally been followed (or at least recommended) are still applicable. Additionally, the sandbox environment that most mobile operating systems implement gives mobile apps a degree of separation and isolation from other applications on the device, (ideally) preventing less secure and potentially malicious apps from compromising legitimate apps. When displayed side by side (in the figure below) – it’s easy to see that the most popular mobile operating systems (Windows Phone, iOS, and Android) all use a very similar approach to this separation of applications from the operating system:
Android Architecture


iOS Architecture


 Windows 8 Architecture


The key point being illustrated in these diagrams is that most modern smartphone architectures take a similar approach to application isolation. Each application has its own private file storage area and only interacts with the operating system through a well-defined and limited set of API functions. They also all have built-in mechanisms for protecting sensitive data to some degree. 

The first step that all developers must take before deciding how to protect their sensitive data, however, is to determine whether it is in fact absolutely necessary to store the data and just how sensitive that data is. This can be a very delicate trade off – for example, knowing that network access is never guaranteed and often less than stellar when available, a developer might be tempted to aggressively cache data in order to make an app seem highly responsive even under poor network conditions. This may practice may be perfectly acceptable for an app like a home loan calculator that retrieves and stores the most recent interest rates when it has a stable network connection and uses those rates until it can refresh the data. If the application is designed for healthcare professionals, however, and does something like store patient healthcare information to be uploaded and processed once a solid network connection is established, the standard of security is increased substantially.
A number of events could cause the information to end up in the wrongs hands, for example:
  1. Many phones sync with cloud services (iCloud, SkyDrive, Android Backup Service) and automatically back up their application data – if the app stores the credit card number in such a way that this data is automatically backed up to the cloud, it could end up being transferred in plain text to multiple locations without the user’s knowledge. This greatly increases the risk that this data may be compromised and may violate certain privacy protection policies.
  2. The phone could be stolen or lost, requiring public notification of a data breach if the phone wasn’t encrypted.
  3. A weak pin code on the phone could render the device storage encryption moot allowing someone to retrieve the information while the phone is unattended (4 digit pins can be cracked in around 800 seconds).[1]
Harsh laws and regulations surrounding the unintentional disclosure of social security numbers, health information, financial information, and other personally identifying information have made careless data handling practices extremely costly for business, and it’s often up to developers to understand and implement secure handling of this data within their applications. This can be a daunting challenge at times, but a number of resources have been developed by mobile OS vendors and third parties, such as OWASP (Open Source Web Application Security Project), to assist developers in securing their apps.
According to the OWASP iOS developer security cheat sheet, these are the top 10 risks that must be addressed by developers on mobile platforms in regards to an application’s overall security:
  1. Insecure data storage
  2. Weak server-side controls
  3. Insufficient transport layer protection
  4. Client-side injection
  5. Poor authorization and authentication
  6. Improper session handling
  7. Security decisions via untrusted inputs
  8. Side channel data leakage
  9. Broken cryptography
  10. Sensitive information disclosure
Interestingly enough, these vulnerabilities are the same ones that exist across web applications and client applications of all kinds, and many of the remediation steps for these vulnerabilities on a mobile platform are the same as they would be on any platform. A few of the vulnerabilities listed have new avenues of exploitation in the mobile world, and unfortunately the mitigation steps for these tend to be different for each platform. These risks are not an exhaustive list by any means – in fact, VIA Forensics has a list of almost 50 cross-platform mobile security best practices that developers should be following when developing mobile applications that deal with sensitive information of any kind. However, one of the most important mitigation steps that developers can take against insecure coding practices is to implement code reviews, with a security professional in attendance if possible, during the development process to review how sensitive data flows through an application. It’s often the case that simply having a secondary developer perspective will greatly increase the quality and cleanliness of code (how much more often does one clean their house when they’re expecting guests?). 
In the end, It all comes back to users
Mobile security, and in fact security in general, is always a difficult and nebulous goal to achieve because its definition is always in flux. Even with all of the cataloging and categorization of risks and vulnerabilities that security researchers are constantly doing, new vectors for exploitation are being discovered all of the time. App stores and MDM solutions have made it possible for enterprise mobile app developers to push updates to their users in almost real time, but these updates being applied usually hinge on the user exercising some degree of vigilance as well by opting to approve or install these updates in a timely manner. In the end, any security implemented in software can be rendered ineffective by careless end users, which means that security training is always going to be the linchpin of an organization’s overall security posture. 



Phone: 312-602-4000
222 W. Adams
Chicago, IL 60606
Show Buttons
Share On Facebook
Share On Twitter
Share on LinkedIn
Hide Buttons