Sophos Cloud Optix
Early last year I wrote some simple practical advice on handling bring-your-own smartphones in the enterprise.
A year on, demand is still strong. If your efforts to bring personal devices into the network have been successful, you’ve probably been rewarded by a deluge of requests for more!
Most organisations start by offering email on personal devices. Even this is complex and fraught with risk. Have a think about all the juicy stuff in your inbox. What could an attacker do with it?
There’s a good chance they would find your address, date of birth and information that would help a criminal answer what should be secret security questions.
They might even find passwords in plain text, emailed to you by colleagues or insecure websites (on a side note, searching your own inbox for this kind of data is an interesting exercise).
Armed with all this data an enterprising intruder can launch a very convincing social engineering attack.
It’s a small mercy that, notwithstanding a major problem with your mail server, an attacker will still have to start with trying to gain access to a single mailbox.
Subsequent attacks are somewhat dependent on luck because the attacker is continually running the risk of getting caught.
Enabling your mobile workforce may be essential, but exposing customer information to the outside world is a far greater risk. One leaked or hacked password could be all an attacker needs to log on, find the export button and walk off with all that confidential data.
Much of the available technology today focuses on protecting devices, but steps you take to offer anytime, anyplace access to applications can introduce extra problems.
Take a standard in-the-cloud app. It’s simple to allow mobile clients to connect: download an app and login. There is no need to host your own remotely accessible systems with the associated complexity of static IPs, domains, SSL certificates, VPNs etc.
The SaaS delivery model has fulfilled its promise of simplicity but look a little deeper and problems begin to appear.
If anyone can download an app and simply log in, what’s stopping an attacker? Educating users on good password practice is vital, but relying on this alone to ensure the system’s security is very questionable thinking indeed.
If guessing passwords through a mobile app with a touchscreen keyboard seems too tedious to be likely, you’re probably right.
The smart attacker doesn’t need to. Behind the scenes all these applications speak plain-old http.
It’s not hard for a moderately-skilled bad guy to have a poke around the underlying web services that the app speaks to. Once he’s figured out how it processes user logins, writing a little password-guessing script is likely trivial.
We realised the problems with passwords years ago, that’s why we have VPNs that require certificates, smartcards and key-fobs to connect. And in the rush to get new devices it’s easy to forget the basics.
So how do we make life harder for the attacker – without impacting the user? Unfortunately, it’s not easy but here are a few ideas.
Ask the application vendor for help
The easiest way is to see if the application can assist. The larger and more security-conscious vendors may be able to help you implement an additional authentication factor.
These tend to take the form of email verification for unknown devices, an SMS code or a separate app which generates authentication codes.
Although better than nothing, these methods still have problems.
Simply, having different usernames and passwords for different accounts is confusing enough. If you need a special SMS code for one app, email verification for another and a soft token app for a third, you’ve got yourself a lot of help desk tickets.
Of course, if your email isn’t well protected then email verification isn’t much protection either!
Remote terminal technologies
Remote terminal technologies have made some inroads, turning your smartphone into a pane of glass through which you can access corporate applications.
They have the great advantage that they’ll probably work with all your existing apps (as long as they’re not too graphically intensive).
They’re the easiest to secure too. The data always remains on the server so you don’t need to worry too much about data loss for lost/stolen devices. Most solutions support various forms of two-factor authentication. The login method will be the same for all applications so things shouldn’t get too confusing.
Of course there’s a catch: the user experience often suffers. Things are never going to be as slick as a native app with all its fancy notification features and smooth integration with the phone’s camera, address book, etc.
A clunky app is still a clunky app. Making it viewable on a shiny touchscreen device won’t change that, especially if the app has been designed for a mouse, keyboard and large screen.
Still, if you’re willing to make some usability compromises and absolutely must provide remote access to very sensitive applications, this is probably the best choice. Just make sure it’s got good authentication and encryption.
VPNs
VPNs are another option. Assuming your existing corporate VPN has strong authentication then routing all traffic over that has a couple of key advantages.
Firstly, you’ve got a central choke point to perform web scanning, IDS, etc.
Secondly, even if the application is outsourced, connections will be coming from your static corporate IP ranges. Being possibly the very first form of network authentication, limiting access with IP ACLs tends to be supported by just about everyone. They are thus a reliable, if cumbersome, second-factor.
Unfortunately your users might not be so keen. Typically a user will have to remember to fire up the VPN, authenticate to it (possibly with a long password and a key fob code), then authenticate again to access an application. Assuming you’re forcing a reasonably long password, repeatedly typing it on a smartphone will quickly become tedious.
Things get even more unpleasant on an unreliable connection. iPhones particularly don’t seem to do a very good job of keeping VPN connections alive, forcing constant reconnects.
x509 certificates
The final option I’ll cover are x509 certificates. Certificate authentication is a well-established (if often misunderstood) standard which tends to be well supported by most smartphone web browsers and, on the other end, web servers.
You’ve probably already spotted a key limitation: unlike VPNs or remote terminal clients, this technology is not transparent to the application. It must be supported by the client and the server.
This limitation might not be such a showstopper though. Firstly, some mobile apps are really just web apps which rely on the system’s underlying browser. Providing this is the case, then the app will likely support client certificates, even though it doesn’t realise it.
Don’t expect the app vendor to know this though. As mentioned before, x509 client certificate authentication is often misunderstood. Do the testing yourself.
Secondly, you don’t have to configure all your web servers with client certificate authentication directly. There are a couple of very useful technologies to help.
For internal systems, a reverse http proxy on the gateway can be configured to handle the client certificate authentication. This provides a neat way to make explicit applications externally accessible without changing any internal configuration.
Protecting externally-hosted systems is probably best achieved with federated authentication. Technologies such as OAuth and SAML allow you to retain central control of authentication in a distributed architecture.
It’s worth spending the time to understand federated authentication as it’s fast becoming a critical cornerstone of enterprise identity management. Put very simply, it allows you, as an ‘identity provider’ to issue a signed token which says, for example, “I, Sophos, assert that this person is Ross”.
The client submits this token to the service provider, i.e. the web application. The service provider checks that the token was really issued by Sophos (using PKI) and if ross@sophos is authorised to access the application, allows him in.
The trick to ensuring two-factor authentication in a federated environment is to strongly authenticate the user before issuing the token. That is, require a certificate and a password to access the federation service.
Get this all right and you’re pretty close to satisfying everyone.
The user experience is good. As long as the certificate is on the device, they will only need to enter their password once. If properly configured the user will simply need to visit the desired site or launch an app. No need to remember to fire up a VPN first.
It also delivers a consistent experience as users will use the same authentication gateway for all services, whether they’re internal or external.
Consistency can improve security too. If users are used to using the same system to log in they are less likely to be fooled by a phishing page.
Security is good. You aren’t susceptible to anyone on the internet guessing a password. Unfortunately, you may be vulnerable to certificate theft. Device encryption can help, but to really secure things the certificate should be stored in a TPM (Trusted Platform Module), so that even a malicious piece of software on the device can’t steal the private key.
Sounds great, but TPM support is very patchy. Of course, compromising a device and stealing a certificate is still a lot harder than guessing a weak password.
If nothing else…
If you’ve got through all the above then you’ve probably realised that this isn’t easy!
Smartphones do genuinely offer some security improvements. Strong sandboxing, code signing and various other OS-enforced security boundaries make many attacks on these platforms much harder than they are on PCs. This is a great benefit to all of us, but it shifts the focus back onto your services.
Bad guys will go for the weakest link. This isn’t always the client.
Password screen, cat cartoon smartphone, smartphone pattern, security sign and Smartphone images from Shutterstock.
Regarding the issue of security breaches involving email, I assume that everyone who is even minimally conscious of security recognizes and agrees that the potential for mischief is enormous if a bad guy hacks into someone's email account. The article (above) says so. No argument there.
The part that utterly baffles me is why more people don't use secure messaging (encrypted mail). I just don't get it. It's bad enough that private users don't use encryption, but it's utterly incomprehensible to me that companies don't use it. The number of companies with whom I have corresponded who use encryption (count it carefully, now) is…ZERO.
Zero. That includes banks, and many other companies who should know better. The mind stops.
Sure, it would take a massive public awareness campaign to educate people about the use of X.509 certs and how PKCS encryption works, but who is better placed to do that than the companies with whom we conduct business daily? For example, Sophos could use NakedSecurity as a bully pulpit to promote secure messaging.
And yes, I DO understand that PKCS is not a perfect system (for example, users still have to take care to protect their private keys). But surely it would be far better than the current condition, wherein the risks imposed by unencrypted mail are nearly universally accepted as "normal".
Great article and there is an additional issue not mentioned around complexity of these solutions for non-technical people. We implemented remote terminal as a trial for some key users, despite a 14 page document on how to get it set up with all the various home browsers in use and potential problems they could encounter, we had so many work orders on a continuous basis associated with it that the whole project was abandoned.
The challenge for IT is always balancing security and productivity. Different kinds of organizations requires different levels of balance.
Also different organizations have different budgets and IT departments. Some organizations are willing to deal with security intrusions for whatever reason (bottom line, overhead ,etc.). Some are willing to go the extra step.