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.