Mobile Devices and Securing the Wild.
How do we secure against the threat of #mobile lost devices now and in the future?
Security and application accessibility is a chicken and egg question. Of course you develop apps first in an emerging space, but when do you introduce security? While developing? While the space is developing? After the space is matured and attacks have become a fact of life?
Right now it seems that the focus of organizations everywhere when it comes to mobile is providing new ways for users and employees to interact through mobile devices. That’s a great place to start, since the mobile paradigm is a different beast than the desktop paradigm (a great read on one facet of the differences is this page from the Android Developer site – Android Design). While it is necessary to get applications and new access methods out there, we’re still struggling with basic security issues. The same things that scared many organizations off of Palms when they first came out and USB keys later plague mobile devices (of which Palm was one, though certainly an early generation)… How much data is being carted out of the building and by whom, what happens if a trusted employee loses their device – which is a different question in the BYOD world than the IT issued device world… You cannot wipe a BYOD device remotely, and there’s a good chance you can’t force the employee to either.
While at the #CEBTowerGroup analyst conference (aimed at Financial Services firms, but a good show for any company struggling with cutting edge issues), one presenter pointed out that increasingly employees in the IT issued device category will delay calling IT to report a lost device in the hopes that they’ll find it without it being wiped. Not at all surprising, but not something I had specifically thought of either, and a great point. How much time does a ne’er-do-well have with a device before it is locked out.
With customers, the problem is doubly troubling. Calling your company to inform you that they lost their phone is not exactly going to be the first thing on their mind unless they have stored passwords and credit card info for your website on their phone… And then you’re likely to be one of many.
Another troubling statistic that came from the Tower Group conference was that over 50% of those who found a mobile device attempted to look at private information on the phone… in fact, nearly as many people snooped around in private information as tried to contact the owner of the phone. That’s scary, and shows some amount of overlap between those two numbers.
So the scenario where a user loses their phone, and that phone is (a) loaded with corporate data, and (b) has stored credentials for access to corporate apps, where the phone is then used by someone of ill intent to access corporate info is inevitable. More prevalent and thus more inevitable is customers losing a phone with credentials stored on it. You can avoid some of the customer problem by not caching credentials in your app, but that doesn’t stop the customer from keeping the info on the phone so they don’t have to remember it, or from using some other on-phone mechanism to “cache” them. And history says they will.
Does your perimeter know which I’m on?
It is the job of corporate IT to protect against these concerns, but today we have little enough in the way of tools to implement protection from this kind of problem. Here’s what we need, though I understand that this is not an overnight solution set.
- Today, mobile devices do not reliably offer brand/model information on opening a connection. They’ll need to. More to the point, they’ll need to offer some kind of unique identifier to go with it. People who join a phone plan and get four Galaxy SIIIs for their family will need to be able to tell them apart – or more importantly, sites they notify that the phone is lost will need to tell them apart.
- IT needs a way to block devices that are reported as lost or stolen. Wiping them is great if the company supplied the device, but blocking them from access to corporate systems is the best that can be done in a customer or BYOD scenario.
- Customers and employees need an easy way to report a lost or stolen phone and an easy way to mark it as found. The IT response to these would be “lock out” and “reactivate” respectively. This method needs to be secure and definitively identify the customer as the person attempting to use it.
The first point is the sticky one. As I’ll explain below, we have the answers for #2 and #3 today, but #1 is more difficult. It can be answered within custom-built apps, but that doesn’t help the 300,000 apps out there already for mobile devices, and it’s not generic, meaning you’ll have to implement it on both sides yourself.
As usual, I focus on F5 products, but no doubt you could find similar ways to implement this technology. The good bit about F5 gear is we’ve done the heavy lifting for you .
The other two points we have in one form or another today. F5’s Access Policy Manager (APM) can say “if user X logs in from a mobile device, redirect them to the mobile site.” it’s easy enough to have a rule that says “if user X logs in from a mobile device and their devices is reported as stolen, redirect them to a lockout page, away from corporate systems” utilizing APM’s functionality. The same is true for customers and users attempting to access the VPN. This is important even in an environment where IT supplies devices because employees are more likely to invoke that type of functionality than have their device wiped clean. Depending upon the employee, that may be fine – some don’t carry corporate info around on their devices, just use them for remote access. The catch to this step is, of course, that until step #1 is implemented, the user would be locked out from all mobile devices. That will be fine for some people, but many – like myself – have multiple “mobile devices”. I have a Playbook, a GalaxyTab, and an iPhone, not to mention my access to a Blackberry phone and an Impression tablet. If I lose my IT-supplied iPhone, or my son loses his Impression after I’ve used it to log into work, should it lock out my GalaxyTab too?
Point number two is easy to implement, since “stolen” could be an AD or LDAP field that is then accessible to APM integration. IT would simply need to implement a web interface to report lost or stolen devices.
This solution is most applicable to financial sites, but major shopping sites like Amazon suffer the same level of trust issues, and no matter how small the business, the employee side of this equation applies to you. The reason I say it’s more important for financial institutions is because today the solution to “I lost my phone” would have to be “put a hold on their account”. If you’ve ever been through a hold on your account, it’s painful, and honestly, if an hour later you find your phone at Starbucks where someone turned it in, you’re going to suffer a lot of unnecessary discomfort in the banking scenario.
So today, products like our APM can stop users from logging on from a mobile device once a device is reported as stolen, you could put device identifying information into your app if you are developing it to make this control more granular, and turning on and off could be simple – as long as a way can be secured to make certain it actually is the user in question blocking and unblocking mobile access.
So think about it. This threat is more one of opportunity than what we usually protect against, but the reputation – or even the competitive health – of your business could be at stake, a simple way for users to control access is worth pondering.
Related Articles and Blogs:
FBI Offers Smartphone-Ready 'Most Wanted' List
Duo Security Advances Two-Factor Authentication
Google Acquires Quickoffice Mobile Apps
Researchers Find Ways to Bypass Google's Android Malware Scanner
What Does Mobile Mean, Anyway?
Mobile Apps. New Game, New (and Old) Rules
Mobile Device Support for VMware View
F5 Enables Mobile Device Management Security On-Demand
Mobile User Access Anywhere, Dynamic Security Everywhere
Mobile Payment sicherer machen!
Mobile and IPv6: Why Cows Connecting to the Internet Affects You