At a recent speaking engagement, I told the story of this creepy dude who sat next to me on the plane down to Orlando. I don’t know if it was his bogus Scottish accent or strange dental work, but I got the feeling he was shoulder-surfing me while I was working on my iPad. I got a picture of him leaving the airport…
It turns out that was MY iPad he got off the plane with, which he lifted while I was in the lavatory. I called my company and they were able to wipe the device with MDM. I had to wonder though, how long would it take any good super-villain to get the data they wanted off a device? He most likely had the device password after watching me punch it in on the plane.
I had another presentation to deliver a short time later, so I used my backup iPad, a first generation model. It doesn’t support mirroring, so I would need to jailbreak it in order to support display to VGA. It took me all of 10 minutes to do so. I thought back to the incident on the plane. What would Bane do? He probably had the device broken and all of the data pulled off before it was wiped. Then I had to ask myself, what data did the mobile apps I use keep on the device? It’s not always obvious to me what apps are storing data on the file system. I do know that developers make it easy to access apps once you’ve signed in the first time so you don’t have to do it again. How could I have mitigated this risk once my device was compromised?
Mobile application management (MAM), paired with a robust identity access management solution, could help. In this scenario, we’d be essentially looking at a corporate app store: Applications downloaded through the MAM are vetted through the company and thus have some degree of governance. MAM can apply application-specific policy for those apps that come from the MAM app store. Some of these policies are very MDM-ish in nature (prevent access when a device is jailbroken, or prevent apps from storing data locally for instance), but specific to the app. This is nice on the BYOD front, as a company can protect its interests without wiping out someone’s personal data that happens to be co-located with the corporate apps. It also helps with the Bane scenario, because for the apps that matter to the company, data is always kept off the device.
The more interesting part to me, though, is the authentication aspect. The ability to require authentication per application provides a consistent experience, linking the MAM with the corporate access management system. Through a web view and SAML approach, you can authenticate to the app, propagate identity to the service provider, and get SSO within the device.
Once you’re linked in with the IAM, then you can start applying context-based authorization to the scenario. How did the user request to authenticate, from what device, and what time of day? Where was the user when he requested the app? What is the historical profile of the user accessing this application? What is the environmental risk condition presently? How sensitive is the application or content being accessed?
Using a risk engine, the answers to these questions can be leveraged to generate a verdict that might trigger second factor authentication to be required before giving the user access the cloud resources. With that, Bane might have device access, but he isn’t going to get to the more sensitive apps.