Securing corporate data in a mobile world

While some organisations demonstrate a remarkably casual attitude to mobile security, more sophisticated ones are adopting a multi-layer approach to securing corporate data.

These include considering and actively addressing the following elements as a minimum:

• User: individual-specific log-ins and user profiles; monitoring usage patterns
• Device: enforcing “strong” passwords; applying security policies to personnel and using “native” device encryption capabilities
• Apps, including email: data containment and secure document sharing
• Browser/web access: applying white lists / black lists; using secure browsers; considering fundamentally how access is provided to the internet
• Network security.

Corporate policies and processes should of course be put in place to minimise the physical loss / theft / damage to mobile devices. Should the worst happen, there should then be the facility to remotely wipe all sensitive data and/or block access to corporate systems.

IBM, with a highly technically-competent workforce, offers a very high degree of flexibility in its staff’s use of corporately-connected mobile devices, but manages the various layers of security very tightly

Another important area in securing data is to consider what should be stored locally in the first place, noting that the aggregation of data on a single device increases the potential security risk. For example, in some “sensitive” facilities, only the information required to perform a given task is sent to the mobile device: this can then be deleted once the work has been completed and the next task and associated data sets transmitted.

It should also be noted that there will be many different use cases within a single company to be considered from a security perspective. This can be a complex area and indeed, several firms such as MaaS360 (recently acquired by IBM) are wholly specialising in mobile security.

Adoption

Obviously, if workers do not fully embrace and utilise the devices they are issued with, the anticipated mobility benefits will not be achieved.

Part of the reason for the relative unpopularity of some once-popular brands, for example, is that they are not considered “cool” by many of their corporate users who have access to far more sophisticated phones in their personal lives. Two key factors often repeated in successful mobile deployments are:

1) offering modern, easy-to-use and physically attractive devices

2) personally allocating them to individuals, thus promoting not only better care but often significant investment of personal time in learning how to use them better - as well as users charging their devices at home

Other points to consider include whether or not to:

• allow personal use
• permit personal data and even apps to be loaded
• offer phone calls and/or mobile data use outside work.

There is probably no single optimal approach to these variables. In one recent successful client deployment, personal use was permitted, but only Wi-Fi access was allowed for non-corporate apps. On the other hand IBM, with a highly technically-competent workforce, offers a very high degree of flexibility in its staff’s use of corporately-connected mobile devices, but manages the various layers of security very tightly through advanced software that it also sells to its external clients.

The popularity of BYOD policies (sometimes with a corporate contribution to the initial cost of the hardware) offers its own challenges, but these can be effectively and securely managed and of course offer the ultimate flexibility to staff in the choice of their devices.

Organisations need to be careful of “big brother” concerns, especially the GPS tracking of staff in highly-unionised situations, but it has generally been found that making the adoption of corporate mobile devices sufficiently attractive to users through some of the techniques mentioned above can outweigh and overcome such fears.

Other points to consider

The physical characteristics of mobile devices: screen size, weight, battery life, degree of physical protection, technical features etc are important for their intended use, and there is probably no perfect “one size fits all” device within any organisation. End-user input is essential in both the choice of physical device and the configuration of the apps running on it. These should not simply be a reduced version of a “full-screen” application, but ideally fundamentally re-thought from a “mobile first” perspective that closely considers the practicalities of mobile users’ situations and how the devices will be used in the field. Simplified options at each stage following careful process design that considers what data really needs to be captured and/or made available at each stage can make a huge difference to the effectiveness of the mobile user interface.

Aside from the choice of individual physical devices (which may be quite wide, especially if BYOD is allowed), the underlying operating systems (or platform) adopted can be an important consideration. While Apple’s IOS devices remain popular, Android units from a wide variety of manufacturers have recently surged, with Windows Mobile and Blackberry platforms declining in a number of areas of use. Quite how sensitive the choice of device type is to an organisation is partly related to the type of apps being used. For example, many enterprise software packages will now support both IOS and Android as a minimum.

However, these can also be limited to certain specific models of device that have been tested to work with them, with other devices on nominally compatible operating systems requiring a degree of customisation to work effectively.

There are also mobile software products that allow the development of multi-platform solutions, for which the apps can effectively be coded once and then readily compiled for different operating systems and devices (an example being IBM’s own Worklight suite, on which many of our existing mobile software products are now being re-written to take advantage of the flexibility that this approach offers).

When developing or selecting solutions for specific use cases, there is sometimes a choice to be made between an “always on” approach where permitted by connectivity and a more complex app that also permits off-line working, storing data and allowing local transactions when no connection is available.

Finally, the whole topic of device management - provision of network access; device deployment and return for repair; software upgrades etc should be carefully considered and optimised for the specific organisation’s needs.

Simon Parsons is the European lead for asset management consulting services in IBM’s business services; travel and transport; life sciences; consumer products and retail industries