1 Appstore security September 2011 Appstore security
2 About ENSA he European Network and nformation Security Agency (ENSA) is an EU agency created to advance the functioning of the internal market. ENSA is a centre of excellence for the European Member States and European institutions in network and information security, giving advice and recommendations and acting as a switchboard of information for good practices. Moreover, the agency facilitates contacts between the European institutions, the Member States and private business and industry actors. Contact details Authors: r. Marnix ekker, CSA and r. Giles Hogben Press and inquiries: Ulf Bergstrom Credits he threat analysis was performed in collaboration with the istrinet esearch Group, K.U.Leuven, Belgium (as part of ENSA tender P/29/10/C), in particular: Prof. dr. Frank Piessens, r. Lieven esmet, r. Pieter Philippaerts, and Philippe e yck. We consulted with industry experts while drafting this paper and the malware defences in particular. We are grateful for their valuable input and comments. Peter ickman, Nick Kralevich (Google) Nader Henein (esearch in Motion) Kari i. Kostiainen, Niall Odonoghue, imo J. Heikkinen, Mikko Saario (Nokia) Vinay Bansal (Cisco Systems) Legal notice Notice must be taken that this publication represents the views and interpretations of the authors and editors, unless stated otherwise. his publication should not be construed to be an action of ENSA or the ENSA bodies unless adopted pursuant to the ENSA egulation (EC) No 460/2004 as lastly amended by egulation (EU) No 580/2011. his publication does not necessarily represent state-of the-art and ENSA may update it from time to time. hird-party sources are quoted as appropriate. ENSA is not responsible for the content of the external sources including external websites referenced in this publication. his publication is intended for educational and information purposes only. Neither ENSA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication. eproduction is authorised provided the source is acknowledged. European Network and nformation Security Agency (ENSA), 2011
3 Appstore security 3 Executive Summary Smartphones will outnumber PC s by 2013 and they will be the most common device for accessing the internet (Gartner, 2010). A key feature of smartphones is the use of appstores: managed repositories of third party software. Apple s appstore and Google s Android market have hundreds of thousands of apps, and claim billions of app downloads. Where in the past mobile phone users could just change ringtone or wall paper, apps turn the smartphone into the digital equivalent of the Swiss army knife, offering anything from sonic mosquito repellent to point-of-sale credit card payments. Apps have not escaped the attention of cyber attackers. For example, in 2010 diallerware was found in appstores for Windows Mobile phones and in 2011 malware was disguised as a popular app on the Android appstore infecting thousands of smartphones. Still, the number of malware attacks on smartphones pales in comparison with PCs. he large market share of PCs plays a role, but we believe that security design choices have been instrumental in preventing smartphone malware. o consolidate this head start, in this paper we analyse malware threats in app ecosystems and we identify five lines of defence that protect end-users 1 from malware and insecure apps: App review: Appstores should review apps before admitting them to the appstore. While app review cannot be perfect, it limits the possibilities for app developers to introduce malicious, or legitimate but insecure apps in appstores. Appstores can check apps with automatic (static and dynamic) analysis tools. Additionally human (manual) review can be used. While scalability is a problem with human review, this could be addressed by focussing on sensitive functionality and by using escalation procedures. eputation mechanism: eputation of apps and app developers can help users avoid malware. Appstores should show the reputation of apps and app developers. Second-order mechanisms can increase reputation quality. Appstores could take into account the reputation of the same app in other appstores. A point of concern is that most users rate apps for their functionality and not for their security, so there should be a separate channel for security and privacy issues (e.g. this app works, but asks for excessive privileges at install ). App revocation (aka kill-switch): Smartphone platforms should support remote removal of installed apps by appstores. Appstores should have an app revocation mechanism for malware and insecure apps. n special cases, e.g. when malware breaks out of the app sandbox, it may be necessary to use customized removal tools. evice security: Appstore defences rely on the security of the devices running the apps. he device should install and run apps in sandboxes, to reduce the impact of malware. n the 1 his paper is part of a number of ENSA activities around smartphone security. We have previously published a full overview of information security risks for smartphone users. We are also working with OWASP to draft best practices for app developers.
4 4 Appstore security sandbox, apps should get only a minimal set of privileges (the principle of least privilege). he sandbox should monitor the app inside it and allow the user to see the app s past activity. App revocation should uninstall the app and return the device to a pre-install state. Jails (or walled gardens): Smartphone (platform) vendors can restrict smartphones to apps from one or more designated appstores only and in this way prevent drive-by download attacks. his is commonly referred to as a jail or a walled garden. he smartphone should either be blocked from using untrusted appstores or, for expert users, present clear warnings about installing from untrusted sources. he approach to this issue is crucial if users can easily install from untrusted appstores, then it is easy for attackers to bypass the defences of the good appstores (with drive-by download attacks e.g.). On the other hand, overly-restrictive jails encourage users to break the jail, possibly introducing higher risks than those originally mitigated by the jail. Jails should, for example, not be used to stifle legitimate competition. We refer the reader to the body of this paper for details about the threat analysis (a combination of SE threat modelling and attack trees) and the five lines of defence against malware. n conclusion, on the positive side, appstores can offer important opportunities to prevent, or reduce the impact, of malware and insecure apps. hey can provide customers with vetted software distribution channels, showing the reputation of apps, and operating a revocation mechanism for malware and insecure apps. At the same time, cyber attackers are focussing more on smartphones. hey will try to sell malicious apps directly or go after software vulnerabilities in popular apps. he stakes are high: Consumers, government and business professionals use smartphones to store and process large amounts of confidential and personal data. ifferent smartphone platforms and different app stores currently address malware and insecure apps differently, which for consumers can be confusing. Without overlooking the differences between the various smartphones models and appstores, we recommend an industry-wide approach to addressing malware and insecure apps. Security teams should exchange information about apps (analyses, reputation) and share security practices. Consumers should be presented with clear security information about app developers and the apps they sell. A solution could be a distributed reputation system for apps and app developers across the different appstores. By analysing the threats and showing a baseline set of malware defences in this paper, we hope to contribute to a more common and standardized approach to app store security, across the (booming) smartphone industry.
5 Appstore security 5 1. ntroduction Besides the well-known Apple Appstore and Google Android Market there are many other appstores. For instance, Amazon opened an appstore for Android smartphones, Microsoft has one for Windows Mobile phones, Nokia for Symbian-based smartphones, CSCO has an appstore for its tablet, and some enterprises even created appstores for their employees. Besides appstores for smartphones there are also other appstores, for example for social media networks (Facebook apps), for business cloud services (Google apps), for browsers (Mozilla s addons), and so forth. n this paper we call a set of appstores, targeted at a specific platform, an app ecosystem (see figure below). App ecosystem App developer App developer App developer app App Store App Store app User device User device User device n an app ecosystem, app developers create apps, and sell or distribute them to users. An app is a piece of software that extends the functionality of the user device (a smartphone or a browser platform for example). he appstores receive apps from app developers and sell (or distribute) them to users, acting as a broker. Appstores generally show the reputation of each app, for example the number of downloads per app, the user reviews and the user votes. n this paper we focus on the threat from malware or insecure apps in app ecosystems. We first build a dataflow model of an app ecosystem in Section 2. he app ecosystem model is used for a SE threat analysis which is presented in Section 4. he scope of our threat analysis, assumptions about the attackers in scope, is explained in Section 3. n Section 5 we analyse the threats using attack trees and we identify five lines of defence.
6 6 Appstore security 2. ataflow diagram of an app ecosystem n this section we construct a model of an app ecosystem, which we will use in Section 4 as the basis for a SE threat analysis. 2.1 ntroduction to dataflow diagrams We describe our model using a data-flow diagram 2. he diagram has the following elements: nteractors (rectangles) generate input and consume output (to a process), e.g. humans. Processes (circles) perform some specific function. hey take one or more inputs, and generate one or more outputs, e.g. computer system functionality. atastores (two parallel lines) are used for storing data temporarily or permanently, e.g. a file system or a database. rust boundaries 3 (red dashed lines) indicate the edges of control. For example, we draw a trust boundary between the smartphone and the appstore because the smartphone is under control of the user, and the appstore under control of the appstore owner. 2.2 Modelling an app ecosystem he full diagram is shown below: he upper left corner shows the main use cases for the app developer (1). he app developer can send a new app, or an update, to the acceptance check (P1), which checks whether the app is suitable for inclusion in the appstore. he upper right corner shows the main use cases for the appstore controller (2). he appstore controller can approve apps for inclusion in the appstore (P1). After approval the app is packaged for inclusion in the appstore (P2). Metadata is added to the app such as a description and a list of permissions that the app needs on the user device (sometimes called a manifest ). Additionally the appstore controller can revoke bad apps (P3), based on complaints for example. evocation removes apps from the user devices (sometimes called a kill switch ). he lower part of the diagram shows the main use cases for the device user (3). he device user can browse descriptions and reputation of apps (P4). he installer (P8) requires as input the actual app published by the appstore (P5) and approval from the device user. On installation the apps are stored in the datastore with installed apps (2). After installation the device user can execute an app (P10). he device user can also submit comments and complaints about apps, which are processed and stored in the appstore (P7). 2 One could use SE with other modelling techniques, for example UML, but data flow diagrams are most common and support the use of tools such as the Microsoft SL hreat Modeling ool. 3 rust boundaries are not usually included in data flow diagrams, but they are used in SE threat analyses; in a SE analysis the focus is on the data flows crossing trust boundaries.
7 Appstore security 7 o ensure that the user devices receive timely updates and revocations, there is a periodic check (P9) for updated or revoked apps. Updates and revocations trigger the installer to install an updated app or uninstall a revoked app. Note that our model is only a general, simplified description of how app ecosystems work, based on an analysis of the Android marketplace, the iphone appstore, and the Mozilla Addons store. 2: App store controller 1: App developer Updated app New app P1: Acceptance check Approval of app evocation of app P2: Package and store app P3: evoke app App and metadata 1: App store P4: Publish description and reputation of apps P5: Publish apps P6: Publish updates and revocations P7: Accept comments or complaints App and metadata App of revoked or updated app P8: nstall, uninstall apps App P9: Periodic app check App App descriptions and reputations 2: Local apps App Comment or complaint about app Approval for installation, update, uninstallation P10: Execute app App name 3: evice user
8 8 Appstore security 3 Attacker model Here we set the scope of the threat analysis and define which attacks and attackers are in scope. n this paper we assume the target of cyber attackers to be users, consumers or professionals in public or private sector organizations, who download and install apps. We focus on attacks that introduce malware on the device via apps or appstores 4. We don t distinguish between stand-alone malware and malware that relies on other apps. he attackers have two intermediate technical goals: to get malicious code on the user device, and (if that works) to keep malicious code on the user device We ignore attacks directed at app developers or appstores which have no impact on the end-user (e.g. click-fraud, plagiarism, unfair competition). We also ignore social engineering attacks in which the user is tricked to configure insecurely an otherwise secure app. emark: here are 2 layers of software on a smartphone: the OS and the apps. So there are 4 categories of malware attacks: 1. Sell or distribute a malicious app. 2. Exploit vulnerability in an existing app. 3. Sell or distribute a malicious OS 4. Exploit vulnerability in an existing OS n this paper we mostly focus on categories more on 1 and 2. he Gemini and roidream attacks, seen in 2011, are an example of the first category. he ZitMo malware is an example of the second category 5. Selling or distributing a malicious OS (category 3) may seem to be a relatively minor threat, but there are device users who install a custom, unofficial OS on their smartphone, for added functionality. here is a risk that malicious operating systems are distributed: users should review the reputation of such operating systems carefully. Exploits of OS vulnerabilities (category 4) have been the dominant vector for attacks on PC s in the past decade. For protecting against OS exploits we refer the reader to a literature survey by. Gollmann. 4 t should be stressed that information security risks do not only come from malware alone. Even authentic, vetted apps can lead to data leaks, for example voice to text conversion software that uploads audio for processing. For corporate users such apps may expose sensitive customer data. 5 Exploits of third-party software have become the dominant problem for PCs as well: For example, according to Symantec more than half of the web-based attacks in 2010 exploit flaws in Adobe software (either the plugin or supporting libraries).
9 Appstore security 9 4. SE hreat analysis n this section we show the result of the SE threat analysis on the app ecosystem model. 4.1 ntroduction to SE SE categorizes threats into six types 6 : Spoofing threats: a process or an interactor pretends to be someone/thing else. ampering threats: a process, a data flow, or a datastore is changed. epudiation threats: evidence of an action by a process or an interactor disappears. nformation disclosure threats: a process, a dataflow, or a datastore reveals sensitive data. enial of service threats: a data flow, a datastore, or a process is overloaded, rendering normal use impossible. Elevation of privilege threats: a process is used to perform unauthorized actions. he 6 threat types apply to different elements in a dataflow model, as follows. Spoofing ampering epudiation nformation disclosure enial of service Elevation of privilege ata flows x x x atastores x x x Processes x x x x x x nteractors x x he focus of the SE analysis is on threats which cross trust-boundaries in the dataflow model. 4.2 SE threat analysis on the trust boundaries Our model has 3 interactors, 10 processes, 2 datastores, and 20 dataflows, so the full SE sweep gives 132 threats. We enumerate all the (61) threats on the trust boundaries first. hreats considered marginal to the scope of this paper are included for the sake of completeness, but typeset in grey. Element ype hreat description App developer (1) S 1 App developer is impersonated (spoofed) by an attacker and (in his name) submits a malicious app. 2 Attacker submits a malicious app, and denies this later. ataflows beteen app developer (1) and the appstore (P1). 3 Attacker tampers with an app or an update, adding malicious code to it.. 4 Attacker learns sensitive information, for example authentication credentials of the app developer. 5 Attacker denies app developers to submit apps or updates by overloading 6 SE includes only technical threats, resulting from design flaws or bugs, and not non-technical threats such as bribery.
10 10 Appstore security Acceptance check (P1) nteractor 3 (evice user) Publish description and reputation of apps (P4) ataflow between P4 and 3: App descriptions and reputations Publish apps (P5) ataflow between P5 and P8: App and metadata Publish updates and revocations (P6) S E S S E S E S the acceptance check with many apps. 6 Attacker spoofs the acceptance check, and gets the developer to reveal authentication credentials. 7 Attacker gets a malicious app past the acceptance check. 8 Appstore denies having received an app or an update for acceptance. 9 Attacker learns sensitive information about the appstore or other app developers from the acceptance check. 10 Attacker denies app developers to submit apps or updates by overloading the acceptance check with many apps. 11 Attacker approves a malicious app or submits an app on behalf of someone else. 12 Attacker impersonates a device user and posts false feedback for an app or skews download numbers for apps. 13 Attacker repudiates having given false feedback. 14 Attacker spoofs the appstore interface, so users see false descriptions and reputations of apps. 15 Attacker tampers with the appstore interface, changing the descriptions and reputations of apps. 16 Attacker browses descriptions and reputations but denies this later. 17 Attacker learns sensitive information, for example which users want to install which apps. 18 Attacker prevents users from browsing app descriptions by overloading the appstore. 19 Attacker carries out unauthorized actions, such as changing the descriptions and reputations of apps. 20 Attacker changes the descriptions and reputations of apps. 21 Attacker learns which users have installed which apps. 22 Attacker prevents users from browsing app descriptions by overloading. 23 Attacker spoofs the appstore, so the device installs malicious apps. 24 Attacker tampers with the appstore, so the device installs malicious apps. 25 Attacker downloads an app for installation and denies this later. 26 Attacker learns sensitive information from the appstore, such as which apps are being installed on which devices. 27 Attacker denies access to the appstore, for example to prevent devices from downloading apps or updates for installation. 28 Attacker carries out unauthorized actions, such as inserting additional (malicious) apps in the store. 29 Attacker tampers with the app, so the device installs a malicious app. 30 Attacker learns which apps are installed on which devices. 31 Attacker prevents devices from downloading apps or updates for installation. 32 Attacker spoofs the appstore, so the device does not get all the revocations or updates. 33 Attacker tampers with the appstore interface, so the device does not get all the revocations or updates. 34 Attacker receives an update or revocation notice and denies this later. 35 Attacker learns sensitive information from the appstore interface, such as which apps are installed on which devices.
11 Appstore security 11 ataflow between P6 and P9: App s of revoked or updated apps. Accept comments or complaints (P7) ataflow between P7 and 3: Comment or complaint about app nstall, uninstall apps (P8) Periodic app check (P9) E S E S E S E 36 Attacker denies access to the appstore interface, for example to prevent users from receiving updates and revocations. 37 Attacker carries out unauthorized actions, such as changing or removing updates or revocations. 38 Attacker tampers with the updates and revocations from the device, so that the device does not receive all the updates and revocations. 39 Attacker learns which apps are installed on which devices. 40 Attacker prevents devices from receiving updates or revocations for installation. 41 Attacker spoofs the appstore, so the user submits comments and complaints in the wrong place. 42 Attacker tampers with the appstore interface, changing or removing complaints. 43 Attacker submits positive feedback information and denies this later. 44 Attacker learns sensitive information, for example which apps are installed on which devices. 45 Attacker prevents device users from submitting comments and complaints by overloading the appstore with comments. 46 Attacker carries out unauthorized actions, such as removing comments or complaints about an app. 47 Attacker changes comments and complaints from the device user. 48 Attacker learns sensitive information about the device users, for example which apps are installed by which users, or personal details about device users. 49 Attacker prevents device users from submitting comments and complaints by overloading the appstore with comments. 50 Attacker spoofs the device, for example to skew the statistics on which users have installed which apps or updates. 51 Attacker tampers with the installer, installing malicious apps. 52 Attacker installs an app, denying this later on, for example to skew the statistics on which users have installed which apps or updates. 53 Attacker learns sensitive information about the user, for example which device the user is carrying. 54 Attacker overloads the installer, preventing the user from installing updates, or uninstalling revoked apps. 55 Attacker carries out unauthorized actions, such as installing malicious apps and rootkits. 56 Attacker spoofs a user device, for example to skew the statistics on which users have received update or revocation notices. 57 Attacker prevents a user device from receiving updates or revocations. 58 Attacker receives an update or revocation notice, denying this later on, for example to skew the statistics on how many users received updates or revocations. 59 Attacker learns sensitive information from the appstore user interface (for example which apps are installed on which user devices). 60 Attacker overloads the process, preventing the user device from receiving updates and revocation information. 61 Attacker carries out unauthorized actions, removing revocations.
12 12 Appstore security 4.3 SE analysis inside the trust boundaries A full SE threat analysis would also cover the elements and data flows inside the trust boundaries. For example, the full SE analysis also yields a spoofing attack on the Appstore controller (2) - an attacker impersonating the Appstore controller. For the sake of brevity, we do not elaborate all these threats and just discuss the internal threats (within the trust boundary) to the process Execute app (P10) because often malicious behaviour only emerges at runtime. Element ype hreat description Execute app (P10) S E 62 Attacker spoofs the execution process, so the user thinks (wrongly) that an app is executing. 63 Attacker tampers with the execution process, to perform malicious functions. 64 Attacker can run an app without leaving evidence (such as logs). 65 Attacker learns sensitive information from the execution process, for example about the device user, or sensitive information on the device. 66 Attacker overloads the execution process, to prevent the user from executing other apps. 67 Attacker carries out unauthorized actions, such as tampering with other apps, reading data stored by other apps, or reading sensitive information.
13 Appstore security efending against the threats he SE analysis yields many different threats. o address them systematically we use attack trees - a technique introduced by Bruce Schneier to analyse all the different ways to attack a system Attack tree An attack tree for attacking the device user with malware is shown below. he top nodes are the highlevel technical attacker goals: to get malicious code on the user device, and to keep malicious code on the user device. n this tree we take into account both malicious apps and exploits of vulnerable apps. We do not refine further to practical goals, such as stealing money or sensitive data. An arc denotes conjunction (meaning that both sub goals are required to execute the attack). he threats from the SE analysis, showing how they can be used in attacks, are on the bottom of the diagram. Keep malicious code on the user device Get malicious code on the user device Sell/distribute malicious app in appstore Prevent detection by device user Prevent updates, app revocation Bypass the appstore Exploit vulnerability in installed app Create malicious app Circumvent app review roll/falsify app reputation Attack trees are similar to fault trees and dependency trees which are used in industrial engineering to analyse how a system or a structure deals with incidents or disaster.
14 14 Appstore security 5.2 Lines of defence n this section we identify 5 lines of defence which can be deployed to prevent malware attacks on end-users (see below). he defence mechanisms are shown in the attack tree below. Keep malicious code on the user device Get malicious code on the user device K, Sell/distribute malicious app in appstore Prevent detection by device user Prevent updates, app revocation J, A A Lines of defence: Bypass the appstore Exploit vulnerability in installed app Create malicious app Circumvent app review roll/falsify app reputation A App review eputation mechanism K App revocation (kill-switch) evice security J Jails App review (A) Appstores can check apps for security issues before they are distributed to end-users. As mentioned earlier, app reviews cannot give a 100% security guarantee, but they make it harder for attackers to introduce malware in app ecosystems. Automated software analysis tools: Static analysis tools can be used to inspect the source or binary code of an app to ensure that it does not use unauthorized functionality and that it adheres to (some of) the developer guidelines. An example would be the tool in Apple s submission process that checks for forbidden AP calls. Alternatively, such tools can scan for viruses or known malicious code fragments. n addition to static analysis tools, dynamic analysis tools can be used, that will actually run the app against a number of test cases so it can be checked and monitored for unwanted or unauthorized behaviour. An example is Microsoft s Hopper tool that runs a submitted application for a number of hours and monitors memory usage, performance, and stability. Automated tools could be set up to trigger escalation procedures to manage resource-intensive analysis such as manual analysis (see next bullet). Manual analysis: While research in software analysis is slowly pushing the boundaries of what can be analysed automatically, there are a number of aspects that can only be checked by a human, for example if an app is trying to spoof another app to fool the user. Scalability of manual analysis is a point of concern for appstores. Escalation procedures and a focus on critical functionality can be used to make manual analysis more efficient. Sharing analysis results: When possible, results of security analysis should be shared with other appstores and security researchers. Appstores could also leverage the expertise of 3rd party researchers and security companies by allowing them to bulk-download and analyse apps.
15 Appstore security 15 Authentication of app developers: App developers should be securely authenticated so that rogue app developers cannot piggy-back on the (good) reputation of other app developers. n app ecosystems often single individuals create apps rather than large software vendors 8. Apps are not only developed in well-protected development environments. his means that authentication of app developers becomes more important. Phishing attacks or XSS attacks to get the credentials of app developers are a significant risk. isk profiling of app developers: he appstore should monitor and create risk profiles of app developers. New app developers, or app developers who submit unsafe or malicious apps, should be treated with special care. Anomalous behaviour from well-known app developers could be a sign of an attack (phishing for example). Continuous process: App review should be a continuous process, and appstores should analyse apps even after they have been admitted to the appstore, for example by using more resource-intensive analysis (manual analysis e.g.). his type of ex-post review could be triggered by the popularity of an app (download numbers) or the reputation mechanism (see below). Priority for updates: Appstores should consider priority vetting for updates to existing (and popular) apps to allow app developers to patch vulnerabilities quickly. eputation mechanism () A reputation mechanism for apps and app developers is important for device users to be able to avoid insecure apps. A reputation mechanism does not give a 100% guarantee, because attackers could invest in building up a good reputation, but it does make it harder for attackers to distribute malicious apps. App track record: o allow users to make a good choice, the reputation of an app should show the history and track record of app developers and apps, download statistics of apps, user votes, and detailed comments and complaints from users. Separate security and privacy reputation: An important issue with current app reputation systems is that users often only rate apps for their functionality. Security and privacy information about apps should be treated separately in app store reputation mechanisms. Sybil attack resistance: Mechanisms should be in place to avoid attackers from creating multiple pseudonymous identities and thereby gaining excessive influence to be able to skew the reputation of apps (aka Sybil attack). Second-order mechanisms can be used to foil Sybil attacks (see next bullet). 8 Consumerisation of software development also means that software developers can more easily change names to escape a bad reputation, and that security processes may be absent, for example patcbing processes.
16 16 Appstore security Second-order reputation: Second-order reputation can prevent attacks on the reputation scheme by giving more weight to votes from users who have a good reputation amongst other users. his can increase scoring quality and relevance and prevent trolling and Sybil attacks. Anonymous feedback: Comments and complaints from device users should be anonymised and sensitive information about device users should be removed from public feedback to encourage honest feedback and to avoid targeted attacks that rely on which apps a device user installed. Exchanging reputation information: When possible, reputation information about the same app in other (trusted) appstores should be taken into account. o allow for such an exchange apps should have unique identifiers and signatures to allow referencing across different appstores. Permission feedback: reputation systems should allow users to give separate feedback on specific security-relevant features such as excessive permission requests (e.g. snake game asks for access to GPS and telephone calls). App revocation or kill-switch (K) Many smartphone platforms implement an app revocation mechanism, or kill-switch, which uninstalls apps installed on user devices. App revocation can be triggered either by the app store or by the smartphone (platform) vendor. mportant aspects of app revocation mechanisms are the following. User communication and consent: emoving apps from user devices is a controversial subject. Users should be informed about the reasons for the removal and, if this does not jeopardize other users, given a chance to opt-out. here are also settings where app revocation goes against security policy. For example in a military setting, apps may be mission-critical and the app revocation mechanism may need to be turned off. Spawning: t is important to prevent a malicious app from spawning installing difficult to remove code across the user device during installation or runtime..e. it should be possible, by uninstalling the app to reverse all changes caused by the app. On PC s for example attackers often spawn malicious code in places where it is difficult to remove (rootkits). n the roidream attack, the Android kill-switch could not be used because the malicious code was outside the sandbox. n such a case, a custom removal tool may be required. Update frequency: Smartphone (platform) vendors should encourage users to update frequently. Security updates should be kept small in size whenever possible, to prevent that users with limited-bandwidth or metered internet access skip large updates. etection: he reputation mechanism (see above) plays an important role because it often provides the basis for a revocation. Comments and complaints should be monitored
17 Appstore security 17 continuously. Apps may exhibit malicious behaviour at a specific moment (say Easter eggs), at random intervals, or randomly across users as seen in malvertisement attacks 9. False positives: App revocation could potentially be used to uninstall good apps from user devices. he app revocation mechanism should only be accessible to security teams who can base their decisions on app reviews, user reviews, complaints. evice security () Appstore defences rely for a large part on a secure implementation on the device. App sandboxes are vital for the security of the app ecosystem because they limit what apps can do on the device 10. mportant device-side security features are the following: Code signing: he user device should only accept apps that are signed by the right app store. Sandboxes: he user device should have sandboxes (or containers) for apps, so that apps are installed and run in isolation, to reduce the impact of malware. Minimal set of privileges: n the sandbox, apps should have only a minimal set of privileges by default (applying the principle of least privilege) and if an app needs additional privileges (for example to access GPS data) this should be handled with care; either the user should be explicitly asked for consent, or the app store should grant permission during app review. An important issue here is that users are often not in a position to make good security decisions, especially when asked frequently. Monitoring by the smartphone user: An important feature of sandboxing is monitoring of the app inside. he device should monitor apps after they have been installed. evice users should have the possibility of seeing reports of the activity of an app (network usage, resource usage, and so on) to detect resource-intensive code. Clean slating: he device should when triggered by the appstore or the user uninstall the app and return the device to a pre-install state. Jails or walled gardens (J) he device vendor (or the platform distributor) can restrict installation of apps to one or more trusted appstores or warning when the user is installing apps from untrusted appstores. his is commonly referred to as a jail or a walled garden. he approach to app installation policies (and jails in particular) is crucial, because most of the above-mentioned defences are useless if users are quick to skip warnings or jailbreak their devices. f it is easy to skip warnings then users are vulnerable to drive-by download attacks a common source of infection on PC s. f jails are too restrictive users will try to jailbreak their devices which could expose them to even higher risks, for example when jailbreaking 9 n some malvertisement attacks, attackers have uploaded genuine-looking - but malicious banners (to exploited advertisement servers) that infect only a few users at random moments, to prevent detection. 10 Sandboxing and capabilities was rated as the top information security opportunity in our smartphone risk assessment.
18 18 Appstore security removes other defences in the process. here are several models in use, each with different security considerations: Closed app ecosystems: n a closed app ecosystem, there are one or more designated appstores that can sell or distribute apps. he devices are configured in such a way that users can only install apps from one or more designated appstores. he appstores in the closed system form a federation and can agree on common security practices. Enterprise app stores: For enterprise users, smartphones could be configured to allow only apps from a dedicated enterprise app store, allowing the enterprise tight control on app installation. Open app ecosystems: n an open app ecosystem anyone can open an appstore and start selling or distributing apps to device users. While this gives the device user maximum freedom of choice, just like on a traditional PC, it also increases the risk of drive-by download attacks. Federated appstores: Appstores could form federations by agreeing, inter alia, to a minimum level of security. Such a federation of app ecosystems could give end-users more choice, while at the same time preserving the security benefits of a closed app ecosystem. App reputation across appstores: Another possibility is to keep a single central list of wellreputed apps as the app whitelist of the app ecosystem. Such a reputation system would provide a central repository of security information about apps, independently of where the apps are sold. n this way, the central list is only responsible for assuring the authenticity of the list entries and their reputation in terms of security and privacy. his concludes the body of our paper. We refer the reader to the executive summary for our conclusions.
19 Appstore security 19 (his page is intentionally left blank)
Malicious software About ENISA The European Network and Information Security Agency (ENISA) is an EU agency created to advance the functioning of the internal market. ENISA is a centre of excellence for
Threat Modeling Frank Piessens (Frank.Piessens@cs.kuleuven.be ) Secappdev 2007 1 Overview Introduction Key Concepts Threats, Vulnerabilities, Countermeasures Example Microsoft s Threat Modeling Process
4 0 0 T o t t e n P o n d R o a d W a l t h a m, M A 0 2 4 5 1 7 8 1. 8 1 0. 4 3 2 0 w w w. v i e w f i n i t y. c o m Utilizing Pervasive Application Monitoring and File Origin Tracking in IT Security
Security challenges for internet technologies on mobile devices - Geir Olsen [firstname.lastname@example.org], Senior Program Manager for Security Windows Mobile, Microsoft Corp. - Anil Dhawan [email@example.com],
Defending Behind The Device Mobile Application Risks Tyler Shields Product Manager and Strategist Veracode, Inc Session ID: MBS-301 Session Classification: Advanced Agenda The What The Problem Mobile Ecosystem
Kaseya White Paper What Do You Mean My Cloud Data Isn t Secure? Understanding Your Level of Data Protection www.kaseya.com As today s businesses transition more critical applications to the cloud, there
Windows Phone 8 Security Overview This white paper is part of a series of technical papers designed to help IT professionals evaluate Windows Phone 8 and understand how it can play a role in their organizations.
Data Protection Act 1998 Bring your own device (BYOD) Contents Introduction... 3 Overview... 3 What the DPA says... 3 What is BYOD?... 4 What are the risks?... 4 What are the benefits?... 5 What to consider?...
Mobile Application Security Helping Organizations Develop a Secure and Effective Mobile Application Security Program by James Fox firstname.lastname@example.org Shahzad Zafar email@example.com Mobile applications
E-mail security About ENISA The European Network and Information Security Agency (ENISA) is an EU agency created to advance the functioning of the internal market. ENISA is a centre of excellence for the
Information Security for Modern Enterprises Kamal Jyoti 1. Abstract Many enterprises are using Enterprise Content Management (ECM) systems, in order to manage sensitive information related to the organization.
Enabling Seamless & Secure Mobility in BYOD, Corporate-Owned and Hybrid Environments Efficiently and Cost- Effectively Managing Mobility Risks in the Age of IT Consumerization Table of Contents EXECUTIVE
5 Steps to Advanced Threat Protection Agenda Endpoint Protection Gap Profile of Advanced Threats Consensus Audit Guidelines 5 Steps to Advanced Threat Protection Resources 20 Years of Chasing Malicious
Mobile Application Security Whitepaper 4 Steps to Effective Mobile Application Security Table of Contents Executive Summary 3 Mobile Security Risks in Enterprise Environments 4 The Shortcomings of Traditional
KASPERSKY SECURITY INTELLIGENCE SERVICES. EXPERT SERVICES www.kaspersky.com EXPERT SERVICES Expert Services from Kaspersky Lab are exactly that the services of our in-house experts, many of them global
. The Radicati Group, Inc. 1900 Embarcadero Road, Suite 206 Palo Alto, CA 94303 Phone 650-322-8059 Fax 650-322-8061 http://www.radicati.com THE RADICATI GROUP, INC. Mobile App Reputation Services Understanding
Mobile App Reputation A Webroot Security Intelligence Service Timur Kovalev and Darren Niller April 2013 2012 Webroot Inc. All rights reserved. Contents Rise of the Malicious App Machine... 3 Webroot App
March 2014, HAPPIEST MINDS TECHNOLOGIES Elevation of Mobile Security Risks in the Enterprise Threat Landscape Author Khaleel Syed 1 Copyright Information This document is an exclusive property of Happiest
WHITE PAPER FortiWeb and the OWASP Top 10 PAGE 2 Introduction The Open Web Application Security project (OWASP) Top Ten provides a powerful awareness document for web application security. The OWASP Top
The State of Mobile Application Security 2014-2015 Application Security Made Easy The State of Mobile Application Security 2014-2015 /> Brought to you by Checkmarx and Appsec Labs Research author: James
Marble & MobileIron Mobile App Risk Mitigation SOLUTION GUIDE Enterprise users routinely expose their employers data and threaten network security by unknowingly installing malicious mobile apps onto their
The hidden risks of mobile applications This session was presented by Jim Stickley of TraceSecurity on Wednesday, October 23 rd at the Cyber Security Summit. To learn more about TraceSecurity visit www.tracesecurity.com
. The Radicati Group, Inc. 1900 Embarcadero Road, Suite 206 Palo Alto, CA 94303 Phone 650-322-8059 Fax 650-322-8061 http://www.radicati.com THE RADICATI GROUP, INC. Mobile App Reputation Services Understanding
Microsoft s Enhanced Mitigation Experience Toolkit (EMET) is an enhancement to the Windows operating system that stops broad classes of malware from executing. EMET implements a set of anti-exploitation
Kaspersky Security 10 for Mobile Implementation Guide APPLICATION VERSION: 10.0 MAINTENANCE RELEASE 1 Dear User, Thank you for choosing our product. We hope that you will find this documentation useful
Real World Testing Report A test commissioned by Symantec Corporation and performed by AV-Test GmbH Date of the report: July 30 th, 2012, last update: July 30 th, 2012 Executive Summary In July 2012, AV-Test
Secure Web Browsing With the right architecture, the web browser can become an effective solution for malware prevention Branden Spikes, CEO, CTO, and Founder of Spikes, Inc. Scott Martin, CISSP, CIO of
Kaspersky Security for Mobile See. Control. Protect. MOVING TARGETS Mobile devices play a key role in connectivity and productivity. But they also introduce new risks to the business: in the past 12 months
TRUST IN MOBILE MALWARE REPORT THREAT REPORT: H2/2014 CONTENTS At a Glance 03-03 Forecasts and trends 04-04 Current situation: 4.500 new Android malware instances every day 05-05 Third-party App-Stores
Where every interaction matters. Peer 1 Vigilant Web Application Firewall Powered by Alert Logic The Open Web Application Security Project (OWASP) Top Ten Web Security Risks and Countermeasures White Paper
The OWASP Foundation http://www.owasp.org Mobile Application Threat Analysis Ari Kesäniemi Nixu Copyright The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under
Malware Security Report: Protecting Your BusineSS, Customers, and the Bottom Line Contents 1 Malware is crawling onto web sites everywhere 1 What is Malware? 2 The anatomy of Malware attacks 3 The Malware
Cyber Essentials Questionnaire Introduction The Cyber Essentials scheme is recommended for organisations looking for a base level Cyber security test where IT is a business enabler rather than a core deliverable.
WEB ATTACKS AND COUNTERMEASURES February 2008 The Government of the Hong Kong Special Administrative Region The contents of this document remain the property of, and may not be reproduced in whole or in
Symantec's Secret Sauce for Mobile Threat Protection Jon Dreyfus, Ellen Linardi, Matthew Yeo 1 Agenda 1 2 3 4 Threat landscape and Mobile Insight overview What s unique about Mobile Insight Mobile Insight
TrustDefender Mobile Technical Brief Fraud Protection for Native Mobile Applications TrustDefender Mobile from ThreatMetrix is a lightweight SDK library for Google Android and Apple ios mobile devices.
How we keep harmful apps out of Google Play and keep your Android device safe February 2016 Bad apps create bad experiences, so we work hard to keep them off your device and out of Google Play. In 2015,
Feature List for Kaspersky Security for Mobile Contents Overview... 2 Simplified Centralized Deployment... 2 Mobile Anti-Malware... 3 Anti-Theft / Content Security... Error! Bookmark not defined. Compliance
CDM Software Asset Management (SWAM) Capability Department of Homeland Security Office of Cybersecurity and Communications Federal Network Resilience Table of Contents 1 PURPOSE AND SCOPE... 2 2 THREAT
Understanding and evaluating risk to information assets in your software projects ugh.. what a mouthful Dana Epp Windows Security MVP Who am I? Microsoft Windows Security MVP Information Security Professional
Application Security Testing Indian Computer Emergency Response Team (CERT-In) OWASP Top 10 Place to start for learning about application security risks. Periodically updated What is OWASP? Open Web Application
THE IMPORTANCE OF CODE SIGNING TECHNICAL NOTE 02/2005 13 DECEMBER 2005 This paper was previously published by the National Infrastructure Security Co-ordination Centre (NISCC) a predecessor organisation
LANDesk Solutions Descriptions Proven LANDesk Solutions IT departments face pressure to reduce costs, reduce risk, and increase productivity in the midst of growing IT complexity. More than 4,300 organizations
Secure By Default: Platforms Computing platforms contain vulnerabilities that can be exploited for malicious purposes. Often exploitation does not require a high degree of expertise, as tools and advice
Sygate Secure Enterprise and Alcatel Sygate Secure Enterprise eliminates the damage or loss of information, cost of recovery, and regulatory violation due to rogue corporate computers, applications, and
Future of Mobile App Security Vincent Sritapan Program Manager Cyber Security Division Science and Technology Directorate Do You Know What Your Apps Are Doing? Spying Microphone & camera surveillance $
Technical Proposition ADAM Software NV The global provider of media workflow and marketing technology software ADAM Software NV adamsoftware.net firstname.lastname@example.org Why Read this Technical Proposition?
Smartphones and tablets are invading the workplace along with the security risks they bring with them. Every day these devices go unchecked by standard vulnerability management processes, even as malware
Security Testing How security testing is different Types of security attacks Threat modelling Note: focus is on security of applications (not networks, operating systems) Security testing is about making
8 Ways to Better Monitor Network Security Threats in the Age of BYOD January 2014 8 Ways to Better Monitor Network Security Threats in the Age of BYOD 2 Unless you operate out of a cave, chances are your
SECURING THE 3DEXPERIENCE PLATFORM OWASP AND APPLICATION SECURITY Milan Bruchter/Shutterstock.com WHITE PAPER EXECUTIVE SUMMARY As part of Dassault Systèmes efforts to counter threats of hacking, particularly
Mobile Security Checklist An Easy, Achievable Plan for Security and Compliance Introduction Are mobile devices the weak link in your security defenses? Today, organizations are pouring millions of dollars
Symantec Mobile Management Suite One Solution For All Enterprise Mobility Needs Data Sheet: Mobile Security and Management Introduction Most enterprises have multiple mobile initiatives spread across the
Guide To Keeping Your Social Media Accounts Secure Social media is an integral part of the strategic communications and public affairs missions of the Department of Defense. Like any asset, it is something
General Security Best Practices 1. One of the strongest physical security measures for a computer or server is a locked door. 2. Whenever you step away from your workstation, get into the habit of locking
Anti-exploit tools: The next wave of enterprise security Intro From malware and ransomware to increasingly common state-sponsored attacks, organizations across industries are struggling to stay ahead of
Are you suffering from misconceptions about safe web browsing? You might think you re being safe, but with a newly infected webpage discovered every few seconds, it s next to impossible to stay up to date
Interim Threat / Risk Assessment Student E- Communications Outsourcing Project Martin Loeffler Information Security, I+TS Creation Date: Version 1.0 June 24, 2010 Last Updated: Version 2.0 July 6, 2010
Hands on, field experiences with BYOD. BYOD Seminar Brussel, 25 september 2012 Agenda Challenges RIsks Strategy Before We Begin Thom Schiltmans Deloitte Risk Services Security & Privacy Amstelveen email@example.com
Plain English Guide To Common Criteria Requirements In The Field Device Protection Profile Version 0.75 Prepared For: Process Control Security Requirements Forum (PCSRF) Prepared By: Digital Bond, Inc.
Preventing identity theft About ENISA The European Network and Information Security Agency (ENISA) is an EU agency created to advance the functioning of the internal market. ENISA is a centre of excellence
White Paper Cisco AppHQ Enterprise Application Center: Deploy Mobile Business Apps with Confidence The Enterprise Exposed The post-pc era is here, thanks to next-generation mobile devices and applications.
Mobile Security & BYOD Policy Sarkis Daglian Assistant Manager, Desktop Support Office of Information Technology Isaac Straley UCI Information Security Officer Office of Information Technology Speakers
WEB SECURITY CONCERNS THAT WEB VULNERABILITY SCANNING CAN IDENTIFY www.alliancetechpartners.com WEB SECURITY CONCERNS THAT WEB VULNERABILITY SCANNING CAN IDENTIFY More than 70% of all websites have vulnerabilities
How to Protect Your Business from Malware, Phishing, and Cybercrime The SMB Security Series Securing Endpoints without a Security Expert sponsored by Introduction to Realtime Publishers by Don Jones, Series
Ten Tips for Managing Risks on Convergent Networks The Risk Management Group April 2012 Sponsored by: Lavastorm Analytics is a global business performance analytics company that enables companies to analyze,
Cyber Essentials Scheme Requirements for basic technical protection from cyber attacks June 2014 December 2013 Contents Contents... 2 Introduction... 3 Who should use this document?... 3 What can these
Exactly the Same, but Different 1 Shayne Champion, CISSP, CISA, GSEC, ABCP Program Manager GO Cyber Security TVA v1.0 Agenda Define Mobile Device Security o o Similarities Differences Things you Should
5/30/12 Chris Boykin VP of Professional Services Future Com! 20 years! Trusted Advisors! Best of brand partners! Brand name customers! 1000 s of solutions delivered!! 1 5/30/12 insight to the future, bringing
Comodo Mobile Security for Android Software Version 3.0 User Guide Guide Version 3.0.042115 Comodo Security Solutions 1255 Broad Street Clifton, NJ 07013 Table of Contents 1. Introduction to Comodo Mobile
Android Developer Applications January 31, 2013 Contact Departmental Privacy Office U.S. Department of the Interior 1849 C Street NW Mail Stop MIB-7456 Washington, DC 20240 202-208-1605 DOI_Privacy@ios.doi.gov
How McAfee Endpoint Security Intelligently Collaborates to Protect and Perform McAfee Endpoint Security 10 provides customers with an intelligent, collaborative framework, enabling endpoint defenses to
White Paper Three Steps To Mitigate Mobile Security Risks Bring Your Own Device Growth The Bring Your Own Device (BYOD) trend caught on with users faster than IT expected, especially as ios and Android
2015 Vulnerability Statistics Report Introduction or bugs in software may enable cyber criminals to exploit both Internet facing and internal systems. Fraud, theft (financial, identity or data) and denial-of-service
Remote Access Securing Your Employees Out of the Office HSTE-NB0011-RV 1.0 Hypersecu Information Systems, Inc. #200-6191 Westminster Hwy Richmond BC V7C 4V4 Canada 1 (855) 497-3700 www.hypersecu.com Introduction
It s 2 o clock: Who Has Your Data? Josh Krueger Chief Technology Officer Integrity Technology Solutions Your home is your business and your farm is your network. But who has access to it? Can you protect
Mobile application security How security and privacy issues can derail mobile applications Whitepaper 2 Introduction Today, many organisations are rushing to develop mobile applications, to remain competitive
WHITE PAPER: WEB PROTECTION FOR YOUR BUSINESS, CUSTOMERS............ AND.... DATA........................ Web Protection for Your Business, Customers and Data Who should read this paper For security decision
Global Headquarters: 5 Speen Street Framingham, MA 01701 USA P.508.872.8200 F.508.935.4015 www.idc.com WHITE PAPER Malicious Code and Mobile Devices: Best Practices for Securing Mobile Environments Sponsored
Android Security Device Management and Security by Stephan Linzner & Benjamin Reimold Introducing Stephan Linzner Benjamin Reimold Consultant, Software Engineer Mobile Developer Founder of Stuttgart GTUG
Your consent to our cookies if you continue to use this website.