In mobile security, we've got a native app problem, but it's one that can be fixed. The most popular apps today are native apps that are downloaded to a device, as opposed to apps that run in the mobile browser on any device. Because they are developed to run natively (get it?) in the mobile OS, native apps generally have faster performance, improved UX, and can better leverage device capabilities. However, with these benefits come challenges that companies must deal with to make sure they aren't exposed to the new security risks native apps introduce.
Here are three reasons companies need to step up their security game to deal with native mobile apps in their environment:
Today, mobile and bring-your-own-device (BYOD) are interchangeable notions in the corporate environment because so many employees now bring their own devices to work. The BYOD trend shifts the power dynamic from that seen in the traditional practice of distributing company-purchased devices. The lines between personal and professional are blurred on these mixed-use devices and employees – alerted by the hacks and business models of the Facebook world – have a greater expectation of privacy. The historical mobile device management (MDM) security technologies that give IT total control over the device just can't be reconciled with this new BYOD reality and IT admins are opting for policies and technology that allow them to protect corporate assets with granular permissions and management while also giving employees the freedom to use the devices and apps they want – all without unnecessary visibility into employee data or activities. Companies should be considering mobile application management (MAM) or Dual Persona solutions, both of which can logically differentiate between business and personal applications and so provide the necessary granularity of enterprise control.
Native applications typically pull data back to the device so it's available for processing when the device is offline (the so-called ‘CEO on a plane' use case). This speeds the performance of the apps because you're not waiting for data to be transferred from a remote server or requests to be sent back and forth. But having data stored locally introduces a significant risk if mobile devices are lost or stolen. Given how easy it is to have the pocket-sized devices slip out of your hands and into the hands of thieves, this risk can not be overstated. One in 10 smartphone owners in the U.S. are victims of phone theft, according to a study from mobile security provider Lookout. To protect against data theft or loss, companies need to consider mechanisms that can protect locally stored business data. Methods for protecting data on the device can range from something as simple as ensuring that the phone has a lock-screen PIN or pattern set, to completely encrypting the device and every bit of data on it.
The popularity of mobile apps can't be beat. People are spending much more time using mobile apps (86 percent) than they are using their mobile browser (14 percent), a new study has found. This goes back to the benefits of native apps – it's a richer, sleeker experience than using HTML. Native applications call APIs to retrieve business data. These API calls need to be authenticated and authorized to ensure that only valid devices, users, and applications can access the business data. Existing security mechanisms used to protect activities on the web, like Kerberos, Secure Sockets Layer (SSL) and Security Assertion Markup Language (SAML), are not optimized for protecting API calls. Consequently new standards have emerged, like OAuth 2.0, and more recently, OpenID Connect 1.0. OAuth 2.0 has seen adoption across both consumer and enterprise and critically in this context has emerged as the preferred mechanism for securing the API calls of native application clients. OpenID Connect adds an identity layer to OAuth that will be sure to become relevant for native applications as it sees adoption. And just as OpenID Connect builds on OAuth, another protocol, called NAPPS, builds on OpenID Connect to enable a Single SignOn (SSO) experience for native applications - a critical feature as employees interact with more and more native applications throughout their day.