Developing Mobile Apps in a Hostile World: Part 1

Good morning it’s Julian here once again, this time with part one of a two-part series on points to consider when developing enterprise applications. I know this will be a little obtuse to those who aren’t actively working in the sector so if you’ve any questions please do add them below and I’ll respond.

Here we go…

– – – – –

If you want mobile users to be productive they need the information to do their work at their fingertips no matter were they are. Getting from a desk bound company to a mobile one requires a lot of legwork, little of which appears in the colour brochures.

What follows is technical but I would hope that any project manager or mobile infrastructure architect will be able to scan through it and say: “we got that one”, “hmmm”, “I think he missed a trick”, “good point” (etc).

These are only starting points: For a number of them you are going to have to spend some time with legal, maybe compliance and probably IT security to see where they rank on your firm’s risk list. What is a problem in banking is not in pharmaceuticals. What the regulators in London will issue £100m fine for may not bother anyone in Hong Kong. If you don’t run voice over IP then don’t worry about solving it for mobile.

In Part 1, I will:

• Address the easily skipped bit regarding getting your information flows from data centre servers safely onto the internet
• Illustrate that encapsulating your data is not something you may want to delay

And in Part 2, I will:

• List the user groups for mobile solution infrastructure design
• Show secure app development over the internet is both necessary and possible
• Suggest a solid list of apps that many users would consider required for utility, security and regulatory compliance: including voice
• Run through ways to integrate mobile app development so it works well for traditional devs as well as app specialists.

Mobile Data: The Double Headed Eagle That Will Bite Your Kneecaps Off

Let’s say the factory services group in Minnesota wants to use iPads running an app they are writing locally. It will allow supervisors to tap into the plant control and HR systems so they will be able to see what what products every machine is working on, who the end customer is and the staff member allocated to it.

If the device goes missing you will end up with a bunch of confidential commercial, HR and production data “out there” but that is quantifiable and the risk can be managed. In some places you might characterise this as low impact data – but in parts of China it could be quite a nasty loss. CIO after CIO is being quoted as saying losing data from mobile devices is their biggest nightmare. But there are two parts to this problem and it is the other part that you hear very little about in the press.

Look Server Side

The elephant in the enterprise room is that you will be exposing data systems, like HR or production control, to the internet which have never before permitted their data flow to hit the company’s DMZ, let alone fly out through the external firewall. Now you are allowing connections from the mobile telephone network, anywhere in the world, into your intranet and your servers, 24 hours a day, every day of the week. Depending on where you work, some of those servers may hold data whose release actually would cause problems for major governments.

Even if it doesn’t scare you, it will scare your corporate risk team.

While locking down your devices will satisfy your CIO and probably was the initial justification for the MDM project, locking down external access your intranet access is something you need to do as well. Even if you are planning to use a SaaS MDM installation you will still need DMZ and intranet servers to control access to your business databases and email.

It is not helpful, but MDM sales and installation glossies typically include front page pictures with dashed lines flying in from mobile devices through the firewall (“just open port 8789 and the universe can be yours”) to the servers. Page two may show a couple of boxes in the DMZ. A global MDM vendor’s MD trumpeted, “for the truly paranoid we support a reverse proxy in the company DMZ”. That last implementation, on page 12, is the only right one but the breezy language that preceded it affects how long people think this will take.

In the initial whiteboard/back-of-the-envelope planning stage, there are some very good things to bring up early. If you put these into the centre of a mind-map hopefully you, and the teams you call on, will start to describe something robust and workable.

Certificates for authentication: Speak to an expert – the people who really know this stuff are legends and this isn’t a subject for internet fuzzy niceness. Generally, the more certificates (per device, per app if possible) the better because these are the one control you can kill on your side if a device goes missing and offline. My first piece of advice is make sure no traffic gets through the reverse proxy without a valid “corporate ownership” certificate and only then do you think about authenticating users. My second piece of advice is never use intranet server validated passwords on mobile device: use one time tokens, RSA keys or whatever. In most companies, intranet single-sign-on usernames and passwords are the highest grade security information that any user has in that domain. They shouldn’t be used on client or vendor sites. In some places usernames and passwords aren’t even trusted: it is two factor internally and externally and, yes. some MDM vendors struggle with this. Whatever. Use something unique for mobile authentication.

Secure mobile data flows need their own solution: Do not assume that you can piggyback on your VPN server farm for secure app communications – it very nearly works, almost to the point that you can be railroaded into it. However, VPN connection licences are stupidly expensive, probably fully allocated and the degrees of control that systems like Juniper give you are fabulous and way over specified for simple data streams. On paper, per app VPN sounds far more appropriate than, I assure you, it will be once you are writing lots of apps. Consider 1,000 remote concurrent app users tying up Juniper endpoints and then picture 20% of them flipping to a different app triggering a new session every 3 minute, as people tend to do on mobile phones. Using full device VPN doesn’t work either because it breaks Apple Push Notification Service and thus MDM – unless your company allows unsolicited inbound network connections from anywhere in Apple’s class A network (which, I think we can all agree, it doesn’t).

Instead use your MDM/EMM vendor’s carefully designed SSL hardware/SDK supported solution. AirWatch’s solution allows you to integrate it into your own apps via their SDK, or wrap any normal app with their software, so that the data back haul is encrypted using SSL to your AirWatch DMZ cluster. It integrates with your certificate authority on a per-device/per-app basis. If you use a CA hooked into AirWatch’s externally facing device service module, its internally facing console and your intranet directory service, you can issue and revoke certificates in real time so that your app, DMZ gatekeeper and AD reliant servers all respond independently but at the same time. Credentials can’t linger on offline mobile devices for nasty people to reuse. Also, in AirWatch, you can easily manage the certificates on the same L1 console page that you use to manage lost devices.

Go to market and find a really good MDM/EMM company that will provide you with 90% if the infrastructure software support you need and 95% of the mobile device OS services abstraction support you definitely need. I like AirWatch because I have actually got this kind of infrastructure implemented and integrated quickly – for other people, products like Antenna, Citrix, MobileIron, Maas360, BoxTone, Afaria (SAP), Good Dynamics appeal. As with all infrastructure software you need to base your choice not only on features but also on market dominance and your ability to recruit skilled people over the next 5 years.

Once you have an authenticated device and user, you can switch the data stream into your intranet and permit your internal end systems to treat it like any other marginally distrusted request from within the network.

Plan for Stage 2 with secure data channels, email etc happening 4 hours and 30 minutes after stage one is working: Setting up the DMZ infrastructure for apps and data is well understood but can way too easily be indefinitely deferred during an initial MDM implementation. This is because the focus is on securing the devices. As Chris Marsh of the Yankee Group notes, pure MDM is the starting point for most firms but once it is done it becomes obvious that Apps will follow really fast. The, “get it done and get it done now” culture in big organisations often prevents discussing next week let alone what will be required in six months. New hardware in corporate data centres can be expensive and slow to order, especially when you are clustering and pairing in high availability configurations across countries or regions. So, my advice is get all the possible hardware ordered up front.

Look Mobile Side

What is needed on the mobile device is really quite well understood by the vendors, analysts and commentators but it changes so, so fast. You don’t want to secure the device, but you do want to secure what is on the device. It is probably worth saying the obvious that mobile security is impossible to guarantee if you loose the device. Whoever has the hardware can do what they want given sufficient time and skill.

What you require is a group of coordinating apps on the device that trust each other to appropriate degrees given the threat model you are happy with. The enterprise platform that app writers can depend on, within this circle of trust, includes generic components such as email, share-point, document reader-helpers, instant chat and voice. iO7 supports mutual trust between managed apps and Samsung Knox is similar (as is Blackberry’s Balance). These work on devices whether it is enrolled in MDM or not which means you can provide a single eco-system of apps that all of your developers can rely on. It doesn’t matter if the target is corporate devices or BYOD.

The solution is, at last, transforming from a secure device into a secure platform with services.

Look Inwards – Know Thyself

If a device is lost, can you say what precisely is missing?

If you lose personally identifying data, in many jurisdictions and regulatory regimes you will have to notify each person and say exactly what was lost: no more and no less.

Do you have any mechanism in your business that would enable you to quantify this? Could the L1 service desk workflow, “User reports they have lost their mobile device” automatically kick off a report to the regulatory compliance team?

Planning for data loss in companies operating in the Square Mile is not about shutting your eyes and wishing. Devices and data will be lost.

The regulators will punish data loss. They will hang out to dry any company that hasn’t even attempted to get this right. The sorts of fines that the SEC and the new regulatory arm of the Bank of England can issue should be large enough to pay for some thinking time. Clarify with with your legal and regulatory compliance teams where your company stands with this.

Encapsulating the data: Some of you (particularly if your background was in enterprise data systems) will remember the notion that data is saved in detail but queried through semantically defined “data objects”. These could be implemented as queryable stored procedures in the database, within “universes” in Business Objects(TM), transformations in Informatica(TM) or some sorts of statistically things in SAS(TM). The driver for this architecture was initially “write your own reports”. However, requirements for regulatory and financial reporting meant that all reports required the same well defined data semantics for the regulated components to ensure that ad-hoc and standard reports were consistent.

My experience is that most data-warehouse and reporting solutions got about 80% of the implementation done and then gave up.

What I am proposing here, wearing my dusty data architect’s hat, is that only properly semantically defined data objects should be allowed to be used in mobile apps. I have written a couple of regulatory reporting frameworks in my time and this feels like exactly the same problem, for a very similar business driver and so the same solution should work.

Data objects allow querying in several dimensions: time, name, location etc, depending on the object. The better defined the semantics of the object typically the fewer dimensions you can query. If you define the objects right, they can even be updated. The actual solution is not particularly technically novel: few of the things discussed so far about mobile infrastructure have been. The work will be getting the data architects, database managers and data systems support teams identified and on-board. If you know exactly what you want and why you need it, you should be able to drum up some agreement quite quite quickly within the database groups. When, later, the apps teams come to use corporate data, you can steer them in the right direction to the right people. You can facilitate great architecture.

Data as inventory: If each app can check-out and in every object with a record of the dimensions using the MDM/EMM console. Voila! You have an accurate data inventory. OK, any offline data acquisitions may be missing from the inventory but that information can go into the police report as an appendix (or, better, get some advice from your legal team). The problem for today is that I don’t think any MDM/EMM supports this kind of thinking yet – but they will.

The great thing is you do not have to complete the implementation of data objects for every single database in your enterprise (which would be impossible in every company I have worked in recently). Only the data which mobile apps use needs this treatment. Provided your app writers work closely with the data architects, preferably with a long range plan, the query layers can be built up as required without any impact on existing systems.

Further, if you are a fan of treating data as an asset, the data-as-inventory model will give you some great material for analysis and a good angle on calculating return on investment.

The Take Home

Taking a company mobile isn’t so much about doing anything directly yourself, but ensuring that those whose job it is to make the visible bits work can do so. There is no glamour in it. If you can coordinate the infrastructure work including:

• Certificate authority deep integration with the device, apps, servers and the MDM console
• The hardware to handle the data back-haul per-device and per-app
• Up-to-date data inventories

If you get it right at the very start, then actually implementing it all and hooking it up is quite quick in my experience – just two or three weeks of 15 hour days will do it.

The art is getting legal, compliance and HR on board. Then convincing the identity management, IT security, active directory, data architects (for each global division, for each management group, for each database), CTO and remote access teams that the mobile regulatory priorities are well thought through and you can, with everybody’s help, actually satisfy them.

Hopefully you can do that now.

Part 2 is all about giving your software development teams a development and device platform they can really use and make hum for their clients. All good stuff and it includes details on how to do that without opening new company wide attack vectors!

Stay tuned!