What CISOs must learn from Bitcoin and a research team at Georgia Tech
It has been an eventful time in the mobile world with two recent breaking stories revealing vulnerabilities in the security infrastructure for Android and iOS respectively. While vastly different in their nature, both point to a fundamental lesson that CISOs in an increasingly mobile world cannot ignore – when it comes to encryption, read the fine print. Otherwise you may find yourself up the proverbial creek without a paddle (i.e., remediation strategy).
A sensible approach to mobile security is rooted in a clear identification of what needs protection. In general, CISOs want to protect access (i.e. who can login and get to company systems) and company data, both in transit and at rest. At the root of all protection strategies is strong encryption to protect data that is either input or consumed by the mobile user. Without strong encryption all mobile security strategies are nothing more than a game that hackers can play and win.
In the last month, two separate approaches to compromising encryption on Android and iOS broke in the news. The Android vulnerability, discovered as a result of a compromised Bitcoin transaction, is most directly relevant to encryption. In short, the Android operating system does not properly seed the PRNG (pseudo-random number generator) used by the built-in cryptography APIs.
Randomness is essential to ensure that (a) encryption keys cannot be guessed, and (b) an attacker cannot successfully guess the contents of intercepted, encrypted messages. In short, any app that relies on the vulnerable APIs for its essential encryption functions is flawed, including everything from Bitcoin to a vast array of enterprise-targeted apps developed by third-party and in-house developers.
On the iOS side, a group of researchers at Georgia Tech successfully submitted an app with malicious capabilities and intentions to the Apple App Store. What the researchers discovered is that the cornerstone of Apple’s approval process is a static analysis of the app code (i.e., the app is not actually run for very long to see what it does – instead, tools are used to analyze the code submitted by the developer).
How does malware in the app store implicate iOS encryption? Well, the link here is indirect – malware installed on a device can exploit an OS vulnerability to “jailbreak” the device. Once jailbroken the OS can no longer be trusted, and an untrustworthy OS should not be used for encryption nor should it be trusted to report on its own health and safety when a device management app tries to determine if it is jailbroken.
Before this article is miscast as an indictment of flawed programming or buggy software, it bears stating that all software, particularly complex software like mobile operating systems, has flaws. Having spent eight years building a company in the business of automatically detecting software flaws, I can confirm unequivocally that everything from weapons systems to x-ray machines to console games has software flaws. Some of those flaws have security implications, and it is often hard to tell which will and which won’t. At the end of the day, the root cause of software flaws is the complexity of the software’s feature set and the amount of manual labor required to produce it.
The wake up call for the enterprise is not in the nature of the attacks themselves – it is in the remediation. Enterprises have become adept at managing security vulnerabilities with all of their major vendors, and IT understands that vulnerabilities are a fact of life. The key to vulnerability management is to act on them quickly and effectively, and here we come to the issue.
Employees access corporate systems with a broad variety of Android and iOS devices, and IT can neither upgrade the operating system on Android nor can it influence which apps are admitted to the Apple App Store. IT’s only strategy for remediating vulnerabilities in the mobile ecosystem is to attempt to block access to corporate systems or to blacklist access to specific apps. Neither approach is attractive. Locking broad swaths of employees out of corporate systems is not a particularly productive answer, and attempting to maintain an accurate malware blacklist is destined for failure (see anti-virus).
IT’s best (and only) strategy in a mobile enterprise is to retain control of the components of the mobile software stack that matter most. Encryption and access control are the building blocks of the mobile security infrastructure, and the software implementing these two operations must be as firmly in IT’s control as feasible. In practice, this means that a software-only container, which includes its own full stack implementation of all cryptography functions and all secure network protocols (e.g., a full SSL/TLS stack), should be the only software trusted to handle sensitive corporate data and to authenticate corporate users. This strategy is not perfect because no software (including the container itself) is perfect, but it restores control to IT when vulnerabilities are discovered.
As IT quickly loses control of the endpoint devices that employees choose to access corporate systems and data, IT needs to consider carefully when it is essential to retain control and how to do so. A secure container plus device independent security must be in IT’s control. Companies that fail to do so are risking their data, reputation and revenues.