Wi-Fi Security Threats
Wi-Fi involves communication between radios that use a specific type of radio frequency (RF) technology to send data to each other over the air. In a hospital, Wi-Fi radios in computing devices( tablet computers, communicate with Wi-Fi radios in infrastructure devices such as access points (APs) that are connected to the hospital’s wired network. The radio waves that travel between the devices can reach waiting rooms and other public areas and even “bleed” through the walls of the hospital to parking lots and other nearby areas. Those RF signals can be viewed by any nearby computing device that is equipped with a commonly available software application called a Wi-Fi sniffer, which makes the contents of Wi-Fi packets viewable. Without proper Wi-Fi security in place, a hacker can use intercepted Wi-Fi packets to do one or more of the following:

1. Gain access to the Wi-Fi network.
2. View sensitive information that is transmitted over the air.
3. Trick users into communicating with the hacker instead of the network.

To thwart a hacker, a hospital needs to use strong Wi-Fi security.  But what type of security is strong enough?

HIPAA and Wi-Fi Security
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) required the U.S. Department of Health and Human Services Secretary to develop regulations protecting the privacy and security of certain health information. HHS published two documents, the HIPAA Privacy Rule and the HIPAA Security Rule, the latter of which is found in the Code of Federal Regulations (CFR) Title 45, Part 164, Subpart C, entitled “Security Standards for the Protection of Electronic Protected Health Information”. For Wi-Fi client devices and networks, the key part of Subpart C is section 164.312, which lists standards for access control, audit controls, integrity, authentication, and transmission security.

To satisfy the requirements of HIPAA, a hospital Wi-Fi system needs:

• Strong, mutual authentication between every authorized client device and a hospital network where electronic protected health information (ePHI) is housed to ensure that only trusted Wi-Fi clients can gain network access and that trusted Wi-Fi clients are not tricked into connecting to an untrusted network
• Strong encryption of ePHI that is transmitted between a Wi-Fi client and the hospital network

The Enterprise version of Wi-Fi Protected Access® 2, or WPA2®, satisfies the requirements of HIPAA. WPA2-Enterprise combines:

• IEEE 802.1X for strong, mutual authentication of the Wi-Fi client device and the network
• AES-CCMP for strong encryption of all transmitted data

The combination of 802.1X and AES-CCMP addresses the three security threats discussed earlier. To ensure HIPAA-compliance, a hospital should follow these best practices:

• Ensure that a Wi-Fi client device can gain access to a hospital network only using WPA2-Enterprise with a strong EAP type.
• Configure every trusted Wi-Fi client device to connect only to trusted APs.
• Do not store EAP authentication credentials on client devices.

For more information, watch a replay of the Summit Wi-Fi security webinar or read the Summit white paper on the same topic.

Hospitals and other healthcare providers rely on medical devices for patient care and patient safety. When a medical device is designed to connect to a wireless LAN, the Wi-Fi® radio in that device must provide a constant network connection. If the connection is not reliable, then the device will be seen as unreliable.

IEEE and industry standards define how a Wi-Fi radio interoperates with a wireless LAN infrastructure, and the Wi-Fi CERTIFIED™ seal ensures interoperability. For many organizations that rely on medical devices, however, Wi-Fi CERTIFIED is not enough. These organizations need assurance that their medical devices have been tested to interoperate with a Cisco wireless LAN infrastructure and support Cisco wireless LAN innovations for enhanced security, mobility, quality of service, and network management. The Cisco Compatible seal gives organizations the assurance that they seek.

A client device earns the Cisco Compatible seal through a program called Cisco Compatible Extensions, or CCX. Like the Wi-Fi certification program, CCX:

• Includes a specification that defines a set of features that must be implemented in the hardware and software for a Wi-Fi radio or a device that uses a Wi-Fi radio.
• Requires compliance testing conducted by an independent lab that is approved by the organization that manages the program.
• Requires that a submitted radio or device pass all tests to be approved.

The CCX specification is a superset of that used for Wi-Fi certification. In fact, a device cannot be certified for CCX unless it, or the Wi-Fi radio inside it, is Wi-Fi CERTIFIED.

Within the CCX program, a medical device is classified as an application-specific device, or ASD. The CCX specification for an ASD is a subset of the specification for general-purpose devices such as laptops.

CCX Lite

As CCX Product Manager Mark Dahm announced in our CCX webinar, a new version of the CCX program called CCX Lite will make its debut this year. Designed for ASDs, CCX Lite offers a more modular method of testing and certifying the features that are most relevant to an ASD.

Initially, CCX Lite will initially consist of four specifications for four sets of features: Foundation, Voice, Location, and Management. Only Foundation will be required as the minimum test and certification level to achieve the Cisco Compatible seal. Voice, Location, and Management will be optional service modules to address features of interest to certain ASDs as well as new and evolving Wi-Fi devices. Cisco plans to add more service modules as well as more features in existing service modules to enable pre-standard feature innovation in ASDs and other devices.

According to the Cisco Web site, there will be an unspecified period of time in which Cisco will support both CCX Lite and CCX Classic for ASDs. Eventually, Cisco will phase out CCX Classic for ASDs.

CCX Lite breathes new life into CCX and ensures that CCX will be relevant to medical devices for years to come.

By combining mobility, usability, and performance, CoWs increase efficiency and reduce errors with tasks such as entering patient data, gaining access to patients’ electronic medical records, reviewing lab results or radiology reports, and checking drug compatibility. But CoWs have limitations and potential issues, including:

• Size: CoWs can be cumbersome to move from room to room.
• Infection risk: Moving a CoW from one patient’s room to another can raise concerns about infection risk.
• Connection: CoWs connect to a hospital Wi-Fi network. If the Wi-Fi radio in a CoW is not designed to operate reliably in a hospital, then connection issues may cause CoW users to lose faith in the reliability of the CoW itself.
• Battery: A CoW computer must be recharged regularly.

Once a hospital encounters problems with reliable CoW operation, it may replace CoWs with a workstation in each hospital room. A newer and potentially promising alternative to a CoW is a medical tablet computer.

In an October 2010 blog post, Dr. David Ahn says that a medical tablet provides “an ideal form factor to bridge the analog to digital transition already taking place”. Ahn argues that a tablet is preferable to a CoW or a fixed workstation in a patient room because doctors and nurses can “actively engage the patient while writing or typing on a tablet, no different than they would with a notepad or chart in front of them.” Another post on the same site argues that, if a cart is needed or desired, then a tablet can be mounted to a cart.

Unlike CoWs, medical tablets are not cumbersome, can be wiped down to lessen infection risk, and have relatively long battery lives. But tablets can have Wi-Fi connectivity issues because their Wi-Fi radios are consumer-grade and not designed to maintain a secure and reliable connection in a challenging environment such as a hospital.

Providers: Are you using CoWs today? Do you plan to adopt medical tablets? Why or why not?

The vast majority of Wi-Fi client devices, however, operate only in the 2.4 GHz band, which has only three non-overlapping channels. The 2.4 GHz band also is the home of Bluetooth devices, cordless phones, some WMTS systems, microwave ovens, and other devices. The 5 GHz band is less cluttered and offers considerably more capacity, with up to 23 non-overlapping channels available (depending on regulatory domain). With more channels and fewer sources of RF interference, the 5 GHz band is attractive for a hospital Wi-Fi deployment, especially when the deployment covers many floors and APs are relatively dense.

5 GHz offers more channels and less congestion.

There are two types of 5 GHz channels: those for which dynamic frequency selection is required (DFS channels), and those for which DFS is not required (non-DFS channels). DFS, a mechanism defined in IEEE 802.11h, ensures that Wi-Fi transmissions will not interfere with radar. Using DFS channels with highly mobile devices may be problematic, depending on how those devices handle roaming.

A Wi-Fi client connects to a hospital network through an infrastructure endpoint called an access point (AP). When the client moves to a position where its connection to that AP becomes suboptimal, the client will try to switch to an AP that provides better connectivity. The process of switching from one AP to another is called roaming. The client must disconnect from the AP to which it is associated before initiating a connection to another AP. The longer the time between the disconnection from the network and the reconnection to the network, the greater the loss of packets and disruption to the applications running on the device.

The decision of when to roam, the selection of the target AP, and the management of the roaming process are handled by the client device’s Wi-Fi radio software. The roaming process has four steps:

1. Evaluate: Determine if the connection with the current AP is less than optimal.
2. Scan: If the connection is less than optimal, then scan the vicinity for other APs.
3. Select: Determine if any AP within range is likely to provide a better connection than the current AP.
4. Roam: Disconnect from the current AP and create a connection to the best candidate in the vicinity and authenticate to the network.

Scanning for available APs is disruptive to network connectivity, because while a client radio scans it is “off channel”, or not communicating with its current AP. Some client radios scan only when the current connection is suboptimal. Others do periodic scans, when the radio is not sending or receiving data to the current AP, and cache the results of each scan for a period of time that may be configurable. For a highly mobile device, the APs that are available when a roam is required may differ from the APs that are listed in the cached information. When a client’s applications require a persistent network connection, the optimal approach is to perform the scan just before the roam.

The larger number of channels available in the 5 GHz band provides for increased network capacity, but it also can lead to longer roam times for mobile devices, because effective roaming requires scanning of every available channel. When available channels include those that require DFS, scan times are even longer, because DFS channels require passive scanning, which is slower than active scanning. Network administrators should reserve DFS channels for non-mobile devices or look for Wi-Fi clients that support optimized DFS channel scanning capabilities.

For more information on 5 GHz operation and roaming, read Summit’s 5 GHz white paper or watch a replay of the Summit webinar on 802.11n and 5 GHz.

What Is Wi-Fi Direct?

Wi-Fi Direct is a peer-to-peer (P2P) connection technology. When Wi-Fi Direct is enabled on a client device, other Wi-Fi client devices are invited to connect to the Wi-Fi Direct device as if it were an infrastructure endpoint such as an access point (AP). The devices that connect to a Wi-Fi Direct device do not have to support Wi-Fi Direct and may not be aware that they are connecting to another client instead of an AP.

The Wi-Fi Direct FAQs on the Wi-Fi Alliance Web site indicate that Wi-Fi Direct is likely to be used not just in homes but also in enterprise environments such as hospitals. “The technology behind the Wi-Fi Direct certification program will be important for enterprise environments, enabling applications such as file transfer, printing, and display in the absence of a suitable WLAN. We also expect that the specification will be used in enterprises to temporarily connect mobile data terminals and other portable devices for short-term tasks such as data transfer.”

WPA2-Personal

According to another Wi-Fi Alliance Web page, “all Wi-Fi Direct connections are protected by WPA2™, the latest Wi-Fi security technology.” There are two versions of WPA2, Personal and Enterprise. Both use a strong encryption method called AES-CCMP to scramble all data transmitted over the air. The difference is on the authentication side. WPA2-Enterprise uses IEEE 802.1X, which offers enterprise-grade authentication that is sufficient for HIPAA. WPA2-Personal uses pre-shared keys and is designed for homes, not hospitals.

Wi-Fi Direct security must be configured on each client device for which Wi-Fi Direct can be enabled. Configuring security on “personal” devices requires the cooperation of the device user. Users can be forced to configure Wi-Fi network security on their devices because, if they don’t, then they cannot gain access to the hospital Wi-Fi network. But forcing users to configure Wi-Fi Direct security may prove challenging, especially if the device is used at home without strong security.

A Bridge to the Hospital Network

Even when WPA2-Personal is configured for Wi-Fi Direct, that security is not as strong as the WPA2-Enterprise used to protect the hospital Wi-Fi network. In an October 2010 blog post, wireless engineer Andrew vonNagy explains that, using Wi-Fi Direct, a device “can simultaneously be connected to the infrastructure as a client as well as establish a Wi-Fi Direct group session with one or many other group members, then allow those group members to access resources in the infrastructure.”

Such a scheme may be fine in a hospital if all group members are authorized to be on the hospital network. But what if an untrusted person joins the Wi-Fi Direct group? Hackers exploit vulnerabilities. If a hacker is able to connect to a Wi-Fi Direct client that is on the hospital network, then the hacker has access to the hospital network.

Purdue University student Matt Jurek raises this concern in another October 2010 blog post. “…with Wi-Fi [D]irect you are able to connect simultaneously to both your network and a P2P device or Wi-Fi Direct. So if someone attacked your Wi-Fi Direct connection, couldn’t they then tunnel into your existing network through that connection that they have created?”

Wireless analyst Rob Enderle states in a ComputerWorld article that Wi-Fi Direct enables any computer to become an AP. “If you have had problems with rogue access, oh boy, watch out…. You may need to rethink your security procedures,” says Enderle.

Preventing the Bridge

In a Wi-Fi Planet article, Intel senior product manager Gary Martz says that the Wi-Fi Direct specification places a premium on security. “We developed Wi-Fi Direct to have separate security domains, so your wireless LAN connection is a separate security domain from your Wi-Fi Direct network,” says Martz. “And the corporate IT manager can manage that crossover—does he want to allow that crossover, or does he want to firewall it?”

When a client attempts to connect to the Wi-Fi infrastructure, the infrastructure can identify whether or not that client supports Wi-Fi Direct and choose to allow or disallow the connection. Identifying whether or not clients support Wi-Fi Direct likely may require an upgrade to AP or controller firmware.

An Ounce of Prevention…

Richard Kirk, European director of Fortify Software, warns that keeping Wi-Fi Direct clients off the enterprise network is very important. Many of today’s Wi-Fi intrusion detection measures focus on APs, not on clients that can become APs. “Put simply, unless a portable device – such as an iPhone or smartphone – has got robust security on board, as well as applications that are secure against hacking, then an unauthorised person could establish a peer-to-peer connection directly,” says Kirk. “And if hackers can establish a peer-to-peer connection with a smartphone inside a company, they then have a foothold with which to gain unauthorised access to the company network from the other side of the firewall and security software,” he added.

Enterprise Efficiency Editor-in-Chief Matthew McKenzie sees no place for Wi-Fi Direct in an enterprise, at least for now. “First, if you work in enterprise IT, I suggest that you regard Wi-Fi Direct as a clear and present security threat until it proves itself otherwise. Quick, easy, instantaneous peer-to-peer connections among devices — printers, cameras, smartphones, tablets, and who knows what else — sounds like it will be very convenient… especially for people trying to move data they shouldn’t be touching to places it shouldn’t be going.”

Medical device makers often choose CE or Linux because:

• These OSs support the rich interfaces preferred by users
• Software engineers have experience with using these OSs and related tools on desktop PCs and servers

Because it is a fully-integrated development platform, CE makes it easy to get a project started, but CE has a royalty for use and has a code base controlled by Microsoft. Linux is free and open source, but getting Linux to work in an embedded device can be challenging, especially if the device offers a sophisticated user interfaces.

Android

Designed for ARM-based processors, Android leverages Linux to provide a full-featured embedded systems framework without license fees. With Android, the Linux kernel remains under the GPL, but other components are released under the Apache license, which allows Android to be used in both proprietary and open-source endeavors. This dual-license design provides some protection against the “viral nature” of the GPL.

Can Android provide the reliability, including a low risk to patients and users, demanded by many medical devices? Cohen contends that Android, like other heavyweights OSs, is appropriate for use in many Class I and Class II devices. With Android in use on tens of millions of handsets worldwide, the OS boasts an enormous pool of users finding bugs and a large developer community dedicated to fixing them.

The Future of CE

CE is not only a standalone operating system but the core of two other Microsoft operating systems: Windows Mobile (WM) and Windows Phone 7. The latter is specifically for phones, so the choices for medical devices are CE and WM.

While CE is available to any device manufacturer, WM requires special Microsoft approval and licensing. A device manufacturer chooses CE when it needs a highly customizable platform from system-level software to user interface to display size. WM is the choice when the device maker needs a consistent application programming interface (API) set to provide application portability across devices and a familiar and consistent user experience delivered on specified display sizes.

The current release of CE is CE 6.0 R3. With the next version, Microsoft is renaming CE to Windows Embedded Compact.  The current release of WM is WM 6.5. With the next version, Microsoft is renaming Windows Mobile to Windows Embedded Handheld. For more information on CE and WM, see this Summit newsletter article.

Device makers: What operating system will you choose for your next device? Why?

One of our October webinars covered 802.11n and Wi-Fi operation in the 5 GHz band.  If you have 25 minutes, then watch a replay of the webinar.  If you have more time, then browse our white papers on 802.11n and 5 GHz.

Some of the non-throughput benefits of 802.11n don’t  require client support. Once your infrastructure supports dual-band 802.11n, you can exploit the 5 GHz band, which is much less crowded than the 2.4 GHz band. You also will realize improved connectivity in both frequency bands, thanks to two 802.11n features: transmit beam forming and maximal ratio combining.

To take full advantage of 802.11n, you need to understand how it differs from and enhances the other over-the-air standards of 802.11b, 802.11g, and 802.11a. To take full advantage of 5 GHz, you need to understand how 5 GHz operation differs from 2.4 GHz operation. The Summit webinars and white papers will get you started.

Providers: What are your plans for 802.11n in the infrastructure? What about 802.11n on client devices?

Device makers: Do you support 5 GHz today via 802.11a/b/g or 802.11a/b/g/n? If not, then what are your plans for 5 GHz support?

• Security: Ensuring that Wi-Fi security is compliant with HIPAA requirements and sufficient to protect sensitive information such as electronic medical records
• Connectivity and mobility: Ensuring that Wi-Fi devices get on the hospital network and stay on the hospital network, even when devices are mobile and Wi-Fi coverage is spotty in some areas
• 802.11n and 5 GHz: Does 802.11n live up to the hype? How widely is it supported? What are the pros and cons of the 5 GHz band for Wi-Fi?
• CCX and standards: What is the role of the Cisco Compatible Extensions program in hospitals? Which IEEE 802.11 standards are supported by devices used in hospitals?

The goals of this blog are to share information, inspire conversation, and even spark debate. All three of these goals, especially the last two, are up to you. We welcome your feedback, your comments, your suggestions, and your ideas.

Stay for a while, and visit again soon.