Wednesday, May 21, 2008

Remote Access for Vendors

BIDMC works with many external technology vendors which need access to our internal systems. I've been asked how we provide such access in a secure and HIPAA compliant fashion.

We provide vendors two methods of remote access for the purposes of supporting their equipment on our networks. The first is the traditional Lan to Lan tunnel model. If they choose the Lan-to-Lan model we required that they define the TCP/UDP ports required. We then restrict the tunnel down to those ports and to the specific IP address(s) required. This tunnel is terminated at a location on the network that then permits us to subject all of the traffic to inspection by our security devices/tools.

The second option we provide is through our Juniper SSLVPN infrastructure. This is a more flexible and resilient solution and provides more protection from infection by the vendors network. It also provides a much more robust audit log trail of usage. If the vendor does not require any access other then RDP, Telnet, or SSH the SSLVPN provides access as a proxy service from a large list of Java compliant systems. We restrict the usage of the vendor account to the vendor's public address space. This is done to provide a degree of assurance that an employee who has left the vendor, but has an account on our system will no not be able to gain access. The assumption here is that they would no longer have access to the vendors corporate infrastructure so would not be able to get to us either. We use an online provisioning system for these accounts that we wrote in-house - a simple web page with a SQL database backend. As part of the form there must be a BIDMC employee who has oversight of the vendor. Every night at midnight the logs are scrubbed and cross indexed to the submitted forms. The access performed by a vendor account is bundled up and mailed off to the BIDMC employee listed on the request form. This is done to ensure the there is an awareness of vendor activity. There is also an audit job run to make sure that the employee listed in the forms is still employed at BIDMC and if not we chase down who the replacement is.

If the vendor requires access to the machine through a mechanism other then RDP, Telnet or SSH then there are some additional options the SSLVPN provides. One is a port forwarding service and the other is a Java based equivalent to a IPsec VPN client granting them full layer two access into the network. We have done a couple of port forwarding setups but have not yet needed to provide a vendor with the layer 2 capabilities.

We also require all systems with a Lan-to-Lan tunnel or have a vendor remote access to them to pass an initial vulnerability scan. They are then subject to random scans from that time forward until the remote access is no longer in place.

We do not permit any vendor to place a router , firewall or any other networking equipment on the network. By extension they are unable and not permitted to terminate or originate any VPN connections that we do not control.

We have run into some problems with vendors related to this policy. We often hear the same statements from vendors - we do this everywhere else and should be granted an exception. I simply state our policy does not permit it.

Thus far these technologies and policies have worked very well for us. Security is always a journey and we'll continue to be vigilant about evolving technologies and security risks.


Unknown said...

Speaking as a vendor who provides support to many enterprises, this is a good primer for others to follow. We use, and I often recommend, Enexity Securelink ( to accomplish the same well managed access but with better manageability, control and auditing. This might even be the Cool Technology of the week ;-)

Unknown said...

As an IT employee of a hospital, I have to question the workload behind attempting to scan, audit, and monitor a vendor's traffic. If the vendor's equipment communicates across your network to its home office using encryption, such as SSL, across one of your open ports, like SSH (22), how would you detect if the encrypted traffic was harmful to either their equipment or your network? In your post you stated you allow SSH access thus you must allow encrypted traffic on your network, right? How would SSL encrypted traffic traveling across your network to the vendor's equipment differ from SSL VPN traffic traveling directly to the vendor's equipment?

Unknown said...

My organization faces security concerns in cases where we are required to open inbound TCP ports to allow remote access. So, I got down to do a bit of research on this, and discovered that there are remote access products such as RHUB TurboMeeting that don’t necessitate changes in firewall settings for Remote Access. We just need to switch on the computer and get the Internet on, that’s it.

Daniel Lord said...

Thanks for the post John, it's definitely a good primer. Security of data and HIPAA compliance has got to be the number one concern of an IT employee working in a healthcare environment. Luckily for us so many remote access software companies have built it into their systems so that what would be a nightmare is relatively simple