Mobile endpoint security: What enterprise InfoSec pros must know now
A comprehensive collection of articles, videos and more, hand-picked by our editors
Google's decision in early 2015 to stop providing patches for WebView has caused some controversy -- and left many...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
organizations with concerns not only over the security of their bring your own device (BYOD) programs, but also over mobile device end of life.
In this tip, I will discuss the issues Google has caused for the enterprise with this decision, and will explain how organizations can overcome and control the risks associated with it, as well as what can be done to prevent future issues like this from being a problem.
WebView: What no more patching means
WebView is a core component of the Android operating system that helps render Web-based content. It uses the WebKit rendering engine and makes viewing Web content faster as it removes the need for apps to actually fire up a full-blown browser.
The original WebView was replaced in Android KitKat 4.4 with a newer and more secure Chromium-based version of WebView. It transpires that Google will no longer be providing security patches for WebView vulnerabilities on devices running older versions -- this is now up to and including Android Jelly Bean 4.3.
The reason given by Google, for no longer providing patches, is because it feels it is no longer practical to securely maintain an aging branch of WebKit. This seems a reasonable argument -- until you look at Google's Android Developers Dashboard, which shows that the majority of Android devices in use are still running Jelly Bean or earlier. Metasploit already includes various exploits for the older version of WebView, which could lead to a compromise of the pseudo-SD card storage system, as well as other saved data. With no likelihood of them being patched, they could last as a forever-day mass-market exploit vector.
Some commentators have likened this situation to when Microsoft ended support for Windows XP despite there being millions of computers still running it. There is a big difference though; Microsoft -- like BlackBerry -- provides clear end-of-life and end-of-sales dates for its products. Windows XP users had several years to plan for its end of life. Google doesn't have a published end-of-life policy for Android -- neither does Apple for iOS; users and enterprises don't know when the devices and software they are running will suddenly stop being supported.
Managing mobile product end of life
The Android operating system is open source, meaning security researchers, device manufacturers or service providers could develop patches for new or existing flaws in vulnerable versions of WebView. However, this scenario is unlikely given the diversity of devices used in a BYOD environment. Google will still accept patches submitted to the Android Open Source Project for older versions of Android, but non-Google-sourced patches are unlikely to make it onto older devices given the resources required to implement the fix, and the need for handset manufacturers and service carriers to push it out to customers.
The most secure option for users whose devices are exposed to pre-KitKat, pre-Chromium WebView vulnerabilities is to update to the latest version of Android. However, this is likely to be an expensive option for many. A cheaper and fairly simple workaround is to install either the latest Chrome or Firefox browser from the Google Play store and set it as the device's default browser. Both of these browsers are securely updated through Google Play. Making this change a requirement before users' BYOD devices can connect to enterprise resources may resolve the immediate problem, but it won't prevent a similar situation from arising again with other software.
This is a risk that can't be ignored. As there's no painless method for securing out-of-date Android devices, it may be time for enterprises to introduce their own end-of-life policy for BYOD devices running Android and iOS operating systems. For example, organizations could make it a rule that as soon as an OS version is superseded twice, employees have six months to upgrade their device or they lose access to the corporate network. This will probably be a more prescriptive BYOD requirement policy than employees are currently used to, and it may deter users from choosing Android-based devices as Google tends to provide major incremental upgrades to Android every six to nine months. However, it still offers users freedom of choice while balancing the need for keeping network assets secure. It also will allow organizations to have a more uniform user base, making device control, monitoring and patching easier.
Depending on an organization's resources, it may be more cost-effective to offer incentives to encourage employees to replace older devices and keep hardware and software updated that way rather than by deploying an enterprise mobile device management product to help mitigate the risks of vulnerable software.
Otherwise, if resources allow, the COPE model (corporate-owned, personally enabled) is a good fit for organizations whose sensitive data is regularly accessed by mobile devices as ultimate control resides with the company. This could mean providing devices that include Samsung KNOX or deploying enterprise mobility management software, such as McAfee's EMM or Google's Android Work, that can create a secure container for enterprise data on a user's device, keeping it separate from personal data and theoretically more secure.
While securing both employee-owned and corporate-issued devices is important, securing the data is critical. End-user education about new and existing threats and well-explained BYOD and end-of-life policies are essential to keeping corporate data secure in today's BYOD environments. Network administrators should also bring mobile devices in scope during penetration testing so they can fully understand the risks these devices introduce and how they can be best mitigated.
About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with over 20 years of experience in the IT industry. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. He was also formerly a Microsoft Certified Database Manager and a registered consultant with the CESG Listed Advisor Scheme (CLAS). Mike has a passion for making IT security best practices easier to understand and achievable. His website offers free security posters to raise employee awareness of the importance of safeguarding company and client data and of following good practices.
Don't miss SearchSecurity's guide to mobile endpoint security