Mobile for B2B: Security Considerations


Published on

Thinking of developing a mobile app for your business? Should you go for a native, device-based application or a web-based application? This white paper addresses some of the security considerations surrounding each approach...

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Mobile for B2B: Security Considerations

  1. 1. Mobile for B2B: Security Considerations Page1Mobile for B2BSecurity ConsiderationsAugust 2011Tom Millard & Rob Hurst
  2. 2. Mobile for B2B: Security Considerations Page2IntroMobile for B2B SeriesThis paper is one of a series we’ve 1. Native or Web?written to help answer some of the 2. Design considerationsquestions we often hear from clients 3. Security considerationsnow that mobile content is firmly on 4. Cross compiled appsthe B2B marketing agenda.Web apps or native apps? How tooptimise content? What should anapp look like? Why might I need anapp and how can it benefit mymarketing activities?This series aims to give some usefulcontext for anyone considering howto make the most of mobile as amarketing channel.
  3. 3. Mobile for B2B: Security Considerations Page 3Introduction website. It is therefore important to consider the same set of security issues as you would with any other web development project.Security is as big a Native appsconsideration on mobile Native apps, on the other hand, aredevices, as it is on any digital downloaded from a secure location, such aschannel. the iTunes app store, and are then stored securely on your device. They can thereforeHowever, the convenience factor of a mobile often be used without a data connection andapp can lead people to treat it with though they often connect to the web in ordercomplacency, putting less consideration on to access information, they do so by accessinghow secure the data stored or accessed via an the device’s connection securely. One of theapp really is and users mostly have none of the downsides of this third party deliveryobvious PC safeguards (firewalls, virus mechanism is that any future developmentscanners etc.) in place. that the app may require will be subject to delays during app-store approval processes,Consequently, there’s an argument that meaning that a discovered security flawsecurity is actually a more important cannot be amended as quickly as with a web-consideration than on other channels. Here we based application.highlight some of the security issues to be Deliverymindful of in two key areas – app delivery anddata transfer.For each organisation and for each app thesecurity risks and considerations will bedifferent – but all apps, as with any digital mechanismscommunication, are vulnerable to attack.Awareness of the main issues will mean youcan evaluate the best approach for your needsand determine potential issues at an earlystage. Publishing an application through an app store can provide additional security over a webWeb or native? app. For example, Apple’s app store requires that all applications be submitted for review, before they can be offered through the store.Let’s start by simply defining the two main This means app store staff can reviewcategories of mobile apps from the point of applications and confirm that developers areview of some of the security considerations.. legitimately involved with a company.Web apps It’s not all plain sailing, however, as Google’s Android Marketplace, which doesn’t have theA web app is any content developed for a same rigorous approvals, has been criticised inmobile device but accessed directly through a the past for its potential security flaws, withbrowser. Consequently they are theoretically instances cited of phishing scams beingmore vulnerable than native apps as they are implemented in the form of fake-brandedopen to the same security issues as a standard
  4. 4. Mobile for B2B: Security Considerations Page 4mobile banking apps, getting users to input attempted hacking - and this is the keytheir personal details, which are then hijacked. difference between the two.Additionally, publishing an app through a Native appsdevice-specific app store requires that the appby publicly visible in the store – where any Device and operating system manufacturersuser can potentially discover it. This means are aware of the potential security risksthat any user can download the app, whether it associated with apps connecting to theis intended for them or not, and so security internet. Each manufacturer offers a stand-like password protection, use of a corporate alone API (application programming interface)login ID or account number might need to be for their platform, which adds a desirable extraput in place to secure any content that is not layer of security. Apple, for example, have aappropriate for public visibility. special inbuilt API which iOS developers can use to encrypt the information they areConsequently native app stores do not offer a sending from the device – making it moreunified level of security, but can be more than web-based applications, hosted inthe same way any website is. Google’s approach with Android is to run each app in something called a ‘Silo’ which preventsConnectivity an app from accessing other areas of a device. Apps then need to be given the appropriate permission (by a pop-up warning on theIn most cases, apps receive and transmit data device) to access anything else which it mayto the outside world, for example accessing up need to use in order to function, such as GPSto date information, search functionally or a location data and so on. Each app is alsoform submission. distributed with a digital ‘certificate’ which contains all the details of the developer.All out-going information, Other platforms have similar securitywhether sent from a web-app measures. All of this means native apps relayor a device-based native app, information through secure connections and/or via encrypted means, keeping yourneeds to be secure, and the customer and client data safe – a huge benefitinformation that is being for B2B organisations. The downside to this increased security is that each platformreturned needs to be trusted. operates in a different way, potentiallyThis security will scale requiring separate and comprehensive development for each device.depending on the nature of theinformation being sent. Web appsSo, what are the considerations you need to Speaking broadly, web apps are ‘open’ as theymake? reside on the web, though of course security can be put in place.No native app can be accessed externallyunless it has been set up to do so, or givenpermission. Web apps, conversely are open to As web apps are open, they are great to build, from a
  5. 5. Mobile for B2B: Security Considerations Page 5development standpoint, but more recently, are gaining increasing numbers of advocates, especially with businessesfrom a security point of view; handling potentially private data. Manythey hold the same risks as any businesses that handle financial transactions, banks such as HSBC and Lloyds TSB and onlineother website. bookmakers such as Paddy Power and Ladbrokes are using web-apps, rather thanRisks could include a hacker attempting to native apps, to cater for their customers acrossintercept all the data passing through a or to a particular device and analysethe contents, or trying to obtain access Additionally, as mobile platform owners andthrough the log in screen. manufacturers look to increase revenues from apps utilizing their platforms, this increase ofThe danger here resides in the fact that an app web apps for transactional or paid functions isis often built to replace or manage a specific likely to continue. Apple has alreadyfunction of a website, rather than recreate an announced a set of rules for ‘subscription’ appsentire website. Often this will be a function that require they receive a 30% cut of thethat involves sending or receiving private revenue.information to and from a device. As such, ahacker can attempt to hijack this individual This brings us to our final point, somethingfunction, rather than a website as a whole – a which can help increase security aroundmore targeted approach, potentially allowing applications for a more targeted audience – afor a higher success rate. bespoke app store environment. Large corporations that produce multipleA web app can, however, be secured like any applications for their customers and worknormal website using an SSL (security) force are starting to make use of this approach.certificate which is granted by a trusted A notable example is the US army, whoseprovider and forces use of a secure HTTPS applications are, understandably, somethingconnection. that the general public should not have access to. Whilst this approach is obviously veryConclusion secure, it’s likely to be beyond the requirement of most application developers.Both native and web apps have their positives,and negatives, when it comes to app security. Read the rest of the Mobile for B2B series.Native apps, whilst allowing better offlinestorage of information – keeping your 1. Native or Web?customers details offline, are slower todevelop, with a new application development 2. Design considerationsneeded for each platform. Web apps, on the 3. Security considerationsother hand, can reside on any platform withone development – and any security concerns 4. Cross compiled appscan be tackled much quicker, but they maylack some of the peace of mind gained with anapp-store download.It’s worth noting that web apps, which havebeen growing in popularity against native apps
  6. 6. Mobile for B2B: Security Considerations Page6Omobono is an award winningdigital agency specialising in branddevelopment and engagement forlarge corporates and government.We believe no one has a betterunderstanding of businessaudiences and how to reach them.For more information, please contactRob Hurst on or+44 (0) 1223 307000.© 2011 Omobono Ltd.All ideas, concepts, brand-related names, strap lines, phrases, copy/text andcreative concepts developed and contained within this document remain theintellectual property of Omobono Ltd until such time as they are procured by athird party.Anyone viewing this document may not use, adapt of modify the contents withoutour prior consent.