Most of today’s medical devices were built without security in mind. The level of risk posed by these devices depends on their designs and the associated clinical workflows. For instance, heart defibrillators, insulin pumps, and glucose meters can be wirelessly hijacked and reprogrammed. Other device vulnerabilities are exploited by diabetes patients who are exploring new ways to manage the disease.
Many patients link monitoring in real-time to their mobile phones to adjust the alarm volumes or choose other ways to be alerted when glucose readings are above or below the target threshold. Others have made their continuous glucose monitoring (CGM) data available on their smart watches to remove the inconvenience of having to pull the receiver out of their pockets and press the button to turn on the screen.
In October 2018, the FDA published a draft set of medical device cybersecurity guidelines for designing trustworthy devices, including recommendations for reducing the risk of multi-patient harm. Once finalized, the guidelines will provide updated recommendations to medical device manufacturers regarding cybersecurity device design, labeling, and the documentation that should accompany devices with cybersecurity risk.
These recommendations can be implemented most effectively using a security-by-design approach. When commercial smartphones are added into the mix to control medical devices and access health data and applications, it’s particularly important that this approach also encompass end-to-end, multi-layered protection against cybersecurity threats.
End-to-end security
First protection layer– A secure communications channel between the smartphone app, the medical device, and the cloud, called application-layer security, augments existing security mechanisms already built into operating systems such as Android and iOS. Authorized devices automatically connect to intermediate hardware gateways or smartphone apps within communication range using Bluetooth. Connected health solutions that use these secure communication channels are resistant to various malware and wireless channel cybersecurity attacks.
Second security layer – Ensure all information and commands can only originate from an authorized and trusted source, which requires authentication of the smartphone app, cloud, and any associated devices connected to the solution’s communication system.
Only an authorized device can become a trusted entity on the network, under control of the trusted cloud. To achieve this, a unique digital cryptographic identity is given to all system elements, and each element can validate the authority and privileges of the other elements, also known as attestation. Creating this root of trust within and between all components protects against the risk of attack through connectivity to its cloud services, smartphone apps, and other IoT devices. The trusted cloud infrastructure verifies integrity and authenticity of trusted smartphone apps and medical devices, issuing digital certificates to them to identify them as trusted. It also manages all identities throughout its life cycle on the system’s network.
The authentication layer is most effective when a hardware security module (HSM) is provisioned at the factory to each medical device. The HSM stores and manages all cryptographic keys and digital certificates that identify the device and all device programming. Final testing is tightly controlled during manufacturing. When the device is on-boarded in the connected healthcare system, it is already pre-programmed to interact only with approved gateways in the field. Building security into a solution from the beginning also makes it difficult to reverse-engineer or tamper with devices, protecting against counterfeits.
Third security layer – Always-on connectivity allows systems to receive the most recent data needed to immediately change device operation based on patient requirements. Solutions that depend exclusively on a handheld device or smartphone to deliver cloud connectivity cannot always achieve the high level of continuous data availability and device control required for mission-critical applications. They are vulnerable to dangerous operational lapses if the handheld device or smartphone becomes unavailable for sending data to the cloud and receiving commands from it for device control. Solution providers can combine traditional fixed gateways and employ the smartphone itself as a soft gateway.
Easier implementation
Historically, it would have been difficult and prohibitively expensive for a medical device manufacturer to add multi-layered security to its product offering. Today, these capabilities can be implemented as building-blocks using security software suites and HSM factory-provisioning services from a third-party cybersecurity technology provider. Comprehensive software development kits (SDKs) include all necessary application programming interfaces (APIs) to enable rapid incorporation into a medical device developer’s solution.
Security-by-design best practices are arguably more critical in healthcare than in banking, where they have been widely adopted to protect systems and transactions in compliance with cybersecurity and privacy regulations. The proven practices also align with FDA guidelines for building trustworthy devices.
They protect patient safety and privacy by securing a systems’ communications, ensuring that all information and commands come only from authorized sources, safeguarding patients’ health information, and maintaining the continuous connectivity that is critical for reliable patient care.
Explore the January February 2020 Issue
Check out more from this issue and find your next story to read.
Latest from Today's Medical Developments
- Children’s National, FDA collaborate to advance pediatric device regulatory tools
- LK Metrology’s eco-friendliness CMMs
- Two patents for microfluidic valves
- AMADA WELD TECH’s blue diode laser technology
- Post-IMTS decline in manufacturing technology orders blunted
- ARS Automation’s FlexiBowl 200
- LMA Consulting urges businesses to restructure supply chains now
- Walter’s WEP01C indexable inserts