To improve the security of our network, we decided to close port 3389 and no longer publish a Windows terminal server to the internet. In order to continue to support remote access to our network, we implemented a secure socket layer (SSL) virtual private network (VPN) device that allows users outside of the corporate network to create an secure tunnel into the network. As implemented, end users were required to use a particular operating system, and to follow relatively simple instructions to install a small program that would initiate the tunnel from the home user’s workstation to the corporate network. Authentication relies on the existing Active Directory accounts so that users didn’t need another login. The appliance also allowed us control over which accounts could have remote access, so we could limit the known trouble accounts, such as guest and administrator, from having access to the protected network.
By corporate policy, remote access was originally designed for clinicians to be able to access patient medical records while the clinician was on call. Over time, end users have been able to use remote access to work in the comfort of their homes, whether on call or not. However, in no case has the corporation required that end users be able to work remotely as a matter of course, except for a few traveling staff that work during the day at a third party facility.
Nonetheless, users had gotten into their heads that working from home was a right, not a privilege. And with that right flows the obligation on the part of IT to support the home user’s network configuration. The change, therefore, by IT to the method of access to the remote network was unwelcome by some and was met with resistance, even if the new method was in fact more secure, recommended by our outside information security consultant, and addressed a major security vulnerability within our network.
There were really two important lessons from this experience. First, proactive communication and involvement of the user community in implementing changes to remote access is an important element to the implementation plan. I suspect some would still have grumbled at the change, but we may have headed off some of the complaints simply by better explaining why the change was being made. Second, remote access had grown organically over time such that a lot of people were using it on a wide variety of home computers and home networks. Many of the staff were not particularly competent at using their home firewalls, routers, or other network devices if the users needed to make changes to these devices to access the corporate network. We also underestimated how diverse and how much configuration could be required in order for the SSL VPN device to be able to connect to our network and establish the tunnel for secure communications.
We also discovered that the device was not particularly compatible with OSX (there was a guest kiosk function that would work within OSX, but the screen resolution and performance was poor and effectively unusable for most staff that had to be in for longer periods of time). We had not realized at the time how many staff were actually using Macs at home, so this also caught us off guard. Of course, Parallels and VMWare both offer virtualized Windows XP desktops (with which the appliance was compatible), but users still complained that they had to implement this in order to access the network.
Inherently, there is tension between user access and security, and it is up to IT management to determine how much pain to inflict upon the users to protect network assets. Not everyone will be happy with the balance. In this case, I still think we made the right call, but we didn’t implement according to a complete plan. Next time will no doubt be better.
Faith At Law LLC 