The Three Pillars of Security for Medical IoT Devices

There is no hiding from the reality that Wi-Fi-based IoT devices face a rapidly increasing number of security threats. For hackers and criminals, IoT devices are often the “soft underbelly” of an organization’s IT infrastructure because of the complexity of keeping them secure once they are deployed. This is particularly true for IoT devices in medical settings.

One reason security is particularly challenging for medical IoT devices is how many there are. Hospital rooms, ER departments and exam rooms have an incredibly dense volume of devices, including wirelessly connected monitors, pulse-ox sensors, infusion pumps, patient monitors, defibrillators, ventilators, beds and more. The volume of those devices makes security an enormous challenge, but so does the volume of people. Unlike IoT devices in industrial settings, for example, where access can be highly controlled, hospitals and clinics are open buildings with hundreds or thousands of people each day. Any of those are potential bad actors who can purposefully or accidentally cause a security issue. Compounding the issue further is the longevity of connected medical devices, whose life cycle has the potential to be 30 years or more—far longer than IoT devices in most other industries. 

That is a trifecta of security worries: Lots of devices that must serve a lot longer than typical IoT devices while being accessible by a lot of potential bad actors. This trifecta makes it critical for the engineering teams that design and deploy these connected medical devices to have the right long-term strategy for security. If engineering teams do not have the right strategy to security up front, these devices will require costly, arduous engineering efforts over those 30-year lifespans to address security concerns. That risk begins on the day they are deployed and grows significantly worse over time, particularly at the end of the product’s life when the underlying application firmware may no longer be updated and supported by the manufacturer. During that last phase of a medical device’s operational service, devices are at risk of needing expensive engineering initiatives to try and keep pace with the relentless security attacks found in today’s IT environment.

The wrong security strategy also carries a long list of other risks:

• Vulnerability to attacks that exploit outdated software on the Wi-Fi module to further attack the hosted platform
• Slow, frustrating processes for distributing timely security updates
• Elevated risk of damaging, costly security breaches
• The risk of regulatory-forced recalls or stop ships for non-compliant products
• Risk of compliance failures involving FIPS and other current and future regulatory requirements
• Leaks of confidential organizational and patient data both during the devices lifecycle and after it is disposed

Perpetual security threats of this scale cannot be solved with an overly-tactical approach. Too often, that only addresses issues for the short term and leads to long term security headaches for healthcare organizations. Instead, medical product designers should take a holistic, strategic approach to device security from day one of a design project. This strategy should be based on three critical pillars that will provide the foundation for security throughout a connected device's lifespan. 

The three pillars of security this article will detail allow manufacturers to ensure that their Wi-Fi-enabled medical devices will be secure for their entire life cycle:

• Chain of Trust Device Security [Protects device for malicious firmware]
• FIPS Cryptographic Modules [Prevents data theft]
• A Long-Term Foundation for Vulnerability Monitoring and Remediation [Maintains security]

First Pillar: Chain of Trust Device Security

Chain of Trust is a critical pillar because it ensures the medical device is using valid device firmware created by the device manufacturer rather than one modified by a malicious or rogue actor. These security threats often come from hackers seeking to exploit the boot-up process or operational firmware by injecting malicious code onto the devices to enable any one of today’s common cyber security attacks. The Chain of Trust beginning at the manufacturing level ensures prevention from those kinds of actions that would lead to a breach of various forms of confidential information. 

Building a secure Chain of Trust from scratch requires deep expertise in security architecture, large scale device key programming, and development of a secure key management solution—all of which can require years for an engineering team. Chain of Trust as a built-in pillar eliminates the burden of developing a device security architecture, implementing new secure manufacturing processes, and creating a secure application for device image signing and key management. 

As you evaluate your options for achieving this pillar, be sure to look for solutions that generate cryptographic keys and certificates unique to your company, device family, model number, part number, etc. A solid signing service stores and manages these secrets for future use, enabling you to perform high volume secure provisioning and programming of the hardware root-of-trust on each product and securely-signed software images. 

The following are key features for achieving secure Chain Trust: 

• Secure and verified boot architecture
• Secure enclave architecture
• Secure file storage architecture
• Secure signing service

Second Pillar: FIPS Cryptographic Modules and Implementation

Any discussion of medical device security requires a major focus on FIPS certification, which is why it is the second pillar of an effective strategy for true security. There are two versions of FIPS that medical device engineers need to factor into their product development timelines: FIPS 140-2 and the newer, more rigorous FIPS 140-3. FIPS ensures that your selected encryption method is effective enough to protect your network devices along with patient and user data. It is critical to device security, but implementing it successfully is not simple.

We know FIPS validation is a complex process. Building your own FIPS 140-2 solution from scratch takes years of development. The challenges increase with FIPS 140-3, the new iteration of the FIPS standard, which is even more rigorous to comply with and the validation process is even more comprehensive. Often implementation is blocked by device limitations, so make sure you confirm ability to comply with FIPS requirements as part of your device evaluation.

As you evaluate your options, an important issue for your team to evaluate is the balance between achieving FIPS requirements and optimizing performance. There is a tradeoff between those two because of the impact that hardened security can have on device data speeds, battery life, etc. Be sure to work with components and design partners that are able to tune the balance between those two to meet your device’s specific needs.

Third Pillar: Vulnerability Monitoring and Remediation

The last but certainly not least consequential pillar of this holistic approach to device security is vulnerability monitoring and remediation. For these devices to fulfill their missions for their entire life span—which I’ve noted can be upwards of 30 years—they need to be supported by a security strategy that simplifies the process of identifying and fixing vulnerabilities over time.

Maintaining device and data security over time is no small task given the increasing number of Common Vulnerabilities and Exposures (CVEs) that threaten wireless devices deployed in the field. One of the most critical aspects of this is management of devices’ software bill of materials (SBOM); this often requires the creation of custom tools to scan, monitor, and report on the components and versions being used within the product. The foundation for simplifying this process is having a supplier who provides a stable maintained software stack for their wireless devices and, where possible, is able to provide expedited status of their supplied software components with respect to the latest CVE.

One thing you can be sure of is that security of your devices and customers’ data is only going to get more critical as the volume of devices, applications and data increase. Security is almost impossible to add later and must be considered as a fundamental feature within your device’s development cycle. The pillars listed in this paper are just a framework to allow you to structure your implementations specific to your device and application. Stay safe, stay secure.

About the Author

Andrew Ross is a Senior Product Manager at Laird Connectivity, where he leads the company’s product development for Wi-Fi technology. He is responsible for development of Laird Connectivity solutions that help companies around the world take advantage of the next generation of Wi-Fi. Ross has more than 30 years of engineering experience in electronic design, including prominent engineering and product development roles at Silex Technology, B&B Electronics, Quatech, DPAC Technologies and Mosaic Semiconductor.