Select Page


If you haven’t heard, there is a shortage of mobile app developers. Not surprising really, given the monster growth in mobile apps being developed and deployed. Reasonable market estimates for the number of mobile apps downloaded in 2013 run as high as 100 billion. It’s hard to find enough talent to write that many apps. Talent management firm Talent Neuron estimates that job posting for mobile developers has doubled over the last two years globally, but the number of registered developers has increased only 13 percent. One of the reactions to the imbalance between resource supply and demand has been to attempt to simplify and standardize aspects of app development. Mobile app development platforms, such as RohMobile, PhoneGap, and Appcelerator, can significantly speed up the development of both native apps and HTML apps.

Another interesting market that has sprung up is mobile backend as a service (MBaaS). By aggregating third-party API’s, MBaaS assists mobile app developers in connecting their apps to cloud services. MBaaS allows mobile app developers to focus on building the key components of the app rather than on building backend integrations from scratch. Given the resource restraints that enterprises are facing with their mobile app development teams, it is not surprising that more of them are beginning to take a look at these services.

While initial focus was on backend data delivery services (primarily for consumer apps), the market is now expanding into the enterprise through the delivery of more robust data security, user management, reporting, and other enterprise features. The MBaaS market currently includes dozens of vendors; however, only a few have focused on enterprise requirements. These include Appcelerator,, Kinvey, Parse/Facebook, StackMob, and KidoZen. These services are maturing as vendors realize the opportunity within the enterprise segment. For an overview of services in this market, please see the recent analyst brief MBaaS Can Accelerate Mobile App Rollout.

Follw me on Twitter (@abraunberg) to keep informed as new research is released.

Follow us on Twitter (@NSSLabs) to keep informed as new research is released. 3. FIPS 140-2 — KNOX implements a FIPS 140-2 Level 1 certified VPN client, a NIST standard for data-in-transit protection along with NSA suite B cryptography. The FIPS 140-2 standard applies to all federal agencies that use cryptographically strong security systems to protect sensitive information in computer and telecommunication systems. Many enterprises today deploy this cryptographically strong VPN support to protect against data-in-transit attacks.”

Hey Samsung, implementation is as important as features. An MITM attack is one of the oldest tricks in the book. Although simple, these attacks are most effective at obtaining information, and they highlight the need for a secure communication channel. By their very nature, mobile apps are designed for online connectivity. A secure container alone is not effective enough nor is a device-based virtual private network (VPN). Every application requires its own independent secure communication channel, particularly on mobile devices.

Within the findings, Secure Sockets Layer (SSL) encryption is recommended. Unfortunately, SSL implementation in mobile apps depends on developer implementation. It also lacks any visible way to notify a user when SSL is in use on a mobile app. Errors can occur during SSL implementation that may leave the app exposed to compromise on Android. These errors can occur within the configuration of a device’s trusting certificates, during the use of mixed mode communication, with improper management of hostnames, or even in the number of certificate authorities permitted. In general, developers are not security experts. Isn’t part of the value of a secure mobile infrastructure the ability to remove this dependence on third-party implementation of security controls?

Mobile device management is recommended; however, this does not address a user’s ability to install personal apps, nor should it. The premise of a secure workspace and personal space is that users maintain control of their own personal spaces. However, it is within these open personal workspaces that the risk to the system resides; thus, it is necessary to completely segregate the personal and enterprise space at all points of the application workflow.

Per-App VPN appears to be the solution, but it seems the implementation of the VPN connection as provided by Samsung KNOX is just a configuration profile of a device-level VPN connection (where the problem exists) and not an actual secure communication channel that terminates with the application and a known entity at the other end. Device-level VPN connections are susceptible to third-party interception as encryption key negotiation is not controlled by the application. A security provider must assume that the uncontrolled parts of the system are not secure and therefore are subject to exploitation through unknown variables.

FIPS 140-2 might sound great, but as has been repeatedly shown, attacks against encryption key ownership or MITM attacks don’t care about the strength of the encryption as the communication channel will be unencrypted legitimately anyway. These attacks are a form of interception; they aren’t hacking. For enterprise customers, however, there is no distinction between the two.

If Samsung is looking to provide a secure environment for the enterprise, it must take responsibility for all aspects of the information flow and the application architecture. Enterprises require security that does not rely on the native operating system of mobile devices. For the enterprise, a personal device is a glass house, not a fortress. Adding locks won’t change this.

Follow me on Twitter (@moralesATX) to keep informed as new research is released.

Follow us on Twitter (@NSSLabs) to keep informed as new research is released.