Re-Think VPN

As per request from the CIO, Help Desk is reaching out to consolidate the feedback/comments from the various support teams who have helped end users with their VPN issues. We will also look at our support ticket volume. Branch offices support teams who have helped users with their VPN issues might not have registered them so it does not mean that in the branches they have had less issues. Device centric SSL VPN once worked very well when everyone was on Windows XP or Windows 7 and when Mac user was still a minority group. After everyone upgraded their PC to Windows 8 or migrated to Mac we began seeing the usability issues unfold.

Device Centric SSL VPN

From a usability perspective, users who are carrying their personal devices (iOS, Android, Mac, Chromebook, so on) just want to use their day to day company apps. They don’t care how to and why their personal device must establish a VPN “network level” connection with the company. Connecting a personal (un-managed) device to the company is a workflow intensive process for most of the users hence not a nice experience. Even if you followed the instructions to get it work this time, it does not necessarily mean it will work the next time, because something in between (e.g. Java updates, IE/Safari security updates) could have changed the system. We have witnessed the compatibility issues of our device centric VPN with the latest OS (Win8.1/Mavericks) and Java. Device centric SSL VPN depends on these device level components to establish a trusted connection but in reality these components are constantly updating every day and the device centric SSL VPN solution just cannot catch up with these changes.

Apps Follow Me

Users only want their company apps, and they want these apps to follow them, onto any device they will use or upgrade to, without the hassle of re-installing / re-confirming that it will work on the new device. Users may carry their iPad for a short trip but they may carry a full fledged PC or Mac for a longer trip. They may even borrow a laptop from their family member whilst their primary laptop is under repair. They want company apps to just follow them. This is called “Work Shifting”. What all this means: We need to engineer a solution which is device independent and offers a consistent experience no matter what device they are using.

Security Perimeter

The virtue of device centric SSL VPN is relevant only if we want to securely establish an SSL VPN tunnel between the device (right at its OS layer) and the company’s internal network. This is a great deal if we want the device to be “wrapped” inside the company governance domain and essentially by doing so extend the company’s security perimeter into that device and enforce policy control such as Internet proxy, group policies, security patches and push notifications. We are doing that exactly for company liable laptops which we trust and give the highest access level – that laptop is essentially part of the company network. We trust this laptop because we can control it with a set of defined policies which users cannot tamper with.

Application Portal

Any devices other than company laptop should be considered “untrusted” computer and should only be given access to an enterprise application portal or App Center (whatever we like it called). We no longer need the SSL layer established at the device’s OS level (which is cumbersome as we know it). We just need the AES265/HTTPS transport encryption when the device connects to the VPN gateway (just like a normal secure web browser session). Applications could be Outlook, Excel, Word, or even a VDI session streamed to the device via the App Center.

VPN is not MDM

One other concern we have seen: Device centric SSL VPN cannot recognize an Android or iOS device. It treats them as MacOS. I am not blaming it for that because device centric SSL VPN in its own rights is not an MDM platform. If the user has applied for the MacUser group and now connects his Android he will get to the access level equivalent to a Mac user (whatever that is). It surely creates a security exposure to certain extent if you have an uncontrolled Android device connected at such level.

Conclusion

Tactically we can stay at using device centric SSL VPN and continue to accept the risk of allowing a vast variety of uncontrolled devices to establish a network tunnel with the company to perform activities like RDP, file access, Intranet browsing, without being checked for compliance as long as the VPN gateway does not perform the MDM function to detect if the device is rooted or jail-broken. Strategically we need to re-think the design of our remote access platform so that we can provide the true BYOD convenience and the seamless “My Apps Follow Me” or “My Desktop Follows Me” experience without compromising security or compliance.