While this approach clearly increases the likelihood of data getting into the wrong hands, the risk is compounded with the fact that only one in five respondents back up their mobile devices, which can have significant impact on the availability of data. Consider that, in 2013, Transport for London (TfL) responded to a Freedom of Information request⁵ confirming that a total of 15,833 mobile phones were handed into its lost property department, with 2308 claimed by their owners, For tablets, there were 506 handed in, with 290 reclaimed by their owners.

This of course was only those devices handed into the TfL, and is a very small number compared with those mobile devices that actually go missing. In London, the Metropolitan Police estimate that up to 10,000 mobile phones are stolen every month, which when combined with those not stolen, but that are simply lost (there will likely be some overlap), the amount of data that goes missing each year across the globe will likely be significant. This of course justifies the decision to rank this particular threat as the highest. Particularly, as a third of these users are unlikely to have any form of security controls protecting the device. Not having any form of security controls will likely result in unauthorized attempts to access the data/applications on the device. In the Symantec Smartphone Honeystick project,⁶ 50 smartphones were released (as lost), and in almost all instances, attempts were made to access data on the device:

Although many organizations are likely to have some form of mobile management solution to manage mobile devices commissioned by them directly, there will be many more personal devices owned and managed by the employee. These are unlikely to have any form of security controls (based on the McAfee research this seems a fairly safe assumption), and should employees use such devices to store corporate data whether under the approval of their employer or not, then the loss of device will be nowhere as significant as the data getting into the wrong hands. In addition, the combination of these employee devices storing corporate data, and users installing apps with impunity, there is the risk with regards to the level of access such apps have to contacts, private pictures, social networking, Webmail, and passwords.

Furthermore, mobile malware is predicted to continue growing. According to McAfee Labs,

“In the last two quarters reported, new PC malware growth was nearly flat, while appearances of new Android samples grew by 33%.

While McAfee Labs expects this trend to continue in 2014 it’s not just the growth rate in new mobile attacks that will make news. We also expect to see entirely new types of attacks targeting Android.”⁸

The examples cited in the CSA Mobile Threats research are Zitmo, which is based on the Zeus malware intended to steal mobile transaction authorization numbers (mTANs) that are used for mobile banking. According to Kaspersky,⁹ Zitmo works in the following fashion:

This ofcourse is merely the tip of the iceberg regarding mobile-based malware, with others not only targeting the data on the mobile device but also, in the case of NickSpy, recording conversations and uploading them to a remote server. Alternatively, in the case of Dendriod, the ability to “take pictures using the phone’s camera, record audio and video, download existing pictures, record calls, send texts, and more.”¹⁰

Of course, one of the many reasons that mobile malware is growing at such an exponential rate is the relatively low adoption rate among users for security software. According to a survey¹¹ conducted by the National Cyber Security Alliance, three-quarters of US respondents have not installed security software on their smartphones.

If we take this number and then consider research by security firm BitDefender,¹³ which found that based on analysis of the 836,021 applications in the Play Store (at the time of conducting the research), 1 in 20 were able to locate and open photographs on installed devices. Equally, 1 in 30 divulged e-mail addresses over the Internet, with 1749 doing so over an encrypted connection and 1661 over an unencrypted connection. In addition, the research also found that almost 10% of apps had permission to read the contact lists on the mobile device. Of course, there is no suggestion that the applications themselves are doing anything malicious, indeed for Android, the user is provided with details regarding the permissions the application is requesting. However, there is no doubt that the level of transparency regarding what happens with the data, how it is transmitted, and what happens with the data once collected does not have the same level of transparency. Indeed, if we review the data protection authorities (Canada, Netherlands) investigation into WhatsApp, there is a disparity between what was stated (regarding how long data is stored and transmitted), and what actually happened.

The issue of leaky apps is clearly a key problem, and absence of transparency about how data are stored or transmitted poses an issue. Furthermore, the issue is compounded by the fact that consumers when provided with transparency (by at least knowing what permissions exist) either do not read or understand what data are being requested by the app in question. Therefore, the challenge for organizations in mitigating this particular threat is made considerably more difficult by an audience that do not understand the implications of allowing apps almost unfettered access to their devices, and ultimately corporate data. A recently publicized example of this was demonstrated with the “Flappy Birds” application. “The following example illustrates this: com.touch18.flappybird.app (3113ad96fa1b37acb50922ac34f04352) is one of the many malicious Flappy Bird clones.

Among its malicious behaviors, this clone does the following:

Allows an app to call the killBackgroundProcesses(String) (undeclared permission).”¹⁴

To put the issue into the context, the McAfee Labs team took a sample of 300 Flappy Bird applications, and of these, 238 was cited as malicious. This is the tip of the iceberg, but demonstrates the scale of the issue that is propagated by the simple acceptance of mobile applications without reviewing their permissions.

Known as the average defect density, according to research ¹⁵ conducted by security firm Coverity, the number of defects per 1000 lines of code is estimated to be 0.62. This figure is identical for open-source projects as they are for proprietary projects. Of course, there will be considerable debate about the actual figure, because the number of likely defects will be dependent on many other variables, such as the expertise of the programmer and quality assurance process. However, the intention of presenting these figures is to emphasize that vulnerabilities will always exist, and as we demand more features and interoperability, the risk will only get higher. Furthermore, the level of complexity associated with mobile platforms increases the likely security risk. For example, mobile applications will include the functionalities associated with desktop computing; they will, however, also include cellular communication capabilities.

There are multiple examples of vulnerabilities associated with mobile devices, operating systems (OSs), and applications. This includes those applications that are developed with information security in mind. In 2014, security firm IOActive reported ¹⁶ that the official mobile application for the RSA Conference contained half a dozen security vulnerabilities. According to Chief Technical Officer Gunter Ollman, the most significant of these vulnerabilities could allow an attacker the opportunity to conduct a man in the middle attack, inject malicious code, and potentially steal login credentials. Of course, the argument could be had that this is only an application for a conference (a security conference nonetheless), and that such vulnerabilities are unlikely to be present in applications that we use for more “important” tasks. However, research¹⁷ conducted again by IOActive found that 90% of mobile banking applications contained security vulnerabilities:

Of course, the above details are only the vulnerabilities associated with mobile applications, and the title with this threat includes the OS, as well as hardware. Indeed, when we consider vulnerabilities for mobile OSs, recent research would suggest that the number of identified vulnerabilities is increasing. According to Symantec,¹⁸ 2012 saw a 32% increase in the number of documented vulnerabilities. The security flaw associated with iOS 6 as detailed by Trend Micro provides a recent example of a mobile OS vulnerability. In this example, researchers revealed that when connected to a fake charging station, the security flaw would grant complete access to an iPhone or iPad on the iOS 6 platform.¹⁹

This particular threat has been classed as medium because, although vulnerabilities will exist, the number of exploits (in the wild) are very low.

And now plug in a mobile device.

Indeed, the proliferation of wireless networks means that mobile devices today have a choice of networks to connect to, ranging from cellular to wireless networks. With high international roaming charges, users are often far too willing to search and connect to any wireless network as long as it meets a very simple criteria, that it is free.

As expected, malicious actors understand this behavior and leverage rogue hotspots as a means to connect and compromise mobile devices of either passing users or to target specific individuals. According to the head of the European Cybercrime Centre, Troels Oerting, “We have seen an increase in the misuse of Wi-Fi, in order to steal information, identity or passwords and money from the users who use public or insecure Wi-Fi connections.”²⁰ Subsequently, organizations may want to consider an appropriate policy exists regarding the use of unknown wireless hotspots and implement appropriate controls to enforce such an action on the mobile devices of employees. Other approaches to dealing with insecure networks are to assume that any network is in itself untrusted and to rely on the device and applications to protect themselves. This particular approach follows the principles of the Jericho forum.

With such incentives, there is no surprise at the rise and popularity of third party app stores. For example, consider that the GetJar AppStore has a user base of 200 million, and the Opera Mobile Store has more than 1.8 million apps downloaded every day. These of course are a drop in the ocean compared with the actual number of stores available, and it is worth noting that, although they are used as an example to demonstrate the popularity of third-party stores, there is no suggestion that they do (or do not) host malicious content.

While there is no question that third-party stores are an attractive proposition to consumers for the reasons described earlier, they are the main delivery mechanism of malware. According to the H2 2013 Threat Report by F-Secure,²³ “the most common distribution channel for mobile malware continues to be via third-party app sites.” Compare this with the Official Google Play Store where research found that only 1 in 1000 applications were classed as malware. Comparing this against third-party app stores, the level of malware increases significantly, this is depicted in Figure 4.3, which highlights the malware rate associated with a number of app stores.

This of course only tells part of the story, as malware is not the only risk associated with mobile apps. The research found both Adware^a and Riskware^b found in the Google Play Store, as depicted in Figure 4.4.

Equally, avoiding malware-ridden apps takes more than simply downloading only known apps. A growing trend has been to repackage known applications to offer within a third-party app store. The research found that of the top 20 most popular apps within the Google Play Store, 8 had trojanized versions available in third-party markets. For the purposes of the investigation, trojanized versions were applications that “uses the original package and application name, but also requests more permissions than the original.”

Apple makes the argument that the in-built security features of the iOS architecture negates the need for antivirus software:

Of course, the argument made by Eugene Kaspersky is that the threat of malware on the iOS platform is not currently an issue; if, however, the issue does manifest itself, then addressing the problem will be considerably more difficult because of the closed nature of the platform. As the issue has not manifested itself as yet, the threat has been classed as medium, but the impact if (or when!) the risk is realized will be significant hence its inclusion.

While of course the benefits are well documented, and in certain cases being realized with projects across the globe, there is a growing number of risks associated with NFC. In fairness, a number of “hacks” associated with NFC have largely been proof-of-concepts, which explains why the threat has been classed as low; however, this will likely change. Examples of these “hacks” have taken place at conferences such as “Def Con”; one in particular was showcased by researchers who were able to hack an NFC-enabled device to get free transport on public services. Matteo Collura and Matteo Beccaro studied the security deployed for NFC-enabled cards in the Italian city of Turin. Attempting an NFC hack demonstrated against the San Francisco transport system at the same conference a year ago, they quickly discovered that the same issue was not present in Turin. However, upon further investigation, they found that there was a component within the ticket that is changed from 0 to 1 after each ride. By setting this sector to read-only mode, they were able to get “an unlimited-rides ticket.”²⁶ Another issue was a timestamp, which determined whether the ticket needed to be stamped was in an area of the ticket that could be changed, and any NFC-enabled device (such as a mobile phone) could potentially overwrite this date.

Of course, this is only one such issue and is not per se an issue associated with mobile devices, but rather those platforms that leverage NFC (where the mobile device can be used as the attack vector). The issue is also compounded by the fact that there are now applications being made available to leverage the security vulnerabilities in these platforms offering the would-be mobile user free use of public transport systems: “UltraReset which takes advantage of NFC vulnerabilities in the systems used by many public transit systems, including the New Jersey Path and San Francisco Muni trains where it was tested effectively.”²⁷

In 2012, it was reported²⁸ that security researchers were able to hack into a Samsung Galaxy S3 phone that was running Android 4.0.4 through the use of NFC to send the exploit. The researchers were able to exploit a weakness in the manner in which the S3 implemented NFC, they were able to deliver a malicious file that was automatically opened by the device. Once the application was opened the researchers were able to launch a second attack and ultimately gain full rights on the compromised device.

What this and the other examples demonstrate is that there are clearly vulnerabilities in which NFC support is implemented. Moreover, there is a burgeoning security research community that are actively investing time (and money) into identifying, presenting, and in certain cases developing applications that allow anybody the ability to exploit. Subsequently, the threat level is classed as low but the likelihood is that it will not remain at that level of too long.

The threats listed above are classed as the Evil 8, and based on the research conducted by the CSA Mobile Working Group ranked as the top threats to mobile computing. In fairness, these threats are not necessarily related to mobile in relation to cloud computing, but entirely focused on mobile platforms themselves. In certain scenarios, the advent of cloud computing can be used to mitigate some of these threats; for example, threat 1 (loss of device) can be mitigated with cloud computing. Where data is automatically backed up to a cloud service, the loss of the device and ultimately data on the device is mitigated because the data is backed up to online storage. Although it is worth noting that only the risk of loss of availability is mitigated, but the loss of confidentiality still remains.

Of course, this particular point is important, those risks threats within the Evil 8 are useful to understand but without any recommendations to address they are of limited value. It is for this reason that the “Security Guidance for Critical Areas of Mobile Computing” was developed by the Mobile Working Group. This document, in addition to presenting the Evil 8, also provides mobile components for consideration. These components are those areas that organizations should consider to reduce the risk of the Evil 8 (as well as other threats) being realized at their organization.

These components, and their detail, will be presented in the proceeding section. However, much like the remainder of the book we will avoid the Control + C and Control + V shortcuts and provide additional detail while not deviating from the true spirit of the recommendations provided by the Working Group.

There is no intention here to repeat the section on authentication as a whole, but rather focus on the authentication afforded on mobile devices. Within a mobile ecosystem there will exist multiple authentication boundaries; these are the boundaries between the various components within the mobile ecosystem and the methods these components use to establish trust in verifying their identity. This is demonstrated in Table 4.2.

Of course, the authentication methods available for the trust boundaries are likely to evolve as both technology and the industry evolves. On the latter part it is worth noting the work being conducted by the Fast Identity Online Alliance whose aim is to establish “interoperable set of mechanisms that reduce the reliance on passwords to authenticate users.”^c

The purpose of presenting the mobile authentication boundaries is to consider the levels of authentication available, and thereafter appropriate for the use case in question. For example, consider a use case where a mobile user is looking to gain access to personally identifiable customer-related data via a private cloud service. In this case, it will be appropriate to consider the mobile device boundaries, and where stronger controls can be enforced to achieve the level of assurance sought. Subsequently, the use of authentication at user to device is unlikely to be appropriate, and the level of assurance can be achieved between the user and application. Where the user is accessing data that is not personally identifiable and nonsensitive, authentication via the user to device boundary may be appropriate.

It is also worth considering that there are a number of attack vectors associated with the major authentication threats. These are listed in Appendix 1 (and taken from the CSA MWG Security guidance); this includes a series of countermeasures.

Although Figure 4.7 is an oversimplification of the process, it does demonstrate that the provision of mobile apps to the end user can take a number of routes. Furthermore, the dashed line (D3) is used to indicate a higher risk. However, the recommendation for end users and indeed the organizations that are tasked with supporting these devices is that the mobile device policy should clearly define where the end user is allowed to download apps from.

Some of the basic guidance end users should adopt are in the first instance to review the permission the app is requesting and determine whether the permissions requested are deemed too risky before downloading. Of course, there is no assurance that such an approach will address the issue as solely relying on people to make the right security decision can have varying results. Another option, or rather a supplementary approach for organizations is to consider utilizing whitelisting applications that an end user can download. This will demand the use of mobile device management software; however it will consume resources to test, verify, and regularly update the whitelist of approved applications.

Mobile technologies continue to become a critical component to almost every organization, and as such the need to provide a safe environment for their use is essential in ensuring their use can maximize the benefit to the end user and organization. The mobile nature of such devices when combined with cloud computing allows them to be a great enabler for more productive employees. However, there is no question that the emerging focus among nefarious actors is on these devices due to their popularity. This is supported through countless studies into the threat landscape, with, for example, mobile malware growth outstripping that of traditional PCs. Subsequently, it is imperative for organizations and consumers alike to consider the threats to their mobile devices and implement People, Process, and Technology-based controls to mitigate the risk to an acceptable level.