Guidelines for Vendors

Guidelines for Providing Vendor Access to UTHSC-H Information Resources

Automated information and information resources owned or managed by The University of Texas Health Science Center at Houston (UTHSC-H) are strategic and vital resources belonging to the people of Texas. These resources are entrusted to UTHSC-H to accomplish its mission of providing effective patient care, research, education and community service. Regardless of the funding source, the network and information resources are owned by UTHSC-H and are governed by university rules, which arise from local, state and federal regulations.

In order to maintain the protection of these resources, any individual or entity who demonstrates a business need to access UTHSC-H systems must comply with the policy set forth in this document.

Requests for Vendor Access

Application stewards must send a digitally signed request form to vpn@uth.tmc.edu at least two weeks before the vendor requires access. The VPN team will, in turn, generate a HEAT ticket from which the VPN team will respond. The VPN team cannot guarantee more than a two-week turnaround time. Out-of-band requests will be handled on a case-by-case basis.

The VPN administrator at UT-Houston (VPN admin) will proceed with subsequent steps as soon as the request form from the steward is received.

Steward/Sponsor Responsibilities

The steward/sponsor requesting VPN access has several responsibilities that must be fulfilled throughout the lifetime of the tunnel.

1.) Complete the VPN Request form.

2.) In coordination with the VPN admin, specify the access ports needed by the vendor in the Firewall Database.

3.) In addition to the initial request, the steward must also assist the vendor with the initial VPN setup for client connections. This includes helping them obtain and install the software, assisting them with the initial configuration of the software, and helping them troubleshoot the initial connection (please see section on client VPN tunnels below). In addition, the steward is also responsible for providing end-user support for client VPNs. If the steward has not used the UTH employee VPN, she is urged to familiarize herself with this technology to assist with this important responsibility.

4.)Lastly, the Steward/Sponsor must notify the VPN Team if the VPN tunnel is no longer required.

Determining Technical Requirements

After the request form from the steward is received, VPN admin shall contact the vendor to determine additional needs. For example, the vendor can explain whether or not the site requires simultaneous access to the protected UT-H resource and a resource on the remote LAN. If this functionality is required, the vendor will require either a split-tunneling exception or a LAN-to-LAN tunnel.

Based on the information received, the VPN admin shall determine whether a LAN-to-LAN or client-to-gateway tunnel is more appropriate for the vendor's needs, and whether or not a split-tunneling exception is required. Once an access method is agreed upon, no backup connections will be permitted unless such methods are explicitly discussed and agreed upon by both parties.

For security purposes, UTH enforces the following security requirements:

1. A minimum of 3des encryption must be used.
2. Diffie-Hellman group must be group 2.
3. Re-key times should be no longer than 24 hours for phase 1, and 8 hours for phase 2.
4. Any keys and/or passwords should be at least 8 characters long, and include letters PLUS either numbers or other miscellaneous characters.

All other parameters for LAN-to-LAN tunnels are negotiable, and should be agreed upon with the remote administrator.

Specific Guidelines for Client-to-Gateway Tunnel

In a client-to-gateway tunnel, the VPN admin shall complete all configuration requirements on the VPN concentrator, and restrict the vendor to only the IP addresses and ports required. The client connections will require a second username/password authentication so that a specific IP address may be applied to the connection. The number of simultaneous connections for each user will be limited to one; if additional users need simultaneous access, additional user accounts will be created.

The VPN admin will create a group name, temporary group password, and temporary user password for the tunnel. She will then forward the information to the application steward securely (encrypted e-mail or phone; latter method requires subsequent destruction of the record). The steward will contact the vendor by phone to assist with software installation and initial connection testing, using the VPN website as a guide if necessary. After this step is completed, the steward should notify the VPN admin. The VPN admin will then phone the vendor to set the final password, apply filters, and perform final testing.

Finally, the VPN admin may need to contact the security or infrastructure engineer at the vendor site to offer advice about the ports and/or protocols that need to be opened to allow the connection. These ports/protocols vary slightly depending on the setup of the remote LAN and mode of transparent tunneling, if applicable.

Specific Guidelines for LAN-to-LAN Tunnels

If a LAN-to-LAN tunnel is desirable, the VPN admin will contact the security or infrastructure engineer at the vendor site to discuss the feasibility of establishing such a tunnel. If the remote site has an IPSec-enabled device, and parameters can be agreed upon, the tunnel configuration on both sides can proceed.

If the administrators decide on a shared secret as the authentication method, the key will be protected and changed by the same rules defined above for password protection. “Interesting traffic” should be restricted to only those IP addresses required, and a filter will be applied on the concentrator to restrict the traffic to only those ports required.

A LAN-to-LAN solution requires that the traffic from the remote LAN can be routed internally to the protected resource. This routing will be achieved by patting the entire network on the tunnel default gateway whenever possible.

Protection for Pre-shared Keys, Tunnel Passwords, and System Passwords

It is illegal to share these keys and passwords with anyone. Pre-shared keys for LAN-to-LAN VPNs must not be known by anyone except for individuals who manage the remote site’s VPN device. For client VPN tunnels, the group password is used for all connections at a given site, but individual VPN user accounts must never be shared with anyone. Should a business need arise for additional user access, the VPN administrator at UTHSC-H should be contacted to add another user account. Finally, if the vendor chooses to maintain written documentation of VPN information, all passwords and pre-shared keys must be stored in an encrypted file, with access limited to the individual who requires access to this information. This policy also applies to any passwords the vendor may use to access systems on the UTHSC-H network.

Security Breaches

Each party (UTH and the institution that requires access to our systems) will notify the other immediately upon discover of actual or suspected unauthorized access to or misuse of UTHSC information resources. Specific contacts will be provided during the initial agreements, and an updated list of the UTHSC-H IT security team can be found at the following URL: http://its.uth.tmc.edu

Technical Support

Support for both client VPNs and direct modem access is available via the steward of the resource being accessed, not the IT security department. Support for LAN-to-LAN VPNs may be requested directly from the UTHSC-H VPN administrator, but must be requested by the remote VPN administrator, not a user of the VPN tunnel. Support for password management on client VPNs must be made by the vendor’s primary business contact.