Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Mobile

2/7/2017
02:00 PM
Satish Shetty
Satish Shetty
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail vvv
100%
0%

Enterprise Android Vs iOS: Which is More Secure?

The answer is not as simple as you think. A mobile security expert parses the pros and cons.

Both iOS and Android come with features that are designed to further secure enterprise applications over and above the security level of standard consumer apps. Both operating systems offer some way of segmenting enterprise data from user profile data, in effect, creating a secure container to install enterprise apps and store enterprise data. Furthermore, network transports can be secured on both platforms using technologies such as data encryption, app-specific VPN tunnels, and even some form of direct boot mode, where the device stops being a general purpose mobile device and instead becomes a dedicated device for accessing specific enterprise apps. These features are described in detail on the Android and iOS Web pages.

Both operating systems have also been found to contain pretty serious security vulnerabilities in the past. Both are vulnerable to malware attacks, although iOS less so than Android. And both are prone to exposure from potentially dangerous security vulnerabilities due to the installation of third-party apps.

Each OS also has its own share of documented security issues. For example, Android has/had problems with the Stagefright vulnerability, and Apple has struggled multiple times with loopholes that allowed apps to execute standard library code directly, bypassing security restrictions. Currently, these vulnerabilities have been patched with up-to-date versions of both operating systems, but this does not mean that similar vulnerabilities will not be found in the future. Here are lists of Android vulnerabilities and iOS vulnerabilities from CVE Details. As of January 2017, iOS has had a total of 984 vulnerabilities whereas Android has had a total of 746. 

Open Source Vs. Closed Source: Not A Big Deal
In theory, the open-source nature of the Google Android project does make it more vulnerable to security issues. In reality, this is not the case. The same open-source mindset that has led to rapid development and improvement of Android, also means that when new vulnerabilities are uncovered, they are fixed very rapidly. On the other hand, the closed-source development of iOS should make it more secure and, in many ways, it does. But it also means that security vulnerabilities are fixed in a hierarchical manner, often taking longer to push a fix to market than Android.

The widest security difference between iOS and Google Android is the way these operating systems are deployed and updated. Android suffers from the significantly adverse effects of fragmentation, which means that there are potentially dozens of versions of the operating system in use at any time, even within a single enterprise. Android-equipped devices ship with a specific version of Android. Whether these devices receive future updates to Android is not a foregone conclusion. Some do, many don’t. Those that don’t are left running an older version. This means that security vulnerabilities need to be patched across a wide range of OS versions and devices. In the chart below, you can see that, as of January 2017, the latest Android version 7.1 has only 0.62% coverage in the business category.

As far as iOS goes, the closed-source approach to development and the aggressive way that Apple tends to protect its proprietary technology can hinder data forensics experts in their efforts to diagnose security breaches. Apple is notoriously unhelpful when it comes to opening up parts of their OS to outsiders. And the locked nature of Apple devices adds to this problem. Apple controls the underlying device infrastructure and will not relinquish this control. For example, iOS blocks apps from reading phone number, device UDID etc. from the device. In Android, app developers can programatically query all the device information, including the phone number.

The same philosophy is channeled through to the app vetting process for the Apple App store. In comparison with Android apps, iOS apps go through a stringent and thorough process before the app is approved and available for the general userbase to download. Google doesn’t thoroughly test Android apps before they go live onto the Google Play Store. Consider this recent example: a simple Android photo app named Meitu requires authorization to access location, phone status and identity, and a host of sensitive cellular functionality that has absolutely nothing to do with photo editing.

So Which Is More Secure?
Quite frankly, the answer to this question can change day by day. If a major security vulnerability is discovered, such as the aforementioned Stagefright, then that OS becomes incredibly insecure until the vulnerability is fixed. But in a perfect world where no current vulnerabilities exist, then both are equally secure.

The choice boils down to this: If you are comfortable allowing a monolithic company drive the security of your enterprise mobile apps, then iOS might be the most secure for you. (Not to mention Apple's thorough app vetting process that blocks most of the malicious apps before they even show up on the Apple App Store.) But if you would rather put your trust in a more rapid, open-source development lifecycle in the belief that this is the best way to ensure that vulnerabilities are fixed quickly, Google Android might be the better option. 

Related Content:

 

Satish Shetty is CEO and founder of Codeproof Technologies, an enterprise mobile security software company. Shetty has more than 20 years of security and enterprise software development experience. A recognized leader in the mobile device management space, Shetty also has ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
vikram909060
50%
50%
vikram909060,
User Rank: Apprentice
8/13/2017 | 6:38:59 AM
Ios more sure then Android
Yes this is what most discussion topic about Android and iOS. One ( Android ) is easy to use and second is hard to use ( iOs ) but when it comes to secure so stopping everything to be used is not solution as what ios prefer. I use rooted Android . I am using this Android TV Box https://www.entertainmentbox.com/product/ebox-t8-v-tv-box-2017-internet-streaming-box-version-5/ which is fully rooted with Android firmware and same allowed me to use anything available without ads issue etc. But the risk of virus etc is there is anything you try for which you are not sure can infect system file and this issue is not on ios platform as you cannot do anything lol.
sgh3tti
50%
50%
sgh3tti,
User Rank: Apprentice
7/20/2017 | 1:28:39 AM
Samaung addressing fragmentation issues
Some of the issues with Android fragmentation regarding security have been addressed by Samsung, and possibly other manufacturers within the Android community.

They now wrap up security updates into a standalone update, away from the whole OS update. They're able to push these out at any time without the need for telco approval.
Exploits Released for As-Yet Unpatched Critical Citrix Flaw
Jai Vijayan, Contributing Writer,  1/13/2020
Major Brazilian Bank Tests Homomorphic Encryption on Financial Data
Kelly Sheridan, Staff Editor, Dark Reading,  1/10/2020
New Attack Campaigns Suggest Emotet Threat Is Far From Over
Jai Vijayan, Contributing Writer,  1/16/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: It is too bad the ceiling is made of glass!
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-3686
PUBLISHED: 2020-01-17
openQA before commit c172e8883d8f32fced5e02f9b6faaacc913df27b was vulnerable to XSS in the distri and version parameter. This was reported through the bug bounty program of Offensive Security
CVE-2019-3683
PUBLISHED: 2020-01-17
The keystone-json-assignment package in SUSE Openstack Cloud 8 before commit d7888c75505465490250c00cc0ef4bb1af662f9f every user listed in the /etc/keystone/user-project-map.json was assigned full "member" role access to every project. This allowed these users to access, modify, create and...
CVE-2019-3682
PUBLISHED: 2020-01-17
The docker-kubic package in SUSE CaaS Platform 3.0 before 17.09.1_ce-7.6.1 provided access to an insecure API locally on the Kubernetes master node.
CVE-2019-17361
PUBLISHED: 2020-01-17
In SaltStack Salt through 2019.2.0, the salt-api NEST API with the ssh client enabled is vulnerable to command injection. This allows an unauthenticated attacker with network access to the API endpoint to execute arbitrary code on the salt-api host.
CVE-2019-19142
PUBLISHED: 2020-01-17
Intelbras WRN240 devices do not require authentication to replace the firmware via a POST request to the incoming/Firmware.cfg URI.