Mobile App security the elephant in the room 10

Share this:

Hackers don’t need a reason…

In January, Apple announced App Store sales hit $10 billion for 2013. This number will surely grow this year as there are around half a million native iPad apps available on the site. Add Android apps available from other sites to the mix and the number becomes much higher.

It’s clear that mobilisation is the way of the future. But it introduces security risks that CIOs need to address.

As you mobilise your workforce, users will need to download apps for work purposes, resulting in the need to integrate some of these apps with back end systems on your network.

Securing these apps will be increasingly important as they become more distributed through APIs. Combine the sheer volume of apps already created with the social requirement for mobile devices to run apps for work and play, and the potential for risk of attack grows exponentially.

Bugs in any non-work apps for instance, can potentially compromise your systems and could even provide access to a mobile device for further hacking.

This is not new to IT; we are used to playing catch up and implementing workarounds or finding ways to mitigate risks and security issues, but never before on this scale.

Many of us have spent the last 20 years concentrating on securing our networks. For the most part, application security has been left for the vendor to deal with. We just facilitate it.

Much of the current literature we have focuses on securing the network, while code and data layers have received considerably less attention.


Protect your IP

The point here is all about focus. Data and application security needs to be a focus point for the next generation of corporate mobilised applications. The point of view matters – it’s a completely different mindset in the app world.

Banks will have a distinct advantage because most of them will have gone through the PCI DSS process, which includes application security. Unfortunately, the rest of the corporate world is just starting down this track.

Understanding the security gaps in application data and/or code structure will require in-depth institutional knowledge. Although the IT security industry is growing, I wouldn’t consider it anywhere near large enough to cope with the app boom.

The business of IT needs to understand the message properly – finishing a security project to implement a level of security does not conclude the engagement; rather, it is only a starting point for the future of mobilisation.

When you consider app security it should not be as an academic exercise for cost/benefit analysis. There will be situations where your return on investment (ROI) will not support a critical initiative.

However, you have to consider how much greater the damage could be to the brand or customer base if your company were compromised. Can you afford that risk?

App security should become a part of the design included in every new app release and should be part of the scope of a tender if you are engaging a third-party for development.

Here are some things to consider when you are introducing new apps to your network.


Develop with security in mind.

  • Establish a risk profile for your apps – consider the value of the information they may contain.
  • Integrate industry standard best practices to build your application development security framework. This may require specialised staff or contracts.
  • Realise what your security pain points are in your current applications and then develop a process and build the framework around these gaps.
  • Develop secure APIs and if they’re only for business, lock them down.
  • Create a policy or procedure for pre-defined app development requirements. Applications should be designed and implemented with security in mind.
  • Consider a mobile device management suite to secure devices and corporate apps.

I’m not suggesting an intrusive or disruptive complete overhaul. But consider seriously how you plan your mobile security and API development based on the risk that already exists.

Remember, the number of mobiles running corporate APIs to apps will increase the number of possible breach points into your network.

You simply can’t trust third-party unsigned code or applications completely without verifying that the data and/or code has not been tampered with during transit, under execution or by design.

Mobilisation is a great move forward for many businesses. I am convinced it will minimise costs and create greater flexibility in the workforce. However, it must be leveraged within the context of the threat and possible damage to the brand and therefore the business.

First posted as an article on

Total views


Rod Byfield

About Rod Byfield

Once a wayward rural kid originally from the small town of Kandos in central New South Wales, Australia. I have always held the belief that given the right environment anyone can achieve whatsoever they desire.

10 thoughts on “Mobile App security the elephant in the room

  • Richard Gordon

    While I agree with you that mobile app security is the elephant in the room – the way I look at it, cloud computing is the rampaging elephant that sooner or later will break its tether and head for the door.

    The one chance we have with mobile computer is the growing availability of mobile security products that allow an organization to send a kill command to a device to wipe out all corporate data. Depending on the structure of the app most of the data is stored on the server, and not the device.

    With cloud computing we have users who are typically able to access all data from any edge device (to include grandma’s Windows 95/XP box that has not been patched in the last four years). While there may be a small chance to inject infections into the cloud, there is a very high chance the user’s credentials can be copied by a bot – allowing the bot to create a synthetic identity used to mine cloud hosted corporate data. Without two-factor authentication it is only a matter of time before the peanut eating perturbed pachyderm pounces protections purported to protect us from pirates – yielding published portrayals of our pitiful punctured platform placed on the front page of the Washington Post.

    • Rod Byfield
      Rod Byfield Post author

      Nice work Richard – I certainly enjoyed the tongue in cheek “peanut eating perturbed pachyderm pounces protections purported to protect us from pirates” Excellent! Gave me a good laugh.

      Your correct that the Cloud has issues – but I guess the one thing I would mention here is that most reliable cloud solutions have the ability to set group and user level permissions. Used correctly you can isolate or set policy that sets an information standard for the cloud.
      But even I recognise there are complications in the cloud that still have to be rectified – in fact I wrote an article on it last year for – If your interested:

      Unfortunately many network able Apps that may co-exist with corporate apps have no level of authentication and or restriction for that matter. In fact the way the App is developed in the first place could mean that your corporate standards have already been breached.

      Yes you can kill/ wipe – but this only really helps if you know the device has been stolen / lost – you have no way to check wether an App on the device is being used to compromise your corporate communication.

      Thanks for your comments Richard – really good food for thought 😉

  • Ankit Shaw

    Mobile OS Sandboxing will ensure that intra app security is not compromised, but most consumers are not aware of what level of access an application require and blindly accept all authorization. The major work will involve at App Store end to ensure that any app not requiring access to particular area is blocked from sale , there by increasing the security for end user.

    All apps need to store data in encrypted form in the mobile device to ensure full data security (only a handful does)

    I am looking forward to profile sandboxing that will allow users to manage work apps under one profile and play apps on other and keep them separate at OS level profile.

    • Rod Byfield
      Rod Byfield Post author

      Hi Ankit,

      Thanks for your comments!

      Profile sandboxing with group and user management – will help. Also If they bring out tablets / phones specifically for the office / corporate worker hopefully they will include this type of secure integration.

      Sandboxing is a great start – but it is a mitigation technique and does not resolve the larger issue with insecure/ unsafe practices in App development.

      I agree with you about the “App store” statement, and that some of the responsibility could reside with them – but i think the issue is more wide spread. In my humble opinion, the new App industry that has popped up over the past 6-8 years is were the true responsibility lies.

  • Richard Gordon

    Great article!

    Whether your data is in Amsterdam or Australia is not the first question that comes to mind. When a corporation executes a cloud jump (typically without thinking through subsequent jumps, or a full scale cloud retreat) it assumes that the new home for the data operates relatively similar to their on-prem solution. There seems to be few questions regarding server patching, separation of duties, backup strategy, off-site tape storage, destruction of decommissioned drives, etc.etc.etc.

    When speaking with cloud sales folks their eyes glaze over when asked questions beyond, “Where do I sign”, and “How many accounts can I create?” The classic comeback I have experienced has been “We are web and mobile ready.” which only increases my anxiety as the dirty details are obfuscated behind a “Cloud” (I could not resist) of pseudo geek-speak meant to demoralize the average consumer and befuddle even reasonable geeks when the cost savings are thrown in your face like a hand full of flour.

    Securing the login process, VPN or SSL channels are all well and good – the problem has a lot to do with digital dust. When accessing the cloud in a way that allows you to retain state, or to work offline – there is no true cleanup process. Suddenly the personnel file accessed by the Human Capital Officer is on her son’s iBook because it was faster than her corporate laptop. The legal documents articulating the company strategy for an IPO are on that loaner laptop because the CFO’s new Dell laptop was still being prep’d.

    Interesting enough – the problem is not new…..just more widely dispersed. When we provided remote access to corporate data we opened the door to data leakage, which is now moving rapidly to becoming a full-fledged hole in the the super retaining walls we erected to protect us from all harm.

    • Rod Byfield
      Rod Byfield Post author

      Thanks again Richard – I’m glad you enjoyed it 😉

      I have had a very similar experience with “cloud sales” and the same or similar responses. Which in keeping with your pun – is not the ‘clear sky’ answers we were looking for.

      Regarding online/ offline – my general inclination is that this is more a Governance / Policy issue. If you have super sensitive IP, it should be clear that the ‘sensitive brand risk’ information is unfit for the cloud, or it should based on internal governance with procedures for responsible use.

      I personally don’t have an issue with data being available as needed – But It is up to us to make sure the business is aware that every additional file that contains IP in cloud, could potentially multiply the risk to business.

      As technologist we cannot protect against a misguided decision while working offline – But in this case I take the line that ignorance is no excuse – If you are responsible for the business IP then you should be aware of the sensitive nature of it.

      Your right, the door was opened a long time back with remote access. I personally don’t see that door closing; in fact it’s already the size of a ‘several car garage’ getting bigger as we speak.
      – Have a great weekend mate.

  • Ben Johnson

    Great article. Indeed, the mobile application era is rapidly expanding. One issue I think a lot of IT departments may be having trouble grasping, is not only the problem of implementing new policies/procedures for rolling out byod or mdm. But realizing, with the incoming rush of the mobile environment, also comes new vulnerabilities and new attack vectors that they haven’t seen before and know little or nothing about. Unfortunately, these applications are often times pushed out quickly in order to meet client demand; leaving security as an after thought.

    As you stated, we are used to playing catch up and implementing workarounds or finding ways to mitigate risks and security issues. While it is easier said then done, with this new mobile environment, playing catch up and implementing workarounds is not going to cut it much longer. Mobile is such a rapidly developing entity, that security is something that can not be left to be an after thought any more.
    As you mentioned also, I wouldn’t say the IT industry is anywhere near coping with this boom either.

    While banks have advantage of already going through pci process. I think that also puts them at risk. For example, if I was a criminal targeting bank ABC’s mobile application and have somehow found out they’ve already gone through pci compliance process, including application security, there application is really going to be tested to see just how thorough the application assessment was; and this is where the secure coding really comes into play, I think.

    • Rod Byfield
      Rod Byfield Post author

      Thanks for your comments mate, I appreciate it. Your absolutely correct re:banks and the flip side of this would be a massive internal PCI investigation that would more than likely go public causing more hacker interest.

      One of the other critical factors is that a lot of companies will not have the “scalable infrastructure” required for Mobile on mass – meaning this will be left to a third party also. Food for thought while developing/ work-shopping any SLA or Contract I guess 😉

  • Marta Ganko

    It is the unknown elephant in the room indeed, and when it reveals itself, the world will not believe where it has come. Reading your article made me think about the number of apps prior to installing, requesting permission to access parts of the phone memory, and how much data could be taken off the phone which may be storing personal and corporate information. It would be interesting to see how Bring Your Own Device policies are working in organiations with installed apps rather than remotely logging into virtual environments.

    • Rod Byfield
      Rod Byfield Post author

      Thanks for your comments Marta – I didn’t really go into depth about permissions within the article, but you are so right. Permissions that many App’s request and we then forget, opens up another unquantified risk to business. There really needs to be a lot more rigour in the development of Apps.

Comments are closed.