The VPN Server is a Cisco 3030, capable of handling 1500 concurrent users.
The VPN Server is capable of supporting both IPSec and the PPTP transport protocol. While the PPTP protocol has known security weaknesses, it is supported on a wider variety of legacy client platforms than is IPSec. In particular, PPTP is supported on MacOS9 and earlier, while IPSec is not.
The VPN Server is capable of supporting split tunnels. Split tunnelling permits a VPN client system to maintain its connection to its original network while the IPSec tunnel to the VPN server is up. This is often a useful feature for the user of the VPN client system, but it carries obvious security risks.
The VPN Server is capable of authenticating users by passwords, by possession of a valid X.509 certificate, or both. However, MUSC currently lacks the PKI infrastructure needed to issue and revoke X.509 certificates.
The VPN Server supports access control lists. An ACL can be set for any given host and service (port) target. A user who belongs to a group which is listed in an ACL is authorized to access the ACL's target. Using ACL's and groups, the administrators of the VPN Server can control which targets on the Internal Network can be reached by each VPN user.
The VPN service will have two functions. The first will be to permit MUSC students, faculty and staff to access any IP-accessible resource on MUSC's internal network from remote Internet locations, typically their residences. The second will be to permit the support staffs of vendors of IT services to access specific IP-accessible systems on MUSC's network, if they are authorized, from remote Internet locations, typically their places of business.
We have assumed that the VPN service will support two very different classes or types of users. We will use the term Class A to refer to those members of the MUSC community who are authorized to see any resource on the Internal Network. We will use the term Class B to refer to IT vendor support staff, who are authorized to see only those specific systems which they support on the the MUSC internal network. It makes sense to manage these two classes of users, in terms of access controls, as two distinct user populations.
Because Class A users need access to any resource on the internal network, the only logical place to route traffic from the VPN Server's internal interface is directly onto the Internal Network. This implies that the VPN Server, whose outer interface will be on the Perimeter Network, will pass traffic between the Perimeter Network and the Internal Network, without traversing the packet filter which separates those two networks. It should be obvious that this will increase MUSC's overall security risks. It should also be obvious that, in order to mitigate these risks, (a) provisions will need to be made to monitor the network traffic flow on the VPN Server's internal interface for auditing and intrusion detection purposes, and (b) the VPN client systems used by Class A users will need to be governed by specific security policies.
Both Class A and Class B users will authenticate to the VPN server using MNA userid and password. Class B users will need sponsored MNA accounts. If (when) MUSC develops the necessary PKI infrastructure, then we should move to stronger two-factor authentication (i.e. require both a valid MNA userid and password, and a valid X.509 certificate issued specifically for VPN authentication).
Any MUSC student, faculty or staff may request Class A VPN access. For non-sponsored MNA account holders, no additional authorization or justification is needed, but the requestor must agree to specific security requirements applying to Class A users (see below). All Class A users will be assigned to an access control group which grants unrestricted visibility to all resources on the Internal Network. Each Class B user will be assigned to an access control group which grants visibility only to the specific system(s) he has been authorized to access.
While a sponsored MNA account holder may request a Class B account in order to access a specific target systems on MUSC's Internal Network, the administrator of the target system must first authorize the specific Class B account holder to access the target system through the VPN, before the requested access will be granted.
Class A users will be required to install and securely maintain a firewall to protect the client system(s) they use to access the VPN Server. They will also be required to maintain current virus protection software. The VPN client software will be distributed with split tunnelling disabled, and the user will be prohibited from circumventing this security feature.
Class B will be subject to the same client security requirements as Class A users. Class B users will generally be subject to additional security requirements, as described in any applicable policies (e.g. Partner Connection Policy, Chain of Trust Agreements, etc.).
The VPN Server will be configured to support IPSec only.
Provisions for external monitoring and auditing of traffic flows from the VPN Server's internal interface must be made. This will require the purchase and installation of some new hardware.
Online request forms to process user requests for Class A and Class B access must be developed and implemented.
An online request form, to be used by any MUSC system administrator who needs to request that access to one or more servers on the Internal Network, by one or more Class B user accounts, be authorized, will need to be developed and implemented.
An online mechanism for distribution of VPN client software will need to be developed and implemented.
Specific recommendations/requirements for VPN client firewall products and VPN client virus protection will need to be published. The extent to which MUSC will provide support (if any) for client setup and configuration will need to be determined.
MUSC will need to audit VPN client systems for compliance with security requirements. CCIT's Network Systems Team will be responsible for conducting these audits. The audit specifications will need to be developed.