Tech risk professionals love to have debates about platform security, though it used to be Windows vs. Linux (really closed vs. open source) which morphed to Windows vs. Apple and is now Android vs. iOS. In any case, there are often numbers available to support one viewpoint or another. Let’s have a look and see if we can come to some conclusions.

For our latest debate – Android vs. iOS – there are three sets of numbers that have recently come into play for evaluation:

1. Number of vulnerabilities: A recent blog post on TheVerge.com highlights that iOS and its 238 vulns from 2007-2013 has 8.8x more vulnerabilities than Android’s 27 from 2009-2013.
2. Number of malware samples: In April, a Symantec report [PDF] pointed out that Apple’s 387 vulns in 2012 dwarfs Android’s 13 and yet Android had 103 “mobile threats” (malware) compared with Apple’s 1. Importantly, they also point out that “most mobile threats have not used software vulnerabilities.”
3. Percent of traffic: A paper presented at NDSS ’13 [PDF] monitored actual smartphone traffic and found that a) “The mobile malware found by the research community thus far appears in a minuscule number of devices in the network: 3,492 out of over 380 million (less than 0.0009%)” and b) “users of iOS devices are virtually identically as likely to communicate with known low reputation domains as the owners of other mobile platforms, calling into question the conventional wisdom of one platform demonstrably providing greater security than another“

Now, since we all know that security is the number one priority for IT decisions (heh), the CIO is waiting to hear from us on which platform is more secure. How do you answer?

Here’s my analysis, just using the numbers provided*

First, number of vulnerabilities as a measure is often thought of as a leading indicator of risk even though we all recognize that more vulns found equals fewer vulnerabilities remaining. The perception, however, is that there are actually even more vulns left. Absent of any other information, however, it is worth considering the notion that a higher number here is a measure of stronger security going forward (that is, #vulns is a lagging indicator). It doesn’t help matters that at least one of the sets of numbers inexplicably uses different time periods in its analysis. This measure would be much more useful if we had a way to normalize the numbers across platforms – the two most obvious ways would be with 1) a measure of complexity or size of the code base or 2) a measure of the personhours expended in looking for vulns. While I favor this latter option, it is not very practical.

The second measure, number of malware samples, is interesting because it is closer to the actual compromise. In addition, as Symantec points out many of them don’t exploit software vulnerabilities (this is another knock against using vuln counts). The challenge here is that there is essentially unlimited ability to create more malware samples. Moreover, the notion of a “mobile threat” is fairly broad and not always threatening to the extent that legitimate apps have some similar characteristics. Given the (somewhat) restricted methods for distribution and installation of apps on smartphones, a better measure would be to identify the distribution and accessibility to the population of these malware apps. In this case, getting an understanding of the number of downloads would get significantly closer to understanding the relative risk.

The final measure, compromised smartphones, provides a historical measure of actual infected phones. Aside from the really, really low number, we must decide whether these values are a good reflection of (future) risk or not. Since this number identifies compromised systems, it gets us closest to that which we are trying to prevent, which is useful. Ultimately, I believe this measure is the best of the three in helping us understand “risk” in the mobile world. And right now, it’s a tossup.

A better measure for determining which platform is more secure, in my opinion, would involve a measure of attack surface combined with one of devices sold (as a placeholder for activity volume and popularity).