The Healthcare and Enterprise Wireless Experience

Wireless Security in Healthcare and a new model

Security within the healthcare environment both at the provider level and the medical device level has had many challenges. Those challenges include but are not limited to:

1. Inconsistent testing of wired and wireless devices that now incorporate network connectivity for the myriad of security protocols for wireless enabled medical devices.
2. Lack of documented deployment guidelines surrounding security.
3. Comprehensive intrusion detection systems not in place for forensic analysis.
4. New wide area connectivity options such as M2 to M2 that will pass mobile medical and healthcare data from the point of care through a cellular network irrespective of the carrier.
5. The need to embrace new security methodologies that will decrease cost, decrease risk, and ensure consistency in security of data on mobile medical devices as well as within the provider market.

Integra Systems, Inc., has worked with many medical device companies to validate and verify their now enabled wireless medical devices for pre FDA510k approval. As a result we have had to validate and verify that these wireless medical devices can exist within the myriad of wired and wired security schemas deployed by hospitals today. Network security is a major enterprise WLAN concern and this requires comprehensive testing. Most enterprise WLANs use strong authentication and encryption, usually server based (i.e. RADIUS) to differentiate and centrally control user access and privilege. WPA and WPA2 (802.11i), are the key wireless security protocols that mediate between clients and authentication servers. The common authentication protocols used in wireless networks in the enterprise include PSK, EAP-PEAP/MS-CHAPv2, EAP-TTL-GTC, LEAP, EAP-FAST and EAP-TLS.

1.For all wireless enabled medical devices that will be connecting it is recommended that the medical device manufacture test and validate the following security.
WPA
-IEEE 802.1X authentication
-Temporal Key Integrity (TKIP) encryption
-Support for EAP-Transport Layer Security (EAP-TLS)
WPA2
-IEEE 802.1x authentication
-AES encryption
-Support for EAP-TLS

Security other EAP
-EAP Tunneled TLS Microsoft Challenge Handshake Authentication
-Protocol Version 2 (EAP-TTLS/MSCHAPv2)
-Protected EAP Version o (PEAPv0)/EAP-MSCHAPv2
-Protected EAP Version 1 (PEAPv1)/EAP Generic Token Card (EAPGTC)
-EAP Subscriber Identity Module (EAP-SIM)
-EAP-TLS, an Internet Engineering Task Force (IETF), global standard protocol which uses digital certificates for authentication.
-EAP-TTLS/MSCHAPv2, which securely tunnels client password authentication within TLS records
-PEAPv0)/EAP-MSCHAPv2, which uses password based authentication.
-PEAPv1/EAP-GTC, which uses a changing token value for authentication.
-EAP-FAST, which securely tunnels any credential form for authentication (such as a password or a token using TLS)

2.Healthcare providers should have a consistent deployment guideline for all mobile medical devices and/or smart phones that connect to any wired and/or wireless network.

3.Healthcare providers should provide some documented IDS (Intrusion Detection) system for wireless networks.
-There should be the ability to provide rogue mitigation by identifying any rogue device and automatically removing it from the network.
-Forensic Analysis should be provided to retrace any device footsteps down to the minute by event.
-Policy and compliance reporting should be provided for PCI, DSS, D02 8100.2, HIPPA, GLBA, Sarbanes Oxley as well as corporate policy enforcements.
-Wireless Vulnerability Assessment that will enable remote wireless testing of the networks security posture.

4.As now new M2 to M2 devices are being used over the wireless carrier, network new attention needs to be placed to providing security “outside the walls of the hospital”.

5.Security implementation(s), for wireless medical devices have often opted for the latest network security provided by the enterprise space, i.e., WPA2, they are also now embracing the user model of Citrix receivers and virtualization. Both the medical device community as well as the enterprise community have not adopted consistency in security.

6.A new model which is based upon proven security in the metering of financial transactions has emerged for the medical device and healthcare space from www.pb.com This model could decrease dramatically the cost of the implementation of complex security end to end solutions and provide for consistent security methodologies irrespective of mobile medical devices (smart phones), wireless/wired enable medical devices as well as other mobile medical platforms. The embedded ASIC essentially provides security at the application layer on any device. The same embedded ASIC provides the ability to upload/download money into postal metering on a global basis every day. It is suggested that the medical device community both on a wired and wireless side start to embrace this new business model.

The description of this is as follows:
-A single chip cryptographic model which meets FIPS 140-2 physical security level 3
-Provides FIPS 186-2 compliant 1024 bit public key cryptography engine for
DSA (Digital Signature Algorithms)
RSA (Rivest Shamir Adleman)
ECDSA (Elliptic Curve DSA)
-Provide side channel attack (SPA/DPA/TA) resistant architecture
-Enable secure downloading for medical device application software through 256-bit ECDSA.
-Enable highest level of security to include
FIPS 180-2 compliant Hash Engine (160, 224, or 256 bit)
FIPS 197 compliant Triple Data Encryption (3DES) Engine

FIPS 140
The 140 series of Federal Information Processing Standards (FIPS), are U.S. Government computer security standards that specify requirements for cryptography modules. As of December 2006, the current version of the standard is FIPS 140-2, issued on 25 May 2001. The National Institute of Standards and Technology (NIST) issues the 140 Publication Series to coordinate the requirements and standards for cryptographic modules which include both hardware and software components for use by departments and agencies of the United States federal government.

FIPS 140 imposes requirements in eleven different areas
Cryptographic module specification (what must be documented)
Cryptographic module ports and interfaces (what information flows in and out and how it must be segregated)
Roles, services, and authentication (who can do what with the module, and how this is checked)
Finite state model (documentation of the high level states that the module can be in, and how transitions occur)
Physical security (tamper evidence and resistance, and robustness against extreme environmental conditions)
Operational environment (what sort of operating system the module uses and is used by)
Cryptographic key management (generation, entry, output, storage, and destruction of keys)
EMI/EMC
Self tests (what must be tested and when, and what must be done if a test fails)
Design assurance (what documentation must be provided to demonstrate that the module has been well designed and implemented)
Mitigation of other attacks (if a module is designed to mitigate against say TEMPEST attacks, then its documentation must say how.

FIPS 140-2 Level 1 the lowest imposed very limited requirements, loosely all components must be production grade and various egregious kinds of security must be absent.
FIPS 140-2 Level 2 adds requirements for physical tamper evidence and role based authentication.
FIPS 140-3 Level 3 adds requirements for physical tamper resistance (making it difficult for attackers to gain access to sensitive information contained in the module) an identify based authentication, and for a physical or logical separation between the interfaces by which “critical security parameters” enter and leave the module and it’s other interfaces.
FIPS 140-4, Level 4 makes the physical security requirements more stringent, and requires robustness against environmental attacks.

Global Enterprise Cellular M2M Connections will Nearly Triple by 2015

Yanke Group forecasts revenue from connections alone will approach 7 billion.

Boston, MA April 5, 2011. After years of anticipation, the machine to machine (M2M) era has finally arrived.

A new Yankee Group forecast predicts enterprise cellular M2M connections worldwide will surge from 81.8 million in 2011 to nearly 217.5 million in 2015. In the same time frame, connectivity revenue will more than double from U.S. 3.1 billion to U.S. 6.7 billion, making the M2M market one of the highest growth ares in the wireless arena in the next decade. Several predictions are apparent. Connected energy and mHealth represent massive potential markets over the long term. See the attached report.

View this photo

Download The-Next-Tipping-Point-The-Connected-Experience_YGreport_Mar2011

IEC 80001-1: 2010 Application of risk management for IT networks incorporating medical devices

Application of risk management for IT-networks incorporating medical devices
Abstract
IEC 80001-1: 2010 recognizing that medical devices are incorporated into IT-networks to achieve desirable benefits (for example, interoperability), defines the roles, responsibilities and activities that are necessary for risk management of IT-networks incorporating medical devices to address safety, effectiveness and data and system security (the key properties). IEC 80001-1:2010 does not specify acceptable risk levels. IEC 80001-1 2010 applies after a medical device has been acquired by a responsible organization and is a candidate for incorporation into an IT-network. It applies throughout the life cycle of IT-networks incorporating medical devices. IEC 80001-1:2010 applies where there is no single medical device manufacture assuming responsibility for addressing the key properties of the IT-network incorporating a medical device. IEC 80001-1:2010 applies to responsible organizations, medical device manufactures and providers of other information technology for the purpose of risk management of an IT-network incorporating medical devices as specified by the responsible organization. It does not apply to personal use applications where the patient, operator or responsible organization are one and the same person.

The aforementioned is the actual abstract from the http://www.iso.org web site.
Risk Management means both wired and now “wireless” medical devices.

The medical device company and wireless capabilities
For the sake of discussion this will primarily discuss 802.11a/b/g/n incorporated medical devices (actually no 802.11n enabled medical devices exist today (power and MIMO issues),but this will also extend to those now starting to incorporate both GSM/CDMA (3G), and LTE (4G). Same similar type of concept; however the 3G/4G network is not internal to the hospital IT environment, but external, thus the shift of any risk to the carrier side. This is the challenge with the 3G/4G devices with medical applications, i.e. quality of service and/or security.

The vast majority of medical device companies are now moving very quickly to network enable their medical devices and shift away from proprietary radio technologies and/or networks. (Rationale, connectivity to the EMR.) First, it is not as easy as it sounds because these wireless competencies are not always present internal to those respective companies that have designed for years “stand alone” medical devices. They often simply go out and find a 802.11a/b/g embedded radio or board, write custom drivers, and then test in-house or in a limited setting for network connectivity. They may or may not know how to design the right antenna micro strip or test this device with the embedded antenna prior to deployment. However, this only one piece of the equation. They may have gone through the FCC and EMC certifications, but while this will treat the system as a “stand alone device or system”, does this really characterize how this device with the embedded WLAN radio and antenna element will operate in a real world environment (hospitals), (different multi-path situations), or under actual load situations, proximity to other RF emitters, and/or all the different security protocols beyond just WPA2? Some of this assumption is probably, well this is WIFI and it just works! The reality is each medical device company has pretty much come up with their way of conducting this internal testing; hence the reason why the industry and thus IEC 80001-1:2010 perhaps needs to validate and recognize what is considered the proper risk validation of the testing of a “wireless” and or “wired” medical device or emitter on a healthcare IT network. Integra Systems, Inc. www.integrasystems.org has been involved in many such validations of wireless enabled medical devices for prior FDA 510k submittals.

We have written the detailed test plans and test protocols to validate how the potential “wireless enabled medical device” will need to be tested, as well as actually conducting the testing. On a high level this includes conducting a predictive model of the facility to understand the RF characteristics, obtaining current network topologies, designing the proper segmentation of the network, completing spectrum analysis on site to determine the baseline of testing, conducting load testing in methodical fashion using such equipment from www.veriwave.com, testing against virtually all of the security protocols and methods used in both the wired and wireless industry and finally conducting RF proximity testing with all the various wireless emitters used in hospitals today. This ranges from microwave ovens, Zigbee, Bluetooth, WMTS, cellular (both GSM/CDMA/LTE), public safety radios, and other spurious emitters, such as 900MHz paging, and outdoor to indoor propagation. The complete combination of all this testing in a real world environment will show that the wireless enabled medical device performs as medical device intended for the described use model, based in this known and validated environment under different network loads, security protocols, and the myriad of RF emitter conditions. It should be additionally added that when testing, that actual use model needs to be taken into account. Will the device be used inside a patient room that has a bathroom (multi-path, water, metal, and/or firewall shielding the signal from reaching the access point? Will the patient be in bed with the device, or in a highly mobile environment? Will the patient with the "wireless" medical device going to radiology (lead lined rooms), or may have to be in isolation? What about the age of construction, new or old hospital construction methods? Did the prior implementation take into account the number of actual medical devices that might reside on the network for QoS? This combination of data when submitted should provide the the proper documentation prior for regulatory approval for risk mitigation and satisfy the heart and intent of the IEC 80001-1:2010 and either the initial IDE and PMA 501k.

Risk Management for IT-networks incorporating medical devices
If the medical device manufacture has followed the aforementioned best of practice, they will then have the baseline documentation necessary to create the right deployment guidelines for the intended medical device. These deployment guidelines should be able to specify the proper security, quality of service, and architecture design criteria and minimize any potential risk. Some of the recommendations for the actual deployment model in a hospital is to actually understand the complete architecture of the network. This can often be done by obtaining the network design plans, but a much more comprehensive analysis can be completed by using WaveDeploy from www.veriwave.com. Once the information is obtained in terms of network traffic, this can be combined with a predictive model from using tools from both www.motorola.com and www.ibwave.com. (Note Ibwave for 3G/4G) Combining all these data elements allow with the requirements based upon the deployment guidelines will provide the right risk management for IT – networks incorporating medical devices. Ideally, then this becomes the deployment guidelines and sign off documentation by the hospital upon the deployment of the “wireless medical device and/or devices" on the hospital IT network.

Risk Management for IT-networks incorporating medical devices – Post Deployment
The combination of all of these data elements will dictate the correct design and changes in the hospital IT network that is going to incorporate wired or wireless medical devices. While this will determine what is correct and what will operate as intended when deployed; it does not provide the sufficient level of guarantee that if the network environment changes, (i.e. new firmware updates into the AP and controller), how will this effect or not affect the operation of the wireless enabled medical device previously validated? It now simply means that there needs to be a way of understanding a feedback loop that will provide the hospital and/or medical device manufacture a way of knowing of “changes in the network”. This could be as simple setting up the right SNMP monitoring service inherent in the wired network, or off load this to a real time 24/7/365 monitoring service. If this monitoring service is enabled either in-house or perhaps an ASP model, this will follow again the intent of IEC 8001-1:2010, that is risk management for IT-networks incorporating medical devices.

SummationThe application of risk management for IT-networks incorporating medical devices demands a standardized process for testing of the medical device prior to regulatory approval, a consistent methodology for hospital deployments, and a post implementation monitoring of the integrity of network. If these steps and processes are followed; then risk should be mitigated, safety, effectiveness, and system security (the key properties), will be assured.

Download Best_Practices_for_Pre_and_Post_Deployment_Verification

Download Product_brochure

Verizons 4G Network Leaves Other Carriers in the Dust

RootMetrics found Verizon's 4G upload and download speeds significantly higher than other carriers. Is the smartphone that you purchased really obtaining 4G speeds?

Rootmetrics performed an extensive study to determine how each network's 4G speeds are holding up to their claims. The testing was performed across the Seattle area.

The findings showed that Verizon's LTE network performed at a 100% data-success rate. (I have the 4G modem on my laptop and can attest to this!) It's average data speeds were between four and 14.5 times faster than competitors, and the average upload speeds were between 4.7 and 49.3 times faster. The phone models tested included the HTC Thunderbolt (Verizon), HTC Inspire (AT&T), HTC Evo Sprint and Samsung Galaxy S (T-Mobile). Root Metrics CEO Paul Griff said that the smartphone model and its hardware had very little to do with 4G performance - that performance is almost always network related. Rootmetrics were careful to point out that merely achieving high data speeds does not mean much unless it happens on a regular basis. It found that Verizon's 4G downloads speeds were greater than 10 Mbps about 90 percent of the time, and their upload speeds were between 5 and 10 Mpbs 100 percent of the time. And Verizon's average upload speeds were faster than every other carrier's average download speeds by 37 percent.

3G and 4G Medical Applications Integra Systems and Pitney Bowes

While many have advocated the use model of data and other medical device applications on the 3G and now 4G (LTE) network, they have failed to understand the security and quality of service requirements; since this is now hinges on the carrier. Unlike the WLAN model whereby this has some semblance of standards, i.e. 802.11i and 802.11e and predictive modeling; this has not moved forward in this new 3G and 4G enterprise model. Integra Systems Inc. is working on an exclusive nature with Pitney Bowes to develop the next generation security model for embedded medical devices, not only from the WLAN, but wired and 3G and 4G model with www.pb.com.

This trusted Mobile Development Platform includes but not is limited to a Cryptographic Accounting Module (CAM) (Single chip solution - 10x10 mm 144 pin TFBGA), and a (CAM) Secure Infrastructure of which is provided by an embedded microcontroller and crytographic co-processor of which meets FIPS 140-2 Level 3 + EFP requirements, RSA/DSA and Elliptic Curve Algorithms, AES and DES, secure random number generator. Further it includes a fully integrated public key certificate authority, secure transaction management, and remote device management.

Algorithms supported include:
FIP 186-2 compliant Public Key Cryptography Engine (DSA, RSA and ECDSA)
FIPS 180-2 compliant Hash Engine (160, 224, or 256 bit)
FIPS 197 compliant AES Engine (256 bit)
FIPS 46-3 compliant 3DES engine
Hardware Random Number Generator
Side channel attack resistance (SPA/DPA/TA)
Active tamper detection and response circuit
3.3V design, 20mA when active.

Wireless and Medical Technology RoadMap Planning

Over the course of several years it has been quite clear that the provider market needs quantitative and qualitative tools for the planning of wireless and mobility technologies. A lot of CIO(s), simply do not have the time to devote to the development of a strategic business plan surrounding this. Let alone the technology envelope and speed of change has become very, very rapid. Thus, decisions tends to be made in silos, the RFI and RFP may not cover the bases, and implementations have challenges. Marketing and sales from the companies may not be well versed in explaining the technologies or limitations thereof; so the potential client may be increasing their risk from not only the CAEX but OPEX as well.

Over the course of the next couple of months Integra Systems will design respective tools to aid in technology roadmap planning. This will cover the range of WLAN, cellular, PCS, public safety, RTLS, RFID, Zigbee, WLAN enabed medical devices. We intend to target the healthcare vertical through various channels.