At CSA Congress earlier this month, I told the story about this creepy dude sitting next to me on the plane down to Orlando. I don't know if it was the bad scottish accent or the strange dental work, or the feeling that he was shoulder-surfing me when I was working on the iPad. I got a picture of him leaving the airport...
Yea, turns out that was MY iPad he got off with while I was in the bathroom on the plane. I called my company and they were able to wipe the device with MDM. I have to wonder though, how long would it take any good super-villian to get the data they wanted off a device? I had to assume he had the device password since he probably saw me punch that in on the plane.
I needed to present again off my backup iPad, a first generation model. It doesn't support mirroring, so I would need to jailbreak it anyway in order to hack the device 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 those mobile apps keep on the device? It's not always obvious to me what apps are storing on the file system. I do know that developers make it easy to access the applications once you've signed in once to app, not to have to do again. How could I have mitigated this risk once my device was compromised?
I've found that Mobile Application Management (MAM) paired with a robust access management solution can help in a lot of ways. With the MAM solutions I've evaluated, the theme is essentially a corporate app store. Applications downloaded through the MAM have been 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 MDMish in nature (prevent access when 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 the 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 remote from the device.
The more interesting part to me, though, is the authentication aspect. The ability to require authentication per application provides a consistent authentication experience, linking the MAM with the corporate access management system. Through a web view and SAML approach, one 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 authenticate? What device? Where was the user when he/she requested the app? What is the historical profile of the user accessing this application? What is the environmental risk condition presently? What time of day was it accessed? How sensitive is the application or content being accessed? Using a risk engine, these factors can be leveraged to generate a verdict that might trigger a 2nd factor to be required before accessing the cloud resources. Bane might have device access, but he isn't going to get to the more sensitive apps.
