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.