Wireless networking technologies can allow MUSC staff to access networked information from any portable PC or handheld device, without the restrictions on location imposed by wired connections. Wireless mobility can support diverse applications, ranging from more efficient bedside patient care, to new forms of teaching and learning in the classroom.
At the same time, the broadcast nature of wireless (radio) communications raises security concerns, and carries the potential for interference between neighboring devices, if wireless devices are installed and used naively.
Wireless networking products are widely available and easy for an untrained user to install incorrectly. Departments and individual staff have purchased these products and have installed them on the MUSC network without any authorization or supervision.
In a recent informal audit of wireless access points, CCIT discovered 35 unauthorized access points installed on the campus network. Because they were improperly installed, most of these access points allow anyone within signal range to detect the access point, gain access to our wired network without authorization, and eavesdrop on any communications conducted over the wireless network.
Every Wireless Access Point (WAP) should be wired into a dedicated "Wireless VLAN" whose primary purpose is to prevent access to the wired portion of the MUSC network by unauthenticated mobile users.
Because the "Wireless VLAN" on the core campus network cannot be routed onto remote LANs, MUSC's WAN sites require special consideration.
Biomedical Engineering has done testing and has concluded that 802.11 wireless networking devices do not present a risk of interference with medical devices which use the same FCC unlicensed 2.4GHz frequency band. It appears that on our campus, the only significant risk of interference from an 802.11 device, is to other 802.11 devices.
If WAPs are infrastructure, then they should be centrally managed, and centrally funded. This would allow standardization on a single brand of WAP, with obvious efficiencies. Unless unlimited capital funding and network management personnel were assumed (haha), a mechanism for prioritizing implementation and other services would be needed. Policies for non-infrastructure WAPs would also be needed; they could be banned outright, or somehow accommodated.
If WAPs are not infrastructure, then decisions must be made regarding the degree of standardization and central management that would be needed. Assuming that a non-zero degree of central management is deemed necessary (at minimum, monitoring for compliance with security policies must be performed centrally), a method for funding these centralized support services must be found.
Because wireless communications are broadcast, encryption of some or all wireless traffic must be performed to protect the confidentiality and integrity of any sensitive information. The encryption can be performed at the network layer (e.g. WEP or dynamic WEP), at the IP layer (e.g. IPSEC VPN), or at the transport layer or higher using "end-to-end" protocols (e.g. SSL).
The Dynamic WEP protocol is one approach to protecting the confidentiality and integrity of wireless traffic. Although fundamental flaws in the basic WEP protocol make it unsuitable for protecting the confidentiality of sensitive information, the dynamic WEP protocol, which uses rotating (rapidly changing) encryption keys, appears to eliminate this problem.
Dynamic WEP Pros:
Dynamic WEP Cons:
VPN technology can be used to encrypt traffic at the IP layer. Some or all wireless devices can be equipped with VPN client software, and then connect to network resources through a VPN server. All traffic between the VPN clients and the VPN server is encrypted inside an IPSEC tunnel.
VPN Pros:
VPN Cons:
"End-to-end" encryption protocols like SSL can be used to encrypt wireless traffic at the transport layer or higher.
End-to-End Pros:
End-to-End Cons:
As a policy issue, we think it's safe to claim that all wireless users of MUSC's network must be authenticated. There are at least three potential approaches: 802.1x, VPN, or homegrown.
The IEEE 802.1x standard is one option. Implementations of this standard are still effectively limited to commercial clients ($20-40 ea) although open source implementations are expected to become viable alternatives, and it is likely that 802.1x functionality will be incorporated into client operating systems. The advantage of 802.1x is that it can provide a simple and open standards-based mechanism for authenticating all users on a wireless (or wired) network. Its disadvantage is that (at present) it requires special software to be installed on every wireless client. At a minimum, we certainly should not make any architectural decisions which would prevent us from adopting 802.1x in the future. And remember, dynamic WEP encryption requires 802.1x authentication.
If all wireless users are required to run VPN client software, then the VPN server can be used to authenticate all wireless users. The main drawback of this approach would be the inability of some mobile clients to run VPN client software, i.e. IPSEC clients aren't available for all mobile devices, e.g. handhelds. Another drawback is that VPN authentication cannot protect the network against all kinds of attacks which can be launched from hostile wireless clients, because authentication is not required before the connection to the WAP is effected.
Nathan Zorn's Authentication Gateway is a homegrown approach to authentication currently being used at MUSC. Its principal advantage is its universality, i.e. it can support a very wide range of mobile clients. One disadvantage is that is does not implement the 802.1x standard, so it precludes the use of dynamic WEP for network-layer encryption. Another disadvantage is scalability; because an Authentication Gateway must be present on each LAN where WAPs connect, each WAN site with one or more WAPs requires its own dedicated Authentication Gateway. MUSC currently supports 28 WAN sites, each of which could potentially require its own Authentication Gateway. Another drawback is that, for obscure but apparently fundamental technical reasons, the Authentication Gateway approach precludes the use of IPSEC VPN tunnels by any mobile clients. Finally, as with the VPN approach, authentication takes place after the connection to the access point is made by the (potentially hostile) wireless client, which leaves open the potential for attacks against other, legitimate wireless clients.
MUSC has a goal of enabling wireless/mobile access to the campus network which is as similar as possible to wired from the end-user's perspective, and funding is available to meet this goal.
Infrastructure: WAPs should be defined as network infrastructure. NST should purchase (or at least specify), install, and manage all WAPs. All aspects of NST's services related to wireless networking will need to be centrally funded. There could be no such thing as a non-infrastructure WAP; NST would monitor for rogue WAPs, and ( disconnect | confiscate | destroy ) any rogue WAPs found.
Encryption: We should require dynamic 128-bit WEP between all WAPs and all mobile clients. This is the simplest way to protect sensitive traffic in a way that is transparent to the end-user; it is far less "intrusive" to the end-user than a full-blown VPN implementation. It also avoids the need to restrict access to legacy applications which cannot do end-to-end encryption.
Authentication: Dynamic WEP encryption would require us to use 802.1x authentication.
This approach yields a potential big win (making the wireless network a transparent extension of the wired network, in terms of end-user experience and security policy), at the cost of requiring Cisco-only WAPs (at least for now) and requiring commercial (for now) 802.1x client software on all mobile clients.
Pros:
Cons:
MUSC does not have a goal of enabling wireless/mobile access to the campus network. Each instance of wireless access provisioning will require a local funding sponsor, for both capital expenses and on-going NST services. MUSC will require end-to-end encryption of any confidential data, and will enforce this policy to the extent possible through packet filtering on wireless gateways (limiting connections to only the "known secure" ports on campus servers).
Infrastructure:WAPs will not be defined as network infrastructure. NST will advise departments on the purchase, installation, and management of their own WAPs. Departments may elect to contract with NST for support. NST will set standards for secure configuration of WAPs and will monitor for compliance; at least this aspect of NST operations must be centrally funded.
Encryption: None, under the assumption that any confidential data is being protected by end-to-end protocols.
Authentication: We should continue to use the Authentication Gateway.
Except for acknowledging that funding for enforcement of security policy must be provided, this approach is basically the status quo. Users of the wireless network will be treated like users of any remote, untrusted network, i.e. accessibility of the campus network from a mobile device will be similar to that from a user's home DSL or cable account.
Pros:
Cons:
MUSC does not have a goal of enabling wireless/mobile access to the campus network. Each instance of wireless access provisioning will require a local funding sponsor, for both capital expenses and on-going NST services. Each instance will also require an analysis of data confidentiality requirements, to determine whether and where encrytion is necessary and whether it can be effected where needed with end-to-end protocols.
Infrastructure: WAPs will not be defined as network infrastructure. NST will advise departments on the purchase, installation, and management of their own WAPs. Departments may elect to contract with NST for support. NST will set standards for secure configuration of WAPs and will monitor for compliance; at least this aspect of NST operations must be centrally funded.
Encryption: We could avoid the requirement for dynamic WEP on those specific WAPs where network-layer encryption is not needed to meet MUSC's security requirements. However, we should require dynamic 128-bit WEP between some WAPs and their mobile clients, specifically in those instances where sensitive information must be delivered to mobile clients by legacy applications which cannot be supported by end-to-end protocols.
Authentication: We should continue to use the Authentication Gateway to support WAPs where network-layer encryption is not needed, while migrating to 802.1x authentication for WAPs where dynamic WEP is needed.
By combining the status quo with a fundamentally different approach, this approach would create a host of problems. End-users would be faced with a patchwork of inconsistent access points and security policies, and MUSC would be burdened with the administration of a nightmarishly complex network. No further discussion of this alternative is needed.