Don't Expect Apple and Google to Do App Security for You

The appetite for mobile apps with an appealing user experience shows no signs of slowing – even in closely regulated industries such as financial services and healthcare. In fact, according to Gartner, by the end of 2017, IT organizations will be hard-pressed to meet market demand for mobile app development services as it grows at least five times faster than IT’s ability to deliver them. 

The focus of mobile app developers on speed and on innovation in user experience to meet this demand has resulted in the neglect of basic security tenets, exposing major corporations to serious security risks and many millions of dollars in damages.

This disturbing turn of events stems from a fallacy that is gaining currency in the developer community: that the security measures Apple or Google have implemented to safeguard their app store and advertising revenue streams will keep third-party mobile apps safe from hackers. As a result, a growing number of mobile developers are off-loading their security responsibilities to Apple and Google.

There is a truism in the security sector: security measures work best when they are tied to revenue; otherwise, such measures are considered merely costly overhead at the board level. In this vein, the App Store and the Google Play Store indeed have a robust set of security tools and procedures. But let’s be clear: they are not in the business of securing the workflows of the apps distributed through their stores. 

Those of us in the security industry have seen too many instances in which major corporations were attacked by hackers who gained access to their systems through mobile apps. Let’s imagine XYZ Bank, a major financial institution, has rolled out a new app for its prime brokerage customers. By its very nature, this app includes a great deal of binary logic that contains a wealth of information about XYZ Bank’s back-end infrastructure, including APIs that link to the bank’s servers. 

In an ideal world, XYZ Bank’s back-end would contain embedded security to wall off unauthorized access. But we’re finding that too many mobile app developers don’t pay enough attention to mobile API security. This means that any hacker who reverse engineers the app can gain a blueprint into its mobile APIs and penetrate XYZ Bank to its core.

Once inside XYZ Bank’s back-end, the attacker could move laterally and basically own the bank’s entire system. The result? Millions of compromised accounts, a blow to the bank’s reputation and a multimillion-dollar cleanup bill.

Apple and Google use measures such as DRM, sandboxes and code signing to protect their mobile platforms. These measures have worked extremely well, but they are not infallible. Hackers can still jailbreak, or root, mobile devices, particularly those with outdated operating systems to gain access to the secure app provisioning workflow and remove the DRM layer by dumping the running app from memory. 

As mobile platforms are increasingly hardened, we’re seeing hackers shift their tactics away from attacking mobile operating systems to focusing on penetrating and reverse-engineering individual mobile apps. And as a result, mobile apps have become one of the fastest growing threat vectors.

Real-world exploits at major financial institutions have shown how important it is for mobile app developers, corporate security chiefs and chief executives to start taking mobile threats seriously – immediately.

And it all starts with the most basic security practices – three critical steps every developer, CISO and chief executive must rigorously follow:

Every developer in the world stands on the shoulders of those who came before them, and that means developers often insert third-party components such as file format parsing libraries, networking libraries and compression libraries into their programs. But relying on third-party modules from sites such as GitHub and recipes from StackOverflow is risky because many of the developers who upload code to these sites are not liable for any losses they may cause. 

Developers picking components from these sites must take the extra time to validate that every piece of software is as up-to-date and secure as advertised.

Despite too many painful lessons over the years, security often remains an afterthought in the development process, at least when it comes to mobile apps. Chief information security officers must fold security into the entire development process, from the testing and quality assurance stage, through to production stage before it is submitted to an app store for approval. 

Failure to think holistically about security and expect the unexpected will only increase the odds of something going wrong.

Almost every company relies on outside vendors and many also hire third-party developers. These developers are typically black boxes when it comes to security, exposing corporations that hire them to significant risks. CEOs and board members must insist on full transparency about any third-party developer’s security policies, the vendors they rely on and the auditing tools they use. 

Without full transparency, CEOs cannot properly assess their risk and may unwittingly expose the company and shareholders to significant financial loss. 

Developers, CISOs and chief executives can minimize their risks by assuming complete responsibility for protecting their apps. If they don’t – if they assume Apple or Google will do it for them – they may find themselves bruised, battered and a lot poorer.