If you work in IT, you’ve probably been here already. Someone important is proudly clutching a shiny new toy and asking you that vague, difficult question: “Can I use this?”.
So how do you respond?
The first rule is simple: don’t say no! Refusing a C-level executive is rarely a career-enhancing move and the chances are it won’t make a difference to your organisation’s security.
If you fail to respond to user demand there’s a risk that enterprising users will find insecure workarounds. Far better to accept some well-considered risk than find out vital data has escaped via the CEO’s webmail account (which, of course, works very well from his iPad).
So, you’ve replied with a cautious “Yes but.”, what now?
Unfortunately at first glance your options aren’t very palatable – the traditional centralised approach towards configuration management, software, patching and AV is often not possible, or even relevant, on these platforms.
So where do you start? Refreshingly, it’s a good opportunity to take a step back and gather some basic requirements. The simple question, “What exactly do you want to do?” may suddenly make the issue easier to deal with.
Chances are the base requirements are relatively simple – nobody is planning to ditch their laptop quite yet so your users probably don’t need, or want, access to the scary stuff. In fact, the answer will probably start with two things: email and web browsing.
Here are 5 practical steps to get you started:
1. Segregate
If there’s no reason for a user’s personal iPad to have direct, unrestricted connectivity to your crucial servers, don’t provide it. Create a firewalled wireless network and provide access as needed. If you’re worried about complex firewall rules, don’t be – tablets tend to only speak a few core protocols (HTTP, DNS) and your firewall rule-set will reflect this.
2. Policies
Keep them clear and simple and back them up with examples – this way your users will understand why they are necessary:
No jailbreaking. Software should only be installed from the official app store, marketplace, etc.
Screen-lock password. Should kick in automatically after around 5 minutes of inactivity.
Password length. This can be a contentious issue so it’s wise to be pragmatic here. Require users to type in 15 characters and they’ll make their password 111111111111111. They’ll also get around complexity requirements. Computers aren’t good at detecting randomness, humans are far better and they’ll figure out how to game any complexity enforcing algorithm.
Sounds scary? A little, but countermeasures must be proportional to the threat. To attack a phone-lock password you generally need physical access to the device. Compare this to your network or email password – anyone with an internet connection can start guessing passwords to your VPN gateway or mail server so you need to defend these passwords against the entire population of the internet which is a much harder task.
‘At least six characters’ is probably a good start to deter the casual attacker but it’s sensible to always assume a lost phone has been compromised regardless of the password protecting it (more on this below). Whatever you choose, make sure you follow the same rules yourself – don’t expect your users to accept something you don’t!
For tips on how to choose a strong password, take a look at this video Graham made:
(Enjoy this video? You can check out more on the SophosLabs YouTube channel and subscribe if you like)
3. Evaluate
Different platforms have different risk profiles. iPhones and iPads are encrypted by default but are known to have been broken into. Androids aren’t yet (it is coming soon but you probably won’t want to stake your reputation on it). Either way, remote wipe capability is a good precaution but make sure your users know that you will use this option if the phone is lost – they’d better keep backups!
It’s likely a user’s network password will be saved on the device too (to support automatic email retrieval, for instance). Don’t trust the device to store it securely; ensure it is changed if the device gets lost.
Also worth noting if you’re using Exchange Active Sync: iOS currently ignores the “don’t save attachments” policy setting. (For a comprehensive overview of iOS and EAS polices check out some tests the guys at Sysadmin Lab did: don’t assume it all works!)
Android appears to be a larger target for malware than iOS. Google is attempting to address the problem, most recently with the addition of a Marketplace “Bouncer” to scan submitted apps, but you should still consider this when making policy decisions.
For instance, there is known Android malware that intercepts text messages, providing attackers with a method of defeating SMS-based two factor authentication. Worth considering the implications if you use this technology to protect network or application access.
Patching also varies between platforms, manufacturers and software versions. iOS 5 auto-updates but earlier versions require users to do this themselves.
Android relies on the handset manufacturers to handle device patching but unfortunately they don’t appear to be doing a great job of this. This problem, and much more is covered by some great research from Carnegie Mellon University: All Your Droid Are Belong To Us: A Survey of Current Android Attacks.
Remember: the less regularly a phone is patched, the more likely it will get compromised, particularly via a drive-by-download attack. Segregation is a good defence here – if you’re not satisfied your devices are getting updated don’t let them near your critical applications.
You should probably also consider protecting those critical applications with two-factor authentication; even if a compromised phone can’t access passwords and certificates directly, that drive-by-download exploit could be busy stealing it from the phone.
4. Educate
Both your users and the IT service desk will benefit from some clear advice.
The service desk will need some process and procedure to help with provisioning and promptly remote-wiping lost devices. They’re also close to your users so are vital allies when it comes to education and spotting bad behaviour.
Here’s a nice trick: ask your users to search their email for the word “password”. It’s likely at least one website will have emailed them a password reminder in plain text – remind them that an attacker who accesses their phone will very likely try the same. This will help illustrate how important it is to clean up these emails, use different passwords for different websites and have good password-reset questions.
5. Be pragmatic
If there’s one thing to take home this is it. These platforms are hard to manage and you’ll probably need to do some unpleasant things.
This is important, so a final example: no sysadmin wants to allow iTunes on their network, it sucks up system resources and causes havoc when a user accidentally synchronises their mp3s onto the corporate file server.
Unfortunately, without iTunes a user can’t easily backup (or even patch, in anything under iOS 5) their iPhone. Think you don’t care? You do! Knowing you will remote-wipe it, a user who has lost his phone and has no backups has a strong incentive to delay telling you in the hope he finds it down the back of the sofa.
I hope this article provides some simple and practical advice you can act on immediately. A good understanding of the risks combined with basic sensible precautions will always trump a product which promises to solve all your problems.
Man with smartphone, locked smartphone, plaster and smartphone images, courtesy of Shutterstock
Leave a reply
