BRIEFING PAPER SECURING MOBILE APPS LONG TITLE€¦ · Information Security Forum Securing Mobile Apps: Embracing mobile, balancing control 3 Each mobile device is a virtual gold

1 Frost&Sullivan,“TheSmartphoneProductivityEffect:QuantifyingtheProductivityGainsofSmartphonesintheEnterprise”,2016,www.samsung.com/us/business/short-form/the-smartphone-productivity-effect/ 2 Statista, “Number of mobile app downloads worldwide in 2016, 2017 and 2021 (in billions)”, 2018, https://www.statista.com/statistics/271644/worldwide-free-and-paid-mobile-app-store-downloads/ 3 Ponemon,“2017StudyonMobileandIoTApplicationSecurity”,2017,https://www.arxan.com/2017-Ponemon-Mobile-Iot-Study/ 4 Gartner,“GartnerSays40PercentofU.S.EmployeesofLargeEnterprisesUsePersonallyOwnedDevicesforWork”,2014,http://www.gartner.com/newsroom/id/2881217 5 Ponemon, “2017 Study on Mobile and IoT Application Security” 6 ibid.

Mobile applications, referred to as apps, are part of daily life. There are millions to choose from and people can use them on many devices, anytime, from anywhere. Significant business rewards can be gained from apps in terms of increased productivity, revenue and collaboration – and as a direct channel to customers. These apps are frequently relied upon to support critical business processes and handle sensitive information without any thought about risk. It’s all too easy to get caught up in the ‘magic of mobile’ and overlook security, the cost of which may be too high in terms of security incidents and business impact.

THE RISE OF THE MOBILE APPLow cost and ease of use has fuelled the rise of apps. Anybody, regardless of technical ability, can use an app to unleash the powerful features of modern mobile devices. Many of these features are often absent on desktop and laptop computers, such as: mobile network connectivity (e.g. 3G and 4G), accelerometers and global positioning system (GPS). Originally driven by consumer demand, apps have become central to daily life and are now becoming common in the workplace, with half of employees using apps mandated by their employer.1 The numbers speak volumes about increasing app popularity; 47 billion more apps were downloaded in 2017 than 2016, a one third increase.2

OUT OF SIGHT AND OUT OF CONTROLApps are subject to the same threats as any other business applications – and more of their own making. Apps operate on devices that can contain gigabytes of sensitive information, yet allow their users to disable security features and install apps of their choosing. Mobile devices are always on, continuously network connected, and have an affinity for being lost or stolen – yet typically lack the security protection afforded to IT systems. Consequently, app security is tightly interlinked with mobile devices and the environment in which they operate.

Organisations can face a dilemma when trying to secure apps. Too much control can dilute business benefits by locking down the mobile app environment. Too little control can lead to the environment being wide open, allowing unapproved insecure apps to run on devices unsuitable for business.

Figure 1: The mobile app risk spectrum

Locking down the mobile app environment may tempt individuals to side-step security controls to run their favoured, but unapproved and insecure apps on unmanaged personal devices. Both locking down the mobile environment or leaving it wide open can bring the same result: unapproved apps used for business. It is no surprise that 63% of organisations are not confidenttheyknowalltheappsusedintheworkplace.6

Even approved apps can impact security, particularly if not developed securely, used on unmanaged mobile devices or they rely upon insecure cloud services.

FINDING THE RIGHT BALANCEThis paper is written for individuals managing mobile apps and related devices. It describes the security challenges associated with acquiring, using and operating apps, then suggests actions to manage those challenges, while maintaining the business benefits from using mobile apps.

This paper helps to find the right balance between locking down the mobile app environment and leaving it wide open.

Locked down:– Approved apps– Trusted devices– Restricted environment

Wide open:– Any apps– Any devices– Anywhere

INCREASING RISK

50% of organisations have no budget for mobile security.3

60% of IT and IT security practitioners report their organisation as likely breached by an insecure app.5

50% of employees who choose to use their personal device for business, do so without their employer knowing.4

BRIEFING PAPER LONG TITLEBRIEFING PAPER SUBTITLE

SECURING MOBILE APPSEMBRACING MOBILE, BALANCING CONTROL

Information Security Forum2 Securing Mobile Apps: Embracing mobile, balancing control

7 IDC,“SmartphoneOS”,May2017,http://www.idc.com/promo/smartphone-market-share/os 8 Statista,“Percentageofmobiledevicewebsitetrafficworldwidefrom1stquarter2015to4thquarter2017”,2018,https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices/ 9 Google,“HowPeopleUseTheirDevices:WhatMarketersNeedtoKnow”,September2016,https://www.thinkwithgoogle.com/_qs/documents/276/twg-how-people-use-their-devices-2016.pdf

1 Apps and their environment

Mobile apps (apps) can be defined as applications installed on mobile devices. They are designed to work within the constraints of mobile devices (e.g. touch screen with virtual keyboard, a wide variety of screen sizes and shapes, and limited battery power). There are three main types of app:

‒ native apps, which are developed specifically for the mobile device on which they run

‒ hybrid apps, which use the same technology as a website but with a native app ‘wrapper’ installed to be the interface on a device

‒ web apps, which are websites that run code within a web browser.

Web apps are not specifically covered in this report because they are based on generic website technology and may be unable to leverage many mobile device features.

Mobile devices have become the consumer computing platform of choice: they originated half of website traffic in 20178 and consumers spent twice as much time on them as desktop/laptop computers.9 Mobile devices include smartphones, tablets and modern smart watches (wrist-worn smartphones capable of installing apps). Televisions, refrigerators, cars and other products that use mobile device operating systems are outside the scope of this report. Laptop computers are also outside scope, because unlike mobile phones and tablets, they are typically protected by an organisation’s security function and through IT governance.

APPS AND THEIR PURPOSEThe constraints of mobile devices have led to apps focusing on the most important and frequently used features; this simplification makes the resulting apps easy to use. Apps are intended for different uses, which can be categorised as consumer, business or both: examples of which are shown in Figure 2.

Figure 2: Intended use of mobile apps

BUSINESS CONSUMER

Accounting

Audits

Board papers

CRM

Document sharing

ERP

Expenses

HR

Invoices

Inspections/checklists

Marketing

Surveys

Work orders

CollaborationCommunication/messaging

EmailManaging passwordsNavigation/mapping

News and local servicesOffice suites and productivity

Payment servicesPhotos/drawingReading books

Social networking & blogsTravel and holiday

Transport Taking notesTranslating

Virtual assistants

Dating

Deals and loyalty schemes

Education

Entertainment & sports

Food & drink

Games

Health & fitness

Home automation

Lifestyle

Music

Personal finance

Shopping

Mobile apps are written to run on particular operating systems, of which Google and Apple are the prominent providers. Google provides the Android operating system, which is used by many device manufacturers. Apple is the sole manufacturer of devices for its iOS operating system.

IDC reported that Android held 85% of the smartphone market and Apple 14.7% in Q1 2017.7 Because many organisations produce Android devices, there is a large variation – also called fragmentation – in features available on Android devices.

Information Security Forum 3Securing Mobile Apps: Embracing mobile, balancing control

Each mobile device is a virtual gold mine of personal information about the individual using it. This can include a staggering amount of detail about calls, contacts, emails, SMS messages, websites, health, locations, routes, shopping habits, music, books, and photographs. Apps use this data to get to know their users and provide them with tailored services. Apps can also collect this personal information for many reasons, including: to sell it to other parties, tailor their services and target advertisements at their user.

Business useBusiness apps typically focus on enabling productivity away from the office desk, such as by taking notes, reading emails and using checklists. They also support an increasing variety of core business activities, including customer relationship management (CRM), enterprise resource planning (ERP) and board meetings.10

Organisations are increasing their use of apps: according to CITO Research, 97% of large organisations plan to expand their app portfolio.11

Apps can benefit organisations for many reasons, including business transformation,12 talent retention,13 increased productivity, communication, improved collaboration,14 increased revenue,15 and by creating a direct sales and marketing channel to customers.

Although apps may be intended for business use, this is no guarantee they meet particular business needs (e.g. reliable, stable design and adequate maintenance or support).

Consumer use Consumer apps typically focus on lifestyle, shopping and entertainment. They provide convenient, always-available and tailored services, such as locally relevant content (e.g. weather forecast, travel news and places to eat).

Many consumer apps are free to use, because they are funded through advertising or selling data collected from mobile devices. However, this data can include information that should be kept confidential (e.g. locations visited, contact details, internet searches and email content).

Some consumer apps are used for business purposes, for example by interacting with customers through a shopping app or advertising in a game; these can be relevant to security.

Dual use: business and consumerMany apps are useful to both consumers and businesses (e.g. for productivity, communication, password managers and collaboration). Individuals familiar with apps from personal use may leverage them for business purposes, often without formal procurement, authorisation or valid licensing.

There are 472 apps in an average organisation.16

According to a Ponemon survey, 66% of respondents downloaded mobile apps for business use without their employer’s approval.17

10AppCrawlr,http://appcrawlr.com/ios/anywhere-pad-mobile-meeting-pre 11CITOResearch,“2016ExecutiveEnterpriseMobilityReport”,2016,https://go.apperian.com/rs/300-EOJ-215/images/Apperian%202016%20Executive%20Enterprise%20Mobility%20Report_FINAL_20160216.pdf 12 RedHat, “90 Percent of Respondents to Red Hat Survey Plan to Increase Mobile App Development Investments in 2016”, BusinessWire, 12 November 2015, https://www.businesswire.com/news/home/20151112005332/en/90-Percent-Respondents-Red-Hat-Survey-Plan 13Glance,“UseAppDevelopmenttoIncreaseEmployeeRetention”,23August2017,https://thisisglance.com/use-app-development-to-increase-employee-retention/ 14 Frost & Sullivan, “The Smartphone Productivity Effect: Quantifying the Productivity Gains of Smartphones in the Enterprise”, 2016,

https://www.samsung.com/us/business/short-form/the-smartphone-productivity-effect/ 15 W. Hacker, “Increase conversion by removing friction in mobile user experience design”, Retail Dive,

http://www.retaildive.com/ex/mobilecommercedaily/increase-conversion-by-removing-friction-in-mobile-user-experience-design 16 Ponemon, “2017 Study on Mobile and IoT Application Security”17Ponemon,“TheSecurityImpactofMobileDeviceUsebyEmployees”,2015,https://www.ponemon.org/blog/the-security-impact-of-mobile-device-use-by-employees


MOBILE APP OPERATING ENVIRONMENTApps are dependent on a mobile app operating environment, which comprises many components and services. A large part of this environment can be thought of as wide open as it typically contains untrusted systems and devices whose security level is unknown and over which an organisation has little control. Figure 3 shows the components of a typical app’s operating environment, with managed components shown at the lower end of the risk spectrum on the left, and components of unknown provenance at the higher end of the risk spectrum on the right.18

Figure 3: The mobile app operating environment

Mobile devicesMobile devices can come with different levels of security assurance. At one end of the spectrum are company-owned, managed devices that have trusted provenance. At the other end are unmanaged devices of unknown provenance, which may be owned by an employee or external party.

Mobile devices run operating systems that are stripped down and security-hardened to meet mobile device constraints, enabling them to be treated like domestic appliances by their users that ‘just work.’

Mobile device users Device users cover the full spectrum of risk. At one end are individuals who can be influenced and overseen in their use of apps, such as employees, contractors and agency staff. At the other end are individuals whose use of apps cannot easily be influenced and overseen, including members of the public and potentially malicious parties such as hackers.

Cloud services Apps typically access remote services and servers, which are usually cloud-based, to provide their functionality (e.g. to store notes, take backups of information, translate a document or send messages). An organisation often has no control over these services because they are typically bundled with an app or device and cannot be changed. For example, Apple has confirmed it uses Google’s and Amazon’s public clouds as well as its own hosting services to store mobile device users’ data.19

Network connectivityA variety of wireless (e.g. Wi-Fi, 4G, Bluetooth) and wired (e.g. USB and Lightning) connections provide mobile devices with network access. Many of the older network technologies have security weaknesses (e.g. weak encryption on 2G20 and WEP 21) and there are various well-known means to attack wireless technologies (e.g. rogue access points22 and IMSI catchers23). As mobile devices can automatically switch network, an app’s traffic may at one moment traverse a secured network, and the next moment an insecure network or one controlled by a hacker. Even wired connections can compromise security through public charging points that have been modified to hack into devices via the USB or Lightning connection.24

“Every form of network connectivity a mobile device has is also a potential avenue of attack against the device.” – ISF Member

18 Risk is of course dependent on other factors, but those being equal, the level of assurance in the mobile environment is primary factor.19Apple,“iOSSecurity:iOS11”,January2018,https://www.apple.com/business/docs/iOS_Security_Guide.pdf 20 A.I. Gardezi, “Security In Wireless Cellular Networks”, Washington University in St Louis,23April2006,http://www.cse.wustl.edu/~jain/cse574-06/ftp/cellular_security/ 21 K. Beaver, P. T. Davis, D. K. Akin, “Understanding WEP weaknesses”, Dummies,http://www.dummies.com/programming/networking/understanding-wep-weaknesses/ 22JuniperNetworks,“UnderstandingRogueAccessPoints”,14September2015,https://www.juniper.net/documentation/en_US/junos-space-apps/network-director2.0/topics/concept/wireless-rogue-ap.html 23PKI,www.pki-electronic.com/products/interception-and-monitoring-systems/3g-umts-imsi-catcher/ 24Forbes,“5WaysABadGuyCanStealYourData”,2017,https://www.forbes.com/sites/forbesproductgroup/2017/04/19/5-ways-i-can-steal-your-data/

Locked down Wide openINCREASING RISK

Public networks,e.g. 4G/3G and

public Wi-Fi PublicEmployees

Company-owned and personaldevices (Managed)

Scope of EMM

wwwDatabase

Cloud services

Company-owned and personaldevices (Unmanaged)

Privateapp store

A

Vendorapp store

A

Third-party app store

A

Corporatenetwork


APP STORESApp stores are the main software distribution platform for mobile devices, containing a wide variety of different apps available for download. They provide software developers of all kinds – whether self-employed or large organisations, experienced or novice – with access to a market place comprising billions of potential customers and millions of organisations.

Vendor app storesMany mobile device vendors provide app stores (e.g. Amazon, Apple, Blackberry, Google, Microsoft and Samsung). Vendors produce devices pre-configured to access their app stores, verify apps comply with their content policies and typically prohibit adult content, malware and hidden functionality from their app stores. However, the verification approach varies between vendors and does not ensure apps are suitable for specific business uses.

The vendors' app stores, in general, allow apps to harvest copies of data from mobile devices as long as the app is transparent about the data collected. Apps typically do this by requesting permission, leaving it to the app user to decide whether it is acceptable for the app to harvest particular data. The data harvested (e.g. location, contact details and photographs from the camera) may be important for app functionality, depending on the purpose of an app.

Because mobile devices are typically configured to install apps from their respective vendor’s app store, the vendors retain significant control over apps that can be installed on the devices they produce. To provide customers with an app will typically require going through vendor app stores or developing a web app.

Apps distributed through a vendor app store must be updated via the app store, even if the updates are to fix security vulnerabilities. This enables device vendors to verify the suitability of updated apps, but also allows app users, who may not understand the significance of updates, to ignore applying them.

Third party app stores Various organisations operate publicly available app stores (e.g. Aptoide, Droidapk and F-Droid), which are popular in countries where certain vendor app stores are unavailable or restricted. Typically, they have fewer constraints than vendor app stores, for example, by not censoring the content of apps nor requiring apps to be coded a certain way.

Private app storesAn organisation can control who is able obtain its apps and which apps a device can install by maintaining a private app store with an approved set of apps and restricted access. Private app stores are used by approximately one third of organisations surveyed by CITO Research.26

THE MOBILE APP LIFECYCLEApps typically have a lifecycle similar to a software development lifecycle (SDLC), as shown in Figure 4.

Figure 4: The mobile app lifecycle

Requirements Design Development Deployment Operations Disposal

However, apps often miss some lifecycle stages because they have been obtained without following an authorised procurement process. Consequently, apps are often acquired without:

‒ applying the underlying IT and security operations of a typical business application

‒ going through the important requirements, design and development stages of the lifecycle.

Such unauthorised apps are a type of ‘shadow IT.’

For further detail on the application lifecycle refer to the ISF report Application Security: Bringing order to chaos.

46% of ISF Benchmark respondents do not protect information throughout the lifecycle of a mobile device.

25P.Yip,‘AppLocalizationinChina:YourGuidetoChina’sAndroidAppStore’,2016,http://www.oneskyapp.com/blog/chinese-app-stores/ 26CITOResearch,“2016ExecutiveEnterpriseMobilityReport”,2016,https://go.apperian.com/rs/300-EOJ-215/images/Apperian%202016%20Executive%20Enterprise%20Mobility%20Report_FINAL_20160216.pdf

>200 Android mobile app stores in China.25


2 Apps: understanding the security challenges

Apps have enabled a revolution to take place in computing: cashless transactions; ride hailing apps; direct channels from businesses to their customers available 24 hours a day; free international telephone calls and free video conferencing. Despite the successes of apps and them becoming part of daily life, apps are not without their security challenges. Research identified nine main security challenges that apply throughout the lifecycle of apps, as shown in Figure 5. Each challenge is described in more detail on the following pages.

Figure 5: The nine main app security challenges










A: Unauthorised procurement

CHALLENGE LIFECYCLE STEP

B: Developed with security vulnerabilities

C: Installation of potentially harmful apps

D: Unapplied security updates

E: Inadequate IT and security support

F: Insecure user behaviour

G: Unreliable mobile device security

H: Limited security assurance in an app’s operating environment

I: Sensitive information not erased securely

Understanding these challenges is important. As more currency and valuable information flows through mobile apps, the motivation and capability of malicious entities will increase; potentially turning security challenges into business issues.

Hackers leverage these security challenges to attack organisations by hacking mobile apps. Such hacking, which includes tampering, debugging or reverse engineering, may be performed without detection because organisations typically lack the capability to observe attacks against many of the apps in use, particularly those running on unmanaged devices.

The challenges from apps are further exacerbated because, whether authorised or not, apps are often:

‒ poorly integrated into security services such as malware protection, intrusion detection and incident response

‒ managed with less diligence than other types of business application, even if they support critical business processes.

Failure to address the security challenges associated with apps may result in serious business impacts, such as prolonged outages, exposure of sensitive information or unreliable services. But these impacts can be managed or prevented by finding the right balance of control, enabling the effective exploitation of mobile apps.


27Ciphercloud,“CloudAdoption&RiskinNorthAmerica&Europe”,2014,http://pages.ciphercloud.com/rs/ciphercloud/images/CipherCloud-Cloud-Adoption-and-Risk-Report.pdf 28OWASP,“MobileTop102016-Top10”,https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10 29 L. Franceschi-Bicchierai, “How a Hacker Can Take Over Your Life by Hijacking Your Phone Number”, Motherboard, 4 May 2016,

https://motherboard.vice.com/en_us/article/mg7bd4/how-a-hacker-can-take-over-your-life-by-hijacking-your-phone-number30NowSecure,“MobileBankingApplications:SecurityChallengesforBanks”,2017,https://www.nowsecure.com/ebooks/mobile-banking-applications-security-challenges-banks/

A: Unauthorised procurement


App stores, when coupled with modern mobile devices, make it easy for employees to obtain a wide range of apps without authorisation. This is a type of shadow IT, which is unauthorised IT. Shadow IT often meets legitimate business needs, such as communicating with customers via their mobile devices, sharing files with clients and translating emails from a supplier. Individuals can acquire, deploy and use these apps with less effort, quicker and cheaper than going through their IT department or procurement process.

Unauthorised apps are not subject to formal requirements, design and development lifecycle stages of the SDLC, which ensure business and security requirements are identified and met. Consequently, they can create security-related issues including:

‒ inadequate ‘non-functional’ qualities such as a lack of:• security (e.g. not encrypting data, not validating certificates and weak authentication) • scalability (e.g. responding too slow, storing too few records and an inability to add more users)

‒ misalignment with strategy (e.g. diverging from a preferred platform and duplicating a product already in use)

‒ non-compliance with legal, contractual and regulatory obligations (e.g. not keeping business records, unacceptable contractual terms, not covered by e-discovery tools, and non-conformance with sector-specific regulations)

‒ unmanaged risks from the developer (e.g. developer discontinues the app, changes the service or ceases trading)

‒ being used on unmanaged or insecure devices (e.g. personal devices not covered by a ‘bring your own device’ (BYOD) programme).

Further information on BYOD risk can be found in the ISF report Managing BYOD Risk: Staying ahead of your mobile workforce.

B: Developed with security vulnerabilities


There are often security vulnerabilities discovered in apps, many of which are well known and avoidable.28 These vulnerabilities may exist in part because of the use of rapid application development tools and freely available software components (e.g. libraries and code published on the internet). These tools enable developers with limited security acumen to quickly deliver functioning apps, unaware they contain security vulnerabilities that any low-skilled hacker could easily find and exploit.

The multi-faceted environment in which apps operate can have vulnerabilities that affect the security of apps and the data they process. Examples of these vulnerabilities include insecure development environment; poor access control on cloud storage; and mobile network providers being tricked by hackers who take over mobile phone numbers.29 Such vulnerabilities can be difficult for an organisation to detect, due to limited visibility of them.

Apps and mobile devices are widely used, making attractive targets for hackers. Hackers can keep probing apps and the apps’ operating environment until a vulnerability is found they can exploit. This can be done by hacking the apps installed on mobile devices they own, without fear of detection, because those devices are typically unmanaged and not visible to an organisation’s security monitoring.

A vulnerable app, mobile device or operating environment could have far-reaching consequences for many organisations who were not directly targeted, but have still been breached. An organisation may not know a vulnerable app or app’s operating environment has been exploited until a security incident occurs and the impact is directly felt or reported publicly.

86% of applications in a typical enterprise are shadow IT according to Ciphercloud.27

100% of the North American mobile banking apps tested by Nowsecure each had at least one security issue.30


C: Installation of potentially harmful apps


While third-party app stores reportedly contain more potentially harmful apps than those provided by vendors, hackers are continually seeking to bypass the security of vendor app stores to access billions of potential victims.31 Sometimes hackers succeed,32 introducing potentially harmful apps into the app stores, which are then downloaded and installed on mobile devices.

Apps can be classed as potentially harmful if they enable various types of fraud (e.g. SMS, billing, and call fraud) or contain Trojans (hidden malicious functionality), such as:

‒ ransomware: demanding payment to return control or return access to stolen/encrypted data

‒ spyware: transmitting sensitive information without consent.34

Hackers may create potentially harmful versions of an organisation’s publicly available apps, by taking a copy and inserting malicious code.35 They do this with the intention of these ‘clones’ or ‘imitations’ being installed instead of the genuine app. Clones are potentially harmful to both individual app users and the organisation. They can also harm the brand of the genuine app even if the malicious code does not directly affect the organisation.

Apps can affect information security by requesting permission to access features and information unnecessary or excessive for their operation. Permissions, often described in unclear language, can grant apps virtually unlimited access to mobile devices (e.g. to record audio, read message contents and track internet browsing).

However, there are many features of mobile devices and a variety of information that apps can access, without needing to ask permission. Consequently, these permissions cannot be relied upon to provide comprehensive access control.

Research identified a torch app that illuminates the device’s camera light.37 The app requires the following permissions, most are unnecessary for its purpose:

‒ Monitor, record or perform processing on SMS messages ‒ Read and write contacts data ‒ Access the list of accounts ‒ Record video and audio ‒ Write to external storage ‒ Broadcast sticky intents

‒ Access fine (e.g. GPS) and course (e.g. Mobile-ID, Wi-Fi) location ‒ Open network connections ‒ Access information about networks ‒ Access the camera ‒ Modify global audio settings

‒ Access extra location provider commands

An example of excess permissions

31 B. Barth, “Third-party app stores riddled with malicious apps, Trend Micro warns”, SC Magazine, 11 February 2016, https://www.scmagazine.com/third-party-app-stores-riddled-with-malicious-apps-trend-micro-warns/article/528365/

32 BBC, “Apple App Store malware 'infected 4,000 apps'”, 23 September 2015, http://www.bbc.co.uk/news/technology-34338362 33BBC,“FakeWhatsAppappdownloadedmorethanonemilliontimes”,6November2017,http://www.bbc.co.uk/news/technology-41886157 34Google,“TheGoogleAndroidSecurityTeam’sClassificationsforPotentiallyHarmfulApplications”,February2017,https://source.android.com/security/reports/Google_Android_Security_PHA_classifications.pdf 35 Check Point, “How the CopyCat malware infected Android devices around the world”, 6 July 2017, https://blog.checkpoint.com/2017/07/06/how-the-copycat-malware-infected-android-devices-around-the-world/ 36McAfee,“FlappyBirdClonesHelpMobileMalwareRatesSoar“,2014,https://www.mcafee.com/uk/security-awareness/articles/flappy-bird-clones.aspx 37Torch,https://www.amazon.co.uk/Developer-Infotek-Torch/dp/B00JEB3MOW/

79% of the 300 ‘flappy bird’ clones analysed by McAfee were malicious.36

Over 1 million downloads of a potentially harmful clone of the WhatsApp messaging app were reported.33


38NowSecure,“MobileBankingApplications:SecurityChallengesforBanks”,2016,https://www.nowsecure.com/ebooks/mobile-banking-applications-security-challenges-banks/

D: Unapplied security updates


Apps, like any software, can require updates/patches to improve functionality and remove security vulnerabilities. However, the lack of control over apps and their operating environment, when compared to other business software, can lead to vulnerable apps processing sensitive information. There are many reasons for this:

‒ Users may decline updates, because: they do not understand the importance of updates; simple oversight; their devices lack the capacity to install the updates; and they are connected to a slow, unreliable or high tariff network.

‒ The app’s developer has ceased trading.

‒ There is no responsibility assigned for supporting an app or its related components (e.g. the app uses publicly available shared libraries that are no longer maintained, and the app was written by an amateur developer as a hobby).

‒ Developing and testing apps and updates for many different types and models of mobile device requires more effort than a typical desktop app.

‒ Developers not providing regular updates (e.g. they have prioritised other work and the app has reached its end of life).

Consequently, a preventable security incident could occur due to a business dependence on apps that are not supported or have not been updated to remove security vulnerabilities.

E: Inadequate IT and security support


Apps can be easily deployed and used without the formal onboarding typically applied to other types of business application. Onboarding ensures appropriate support tasks are performed, which includes providing adequate help to app users, conducting routine maintenance, investigating incidents (including security incidents) and planning capacity.

Without formal onboarding there can be a business dependence on apps that lack operational support from the IT and Security function, including help desk, trouble shooting, and incident response. A lack of support may not appear to be a significant problem until the consequences are felt, such as when services are affected and there is no assigned owner to remediate the problem.

F: Insecure user behaviour


Most mobile apps, because they have fewer features and limited configuration options, are simple to use when compared to traditional business applications. But that simplicity does not prevent app users unintentionally causing security breaches, for example by:

‒ downloading unauthorised apps

‒ using a mobile device insecurely, such as by creating a weak password, allowing others to use the device, and losing it

‒ becoming the victim of a social engineering attack, such as being tricked into installing malware or divulging a password.

Insecure user behaviour may be unnoticed until a security incident occurs and the impact is directly felt or reported publicly.

43% of mobile device users do not use a passcode, PIN or pattern lock on their devices.38


G: Unreliable mobile device security


Modern mobile devices are security-hardened with layers of state-of-the-art security controls. These controls often include code signing, sandboxing, hardware-based encryption, secured data storage, biometric authentication and remote wiping of lost or stolen devices.39 However, organisations and app developers cannot rely upon devices having all these controls applied, because:

‒ not every device is new; older devices may lack some state-of-the-art security controls

‒ there are multiple device manufacturers producing a variety of devices, with cheaper devices lacking some features

‒ security controls can be disabled by the device user (e.g. jailbroken, rooted, encryption disabled, and lock screen disabled)

‒ malware can be installed, or security can be breached by hackers or other malicious parties.

Consequently, critical business apps may be running on mobile devices that do not provide a sufficient security foundation.

45% of Benchmark respondents do not require users to refrain from tampering with mobile device security (e.g. jailbreaking and rooting).

H: Limited security assurance in an app’s operating environment


The functionality of apps is typically dependent on an operating environment comprising a range of products and (cloud) services, from multiple suppliers – many of whom an organisation will have no direct relationship with, visibility of, or control over. Consequently, there is often little assurance that the environment is suitable for processing, transmitting or storing business information because the environment may be:

‒ delivering an unsuitable level of service (e.g. reliability, recoverability and scalability)

‒ providing inadequate security

‒ lacking compliance with an organisation’s legal, regulatory or contractual obligations.

I: Sensitive information not erased securely


Apps and their data may remain on devices long after there is no business requirement. This may be because the app user failed to delete it (e.g. due to lack of awareness or oversight) or there is no formal process.

Even after deletion of an app or disposal of a mobile device, sensitive information (e.g. personally identifiable information, financial information or even authentication credentials) may remain on the device, which can be recovered by forensically analysing the device’s storage.

31% of Benchmark respondents do not use encryption to protect sensitive data on mobile devices.

MANAGING THE INFORMATION SECURITY CHALLENGESUnderstanding and meeting the security challenges from the multi-faceted operating environment of apps is vital to exploit the potential benefits of apps in an effective and secure manner. The next section includes suggested actions to help address these challenges, whilst balancing the need to lock down devices with the benefits of operating in a wide open mobile app environment.

39 A. Hayran, M. Igdeli, C. Gemci, “Security Evaluation of IOS and Android”, International Journal of Applied Mathematics, Electronics and Computers, 9 August 2016, http://asosindex.com/cache/articles/security-evaluation-of-ios-and-android-f166139.pdf


3 Securing app use

This section describes a set of suggested actions for addressing the nine security challenges described in part 2. Each suggested action corresponds directly to a challenge. Consequently, suggested action A: Reduce unauthorised acquisition of apps, corresponds to challenge A: Unauthorised procurement. Each suggested action comprises one or more controls to help achieve its objectives.

This section does not cover generic governance and programme management tasks such as determining ownership, allocating responsibility, setting objectives, defining a policy and obtaining resource. These topics are very important to secure the use of apps effectively, but are typically processes already defined within an organisation.

Securing apps is best performed with support from senior leadership. There may also be existing functions with a vested interest (e.g. a digital strategy team or mobile centre of excellence) that should be involved.

Any initiative to secure apps should involve the privacy function to help comply with relevant privacy regulation, because the devices on which apps run typically contain large amounts of personal data.

“Securing mobile apps is best performed as a programme that considers the wider picture, including mobile devices and mobile working.” – ISF Member

A comprehensive and up-to-date inventory of apps, coupled with an understanding of their criticality and how they affect information risk can help determine how to apply the suggested actions. Because many apps can be beyond the reach of automated discovery tools, workshops, interviews and questionnaires may be required to produce an app inventory.

For further information on defining a programme for securing applications, refer to section 6 of the ISF report Application Security: Bringing order to chaos.

40MobileIron,‘MobileSecurityandRiskReview,SecondEdition’,2016,https://www.mobileiron.com/en/quarterly-security-reports/q2-2016-mobile-security-and-risk-review

No discussion about app security could be considered complete without including Enterprise Mobility Management (EMM). EMM is a term covering products and services used by leading organisations to centrally manage mobile devices, apps and the information apps process.

EMM capabilities, as shown in Figure 6, are often categorised as mobile device management (MDM), mobile application management (MAM) and mobile content management (MCM). The capabilities include applying and enforcing a device security policy, securing network communications, installing and removing apps and checking the security status of devices.

63% of Benchmark respondents, in all or most cases use EMM to centrally manage mobile devices.Refer to The ISF Standard of Good Practice for Information Security (the Standard) Topic PA2.2 for more detail about EMM.

However, EMM has several shortcomings as it: ‒ is unlikely to be installed on every mobile device processing an organisation’s data, such as those owned by employees and customers ‒ can, if overly restrictive (e.g. preventing email attachments and disabling the camera), motivate employees to install the apps they want on unmanaged devices

‒ aids app security only if applied effectively.

MobileIron reports that only 8% of organisations with EMM force updates to devices (including updates to fix vulnerabilities) and only 5% identify apps exhibiting behaviour deemed unacceptable to security.40

ENTERPRISE MOBILITY MANAGEMENT (EMM)

MDM- Securing device configuration- Wiping data and device, remotely- Authenticating device - Securing device communications (VPN) to corporate services

MAM- Enabling private app store- Providing a secured app container- Wiping app data remotely- Authenticating user to an app- Securing app communications (VPN)

MCM- Providing secured data container- Preventing unauthorised data sharing - Controlling access to data- Pushing data to mobile devices

Figure 6: EMM capabilities

Enterprise Mobility Management


SUGGESTED ACTIONS TO SECURE MOBILE APP USEThe suggested actions contain a range of security controls, which can be tailored to meet the requirements of individual business circumstances, and should be risk-based. One approach for applying an appropriate, balanced set of security controls is to:1. define three security levels based on criticality/potential impact: locked down for mission-critical (high risk) processing

middle ground for intermediate (medium risk) and wide open for negligible (low risk)2. assign a security level to apps, using appropriate criteria (e.g. type of app, its criticality and sensitivity of information handled)3. apply the controls outlined in each suggested action, depending on the security level assigned.

The categorisation could be based on the impact assessment step of an information risk assessment, such as IRAM2.

The following table shows an example of how suggested actions could be tailored, dependent on the level of security required.

SUGGESTED ACTIONS SECURITY LEVELLocked down Middle ground Wide open

A: Reduce unauthorised acquisition of apps

Apply full acceptance criteria Apply partial acceptance criteria Consider acceptance criteria

Implement full app procurement process

Implement partial app procurement process

Consider elements of the procurement process

Mandate use of authorised apps Provide a catalogue of unauthorised apps Promote the use of authorised apps

Provide temporary amnesty for unauthorised apps

Allow ongoing amnesty for unauthorised apps

Allow ongoing amnesty for unauthorised apps

B: Develop secure apps

Comply with a secure app development process

Employ a standard development process Develop using a defined process

Test app security on a regular basis Test app security prior to live operation Consider elements of security testing

C: Prevent the use of potentially harmful apps

Use private app stores Use trusted app stores Use app stores with care

Remove potentially harmful apps

Remove potentially harmful apps

Remove potentially harmful apps on an ad hoc basis

D: Manage security updates

Force security updates Distribute security updates Apply updates on an ad hoc basis

Prohibit poorly maintained apps

Avoid poorly maintained apps

Warn users if poorly maintained apps identified

Mitigate vulnerable apps Mitigate vulnerable apps Warn users if vulnerable apps discovered

E: Provide operational support

Integrate fully with IT and security operations

Integrate partially with IT and security operations

Consider operational integration

Respond immediately to security issues Triage security issues to prioritise response Respond to serious security issues

F: Reduce security breaches caused by app users

Provide full support to users Provide ad hoc support to users Support on a self-service basis

Create detailed online help Create summary online help Consider creating some online help

G: Manage risks from insecure mobile devices

Detect and mitigate security issues Detect and monitor security issues Detect security issues on an ad hoc basis

Manage device security Monitor device security Consider device security

H: Provide assurance over mobile app operating environment

Identify risks in operating environment Understand operating environment Assume operating environment is insecure

Treat risks in operating environment Monitor risks in operating environment Be aware of risks in operating environment

I: Store and erase sensitive information securely

Store all data securely Store sensitive data securely Assume data is not stored securely

Decommission apps securely Decommission apps Delete apps and data when no longer required

Verify all information has been erased securely

Verify sensitive information has been erased securely

Promote awareness of how to securely erase data


A: Reduce unauthorised acquisition of apps


Unauthorised procurement of apps can be reduced by applying acceptance criteria, implementing an app procurement process, publishing a catalogue of approved apps, and allowing an amnesty for unauthorised apps.

“Blocking certain apps isn’t the answer, workers will just migrate to unblocked apps that may be less well known and less secure.” – Forbes.41

Apply acceptance criteriaDefine and apply acceptance criteria to ensure that business and security requirements are understood, validated and approved before apps are acquired or developed. Suitable acceptance criteria may include having:

‒ defined business attributes (e.g. defined ownership, purpose, specification of functional and non-functional requirements)

‒ specified security requirements (e.g. authentication, encryption, risk assessment and security testing)

‒ reputable source with terms (contractual and licensing) appropriate for a business application.

Implement an app procurement processAmend or create a formal process for procuring apps, including those acquired from vendor app stores. To help prevent employees from bypassing the process, ensure it is fair, simple and quick to use. The process should include confirming an app meets acceptance criteria, understanding information risk, maintaining the app inventory, tracking licences and onboarding the app into IT and security operations.

Publish a catalogue of authorised appsPublish a catalogue of approved apps, that individuals are free to use, which will help to limit use of unauthorised apps. The catalogue should specify the approved purpose and any conditions attached to using the apps such as use for medium-risk processing, not processing sensitive information, and device managed by EMM.

Allow amnesty for unauthorised appsRun an amnesty, allowing individuals to report the unauthorised apps they use for business. Then use the app acceptance criteria to validate whether they are suitable for business use and sufficiently secure. If unauthorised apps have a valid business case, they may be put through the formal procurement process or a suitable alternative app provided. Unsuitable or insecure apps should be removed from devices.

When providing apps to customers or clients, a full information risk assessment should be performed. This can help to mitigate the risks specific to the app by considering factors such as the information processed and potential impact. These apps should be hardened and able to withstand the threats from a wide open operating environment. There should be appropriate operational support to detect and deal with actual and suspected security incidents.

Refer to IRAM2 for details of how to perform a full information risk assessment of a mobile app.

41 G. Dutton, “What Do Mobile Applications In The Workplace Mean For Information Security?”, Forbes, 20 July 2015, https://www.forbes.com/sites/sungardas/2015/07/20/what-do-mobile-applications-in-the-workplace-mean-for-information-security/


B: Develop secure apps


Security vulnerabilities can be limited by employing a secure development process that identifies threats that apps face and uses testing to verify that vulnerabilities in apps have been adequately addressed.

Employ a secure development processDefine and employ a secure development approach for apps the organisation develops, which may include:

‒ identifying and mitigating the risks apps face (e.g. by applying the strong encryption capabilities of mobile devices, hardening app code, securing network communication and using EMM)

‒ determining how app security is measured (e.g. vulnerabilities per lines of code; number of high, medium and low vulnerabilities; total number of vulnerabilities; and trend of vulnerabilities)

‒ specifying the type and version of mobile devices and operating systems supported

‒ providing assurance over the level of security in supporting systems and services (e.g. through testing, certification and contract)

‒ validating app security against defined criteria (e.g. such as OWASP Mobile Top 1043 and NIST 800-16344)

‒ stipulating what type of security vulnerability should be remediated before an app can be released.

Test app security Use independent testing services to periodically verify the security of apps. Testing should be:

‒ relevant to apps and the environment in which they operate, and may include a wide range of possible tests, such as reverse engineering, forensic analysis of storage, and interception and manipulation of communications

‒ commissioned, by considering factors such as risk, the criticality of the app, sensitivity of information handled, when the app was last tested and the reputation of the app developer.

Refer to Category SD of the Standard, for details about software development and acquisition. Refer to the ISF report Embedding Security into Agile Development for further detail about secure software development.

42 Ponemon, ‘2017 Study on Mobile and IoT Application Security'43 OWASP, “Mobile Top 10 2016-Top 10”44NIST,‘VettingtheSecurityofMobileApplications’,2015,https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-163.pdf 45 This should be a periodic task, as should penetration testing of any business application.

According to a Ponemon survey, 69% of respondents cited the rush to release as the main reason for vulnerabilities in mobile apps.42

Only 29% of apps, on average, are tested by organisations for vulnerabilities.45


C: Prevent the use of potentially harmful apps


The use of potentially harmful apps can be reduced by using trusted app stores and removing potentially harmful apps.

Use trusted app storesObtain apps from stores that typically can be trusted to verify their security, such as vendor app stores. Distribute apps that support critical business processes or handle sensitive information through a private app store.

Remove potentially harmful appsMaintain a blacklist of relevant apps that may be potentially harmful, including those that contain Trojans or malware, and clone apps (those that closely resemble corporate apps). Establish a process for handling potentially harmful apps, which may include:

‒ identifying and removing them (e.g. using EMM and manual processes)

‒ requiring app stores to remove clones

‒ communicating the risks from the potentially harmful apps and actions app users can take to protect themselves and the organisation.

D: Manage security updates


The risks from unapplied security updates can be reduced by distributing security updates, avoiding poorly maintained apps and mitigating against vulnerable apps that have not had updates applied.

Distribute security updatesEstablish processes for the timely installation of security updates, which may include:

‒ monitoring threat intelligence feeds, vendor feeds and public domain sources of information to identify the need to update apps

‒ requiring developers to produce updates

‒ prioritising development effort to the production of fixes for vulnerabilities

‒ publishing updated apps in the vendor app stores

‒ using EMM to push updates to mobile devices

‒ communicating to app users the importance of applying security updates and the risks arising when these updates are not applied.

Avoid poorly maintained appsAcquire apps only from developers that have a reputation for diligent app maintenance and effective handling of security issues. Require app developers to produce security updates for the expected life of the app, and consider terminating the use of apps that are end of life.

Mitigate vulnerable appsProtect against the risks from apps with known vulnerabilities, that have not been updated or patched such as by:

‒ limiting the level of access an app has (e.g. by blocking webmail to legacy web browsers and blocking the capability of an insecure customer app from making online purchases)

‒ replacing a vulnerable app with one similar, whose developers remediate vulnerabilities

‒ informing app users of the risks and the organisation’s approach to dealing with a vulnerable app (e.g. limiting access).


E: Provide operational support


Poor operational support of apps can be prevented by integrating mobile apps into IT and security operations and responding to security issues effectively.

Integrate mobile apps with operationsApply standard processes to integrate apps with IT and security operations, which includes deploying them in a planned manner and providing operational support. The processes may require linking to the app procurement process so new apps can be ‘onboarded’ securely. Apps that have bypassed procurement should be identified, for example, by using EMM and allowing app users an amnesty, so apps can be onboarded. Apps that are no longer in use should be removed from operational support (‘offboarded’).

Operational integration should ensure important operational tasks that may affect security are performed, such as capacity planning, vulnerability management and change management.

Provide app users with the level of technical support commensurate with the app’s purpose and criticality, which may include providing a help desk, trouble shooting, communicating with the app vendor’s support teams and replacing broken devices.

Respond to security incidentsAmend or create an information security incident response process to cover the use of mobile apps. The process should ensure that security teams can deal with incidents and liaise with the vendors’ support team to investigate suspected incidents. The process should include app specific topics, such as performing mobile device forensics and initiating a remote wipe of devices and information.

F: Reduce security breaches caused by app users


Security breaches caused by users can be reduced by providing them with support and creating online help, so they can understand the security issues related to apps.

Support mobile app usersHelp individuals to use mobile apps and devices securely by providing security training, awareness and support. Training should include:

‒ highlighting information risks relating to mobile app and device use (e.g. potentially harmful apps and third-party app stores)

‒ explaining how to acquire and use approved apps, report security incidents and secure mobile devices (e.g. lock screen, device encryption and applying updates).

Create online helpMaintain online help material that can be accessed by app users (e.g. employees, contactors and external parties). The material should include:

‒ describing the correct, secure use of apps

‒ answering frequently asked questions

‒ showing where to go for further help

‒ reporting security incidents.

59% of Benchmark respondents do not cover the use of employee-owned mobile devices in security awareness training.

46 J. Peck, “GoCanvas Survey Indicates Growing Comfort with Shadow IT as Mobile Business App Usage Increases”, GoCanvas, 2016, https://www.gocanvas.com/content/blog/post/canvas-survey-indicates-growing-comfort-with-shadow-it

61% of businesses created a new mobile app without IT involvement.46


G: Manage risks from insecure mobile devices


Information risks associated with the use of insecure mobile devices can be mitigated by detecting security issues and managing device security.

Detect security issuesCreate or amend a process for detecting and responding to security issues relating to insecure devices, which may include:

‒ collecting security events from mobile devices and apps using EMM

‒ detecting suspicious events within the services accessed or used by an app to provide its functionality (e.g. large transfers of data and logon attempts to multiple different accounts from a single source)

‒ analysing security events, by using a security information and event management system (SIEM) or similar

‒ triggering the incident response process.

Analyse occurrences of security-related issues so trends can be reported to management and the effectiveness of actions to secure apps can be measured.

Manage device securityConfigure devices to provide an appropriate level of security, whilst maintaining the benefits of mobile devices and apps, which may include:

‒ using EMM to apply a device security policy (e.g. screen timeout and lock screen password) and to check for insecure devices

‒ containerising or virtualising apps to control information stored on the mobile device

‒ scanning mobile devices for vulnerabilities and malware

‒ procuring devices only from a trusted supplier

‒ limiting or blocking access to devices with known vulnerabilities (e.g. an unsupported OS).

50% of Benchmark respondents do not check the security configuration of mobile devices before granting access to the corporate network.


H: Provide assurance over mobile app operating environment


The level of security assurance over mobile app operating environments can be increased by identifying and treating risks in each operating environment.

Identify risks in operating environmentBuild an understanding of the architectural components of an app’s operating environment to determine where security assurance is inadequate. This may require consultation with an apps’ vendor, reviewing vendor documentation and analysing the output from security testing. Determine the information risk from the operating environment by taking into account factors such as the: lack of assurance; sensitivity of data processed; and criticality of processing.

Treat risks in operating environmentTake appropriate risk treatment actions, which may include:

‒ no longer using an app if it is insecure, will not be secured by the app’s vendor or its environment is unsuitable

‒ transferring risk (e.g. buying insurance)

‒ applying a range of mitigating security controls, such as:• leveraging EMM to ensure app data is always encrypted using a VPN• applying a secure architecture• performing security audits and security testing of the operating environment used by the apps’ vendor• security hardening servers and services used by apps• requiring app vendors to obtain appropriate recognised certifications for the product (e.g. ISO/IEC 27001, SSAE16 and PCI DSS)• placing restrictions on the processing an app can perform (e.g. no personally identifiable information and no intellectual property rights (IPR))

‒ accepting the risk.

I: Store and erase sensitive information securely


An organisation can ensure sensitive information is not subject to unauthorised disclosure (e.g. when no longer needed) by storing information securely, decommissioning apps securely and verifying that sensitive information has been erased securely.

Store data securelyProtect sensitive information stored on mobile devices, which may include:

‒ requiring the device to encrypt all storage including removable media (e.g. using EMM or manually)

‒ developing apps to use the strong encryption features built into mobile devices

‒ storing data in a secured container or within encrypted storage (e.g. using EMM).

42% of Benchmark respondents do not use full disk encryption on mobile devices.

Decommission apps securelyEstablish a process for decommissioning apps and mobile devices to provide assurance that sensitive information has been erased securely. Such a process may include:

‒ decommissioning apps and related devices securely (e.g. using EMM)

‒ performing a manufacturer reset of mobile devices that are to be decommissioned.

Verify sensitive information has been erased securelyAnalyse mobile device storage to verify that decommissioned apps and devices have no remnants of sensitive information.

Refer to Topic SD 2.10 of the Standard for details of system decommissioning.


4 Conclusion

Mobile apps have affected the lives of many people. They have not merely lowered the barrier to using powerful distributed computing services, they have smashed through it. It is a triumph of modern computing that anyone with a mobile device can search for, install and use apps without needing knowledge of computers and networks. Apps have become so familiar that individuals expect to interact with organisations via an app, from many devices, at any time, and from anywhere.

App stores are part of a new frontier of modern computing, comprising billions of devices in a globally connected infrastructure. Apps have enabled any developer (whether amateur or professional, malicious or altruistic) to reach a potential clientele of billions. But, buyer beware. Apps may appear in app stores as high-quality, enterprise software but appearances can be deceptive. Scratch below the polished surface and an app could be unsuitable for business use or insecure.

Taking advantage of the benefits of apps, without attracting excessive risk, requires balancing business needs between applying a locked down and allowing a wide open environment. There are three important lessons:

1. Knowledge is paramount. Managing apps and their risk requires knowing which apps are processing what data, by whom, from where and for what purpose.

2. Prohibition is seldom an option; pragmatism is key. The vendor’s app stores provide some security assurance about the apps they contain, but cannot determine whether an app is suitable for a particular business use. Whether an app is used or not should be based upon risk, user satisfaction and the extent to which it meets business needs.

3. Service is essential. Securing the use of apps in an organisation is not just about secure development, the level of IT and security operational support provided should be similar to other types of business applications.

The challenge is to service the business need for apps in a secure manner whilst providing individuals with a similar level of freedom, functionality and ease of use they are accustomed to in their personal life. Fail to get the balance right and unauthorised, high-risk apps will be used anyway to handle your sensitive information and to support critical business processes.

WHERE NEXT?The Process community on ISF Live is the place to share and discuss practical approaches for securing mobile apps. Join this vibrant community to share ideas and learn from other Members' experiences.

ABOUT THE ISFFounded in 1989, the Information Security Forum (ISF) is an independent, not-for-profit association of leading organisations from around the world. It is dedicated to investigating, clarifying and resolving key issues in cyber, information security and risk management and developing best practice methodologies, processes and solutions that meet the business needs of its Members.

WARNINGThis document is confidential and is intended for the attention of and use by either organisations that are Members of the Information Security Forum (ISF) or by persons who have purchased it from the ISF directly. If you are not a Member of the ISF or have received this document in error, please destroy it or contact the ISF on [email protected]. Any storage or use of this document by organisations which are not Members of the ISF or who have not validly acquired the report directly from the ISF is not permitted and strictly prohibited. This document has been produced with care and to the best of our ability. However, both the Information Security Forum and the Information Security Forum Limited accept no responsibility for any problems or incidents arising from its use.

CLASSIFICATIONRestricted to ISF Members, ISF Service Providers and non-Members who have acquired the report from the ISF.

REFERENCE: ISF 18 05 01 ©2018 Information Security Forum Limited. All rights reserved.

Securing Mobile Apps Embracing mobile, balancing controlMAY 2018

PUBLISHED BYInformation Security Forum Limited +44 (0)20 3875 6868 [email protected] securityforum.org

AUTHORMark Sowerby

REVIEW AND QUALITY ASSURANCERichard AbsalomAndy Jones Jason Creasey

Documents

BRIEFING PAPER SECURING MOBILE APPS LONG TITLE€¦ · Information Security Forum Securing Mobile Apps: Embracing mobile, balancing control 3 Each mobile device is a virtual gold