How to Secure Patient Data on Medical Mobile Devices

by Jeridiah Welti / December 5, 2023

The rapid growth of connected and miniaturized medical devices has empowered healthcare providers to offer patients greater autonomy in managing their health from the comfort of their homes. Wearable devices seamlessly integrate with mobile apps, enabling continuous data collection and analysis while significantly enhancing data quality compared to traditional healthcare settings. However, these advantages also bring heightened concerns, including the risk of data exposure to bad actors and potential tampering with medical treatment devices, posing serious threats to patient safety. Mobile devices and their applications provide a unique vector for these attacks. The pervasiveness of smartphones makes for a natural platform to provide interfaces for a user’s device, but this ubiquity also opens new avenues for potential security breaches. The only way to maintain security of the end user’s information is through a robust application, and then testing that application in a simulated hostile environment.

Medical device designers must assume zero trust with every connection. Good data handling and credential practices will go a long way to ensuring the security of the device, its information, and any dataflows to cloud systems. Additionally, it is critical for the success of the medical device that developers and manufacturers stay well informed about the latest regulations and guidelines from regulatory bodies such as the Food and Drug Administration (FDA) in the United States and the European Union’s European Medicines Agency (EMA). Staying current with these regulatory bodies ensures that medical devices not only deliver innovation but also meet stringent security and safety requirements to protect patient data and prevent potential harm.

Insecure Mobile Devices and their Applications

Personally Identifiable Information (PII) and Protected Health Information (PHI) are of particular interest to many bad actors. This information can be used to access a wide variety of services and provides a unique vector for defrauding others. For instance, by accessing this sensitive data, these actors can open fraudulent claims, order prescriptions, or even receive treatments for someone else.

According to research collected by Statista, 2023 saw an estimated 7.3 billion mobile users worldwide. For many of these mobile users, mobile phone haptics allow for moving regular notifications, feedback, and user interface from the medical device to a familiar personal device. This is an advantage to both the device manufacturer and the end user.  However, this comfort and convenience comes at a cost. Since it is virtually impossible to qualify all the makes and models of smart devices on the market, the medical device developers need to define what they will test and qualify to and whether they are going to simply provide an app to support their own device. Then there is the concern of the other apps on the device. While that entertaining block-smashing game might seem innocuous, it might also be collecting data from your smartphone and sending it to a collection service.

Perhaps the answer is to simply create a closed relationship between the mobile phone and the medical device. While this mitigates many issues, it also promotes a false sense of security. Once a device is connected to a home network, it is only as safe as that environment. And, since many home environments are not cybersecure (or not cybersecure “enough”), the device is vulnerable to attacks. However, the scope of today’s discussion is not on securing a home’s cybersecurity but rather on maintaining the security of the end user’s personal information on medical devices.

Mitigating Brute Force Attacks on Mobile Medical Devices

No matter the deployment model that is chosen, it is evident that the only way to maintain the security of the end user’s information is through a robust application and testing in a hostile environment. As mentioned earlier, medical device developers should adopt a stance of absolute caution for every connection they establish. Implementing robust data-handling procedures and adhering to sound credential practices are paramount to fortifying the security of the device, protecting its data, and ensuring the integrity of dataflows to cloud systems. Common pitfalls in this regard — much like those encountered in typical software applications — encompass weak authentication and authorization (A&A), insecure data storage, insufficient data encryption, inadequate input validation, and a deficiency in proper session management.

Authentication is the act of verifying the user is who they say they are; authorization is verifying that the authenticated user has the ability (clearance) to execute the operation being attempted.  The FDA and EMA both have recommendations on minimum levels of A&A strength, as they have long recognized the importance of quality authentication methods. With the proliferation of inexpensive computing power, short or simple passwords are trivial for bad actors to brute force. Requiring end users to have sufficiently complex and long passwords helps to prevent this. Another strategy to help mitigate brute force attacks is to add delays if a password is entered incorrectly multiple times. Additional mitigations are just as important to provide appropriate levels of authorization for the type of user that is connected. The end user of a device might only need to know basic maintenance information of their device (remaining treatment time/dosages, battery life, etc.), but a clinician may want to view all the raw data that has been collected and be able to offload it to another device (cloud, local server, etc.). It is critical to only provide the level of access necessary for a given role and no more.

Proper and Secure Storage

Generally, the bad actors are looking for data, so storing it properly and securely is of utmost importance. Data needs to be encrypted whenever possible in any state — at rest, in transit, or in use. An analogy of the three types for one in an office setting:

  • Data at rest is equivalent to a file folder in a file cabinet
  • Data in transit is analogous to data in an office mailer on its way to an intended recipient
  • Data in use is like viewing a file on one’s desk

Considering these types of data, it is easy to see that data at rest is easiest to secure. Data in transit can be easily secured but is subject to interception and modification before the intended recipient receives it. Data in use presents the most challenges to secure since, at some point, the information needs to be revealed to be useful. Part of securely storing data is the selection of an appropriate encryption method along with the associated strength. Many older encryption strategies are considered cryptographically broken and should not be used for data that needs to remain secure.

There are two types of cryptographic strategies — symmetric and asymmetric:

  • Symmetric encryption can be reversed with the same key that was used to encrypt it. But how does one share the key so that bad actors are not also aware of the key and invalidate the entire purpose of encrypting the data in the first place? This is one of the critical functions within cybersecurity. However, an explanation of practices around this is beyond the scope of this article.

  • Asymmetric encryption is not reversible by the same key. It uses key pairs; a public key and a private key. The public key, as its name implies, is public. A sender will use this public key to encrypt something and send it to the holder of the private key, which is the only key that can be used to decrypt the information.

Many cybersecurity exposures are a result of bad actors abusing a system for other than its intended purpose or intent. This is where input validation (or lack thereof) is a key player. Any opportunity for a “free form” input is an opportunity to put in something the designer of the system did not expect. There are many ways to abuse input validation, but a frequent term that is discussed is SQL injection. Many devices use a database to store collected data, user account information, and other information. A basic definition of an injection attack is that a command is input where other information is expected (such as a password). The system takes this input, and instead of looking up the data, it executes the command given. The system then potentially reveals data that was not intended.

The final issue to consider is session management. From a simple viewpoint, session management involves ensuring that all requests from a particular user are managed and handled in a unique user-defined session. A relatable scenario is approaching a bank teller and executing a few transactions (pay a mortgage, withdrawing some cash, etc.). After one leaves the window, it is expected that the teller will close all related accounts and start over with the next client. We would not expect the teller to just hand the next client money from our account if they asked.

The Security of Your Mobile Medical Device Matters

As guidelines and security issues continue to challenge mobile medical device development, partnering with an experienced engineering, design, manufacturing, and test development team is critical to your success. It is essential to choose a partner with a proven track record in helping customers create innovative and secure medical products. Whether you are venturing into the world of wearable healthcare devices or looking to enhance your existing medical technology, remember that success often hinges on collaboration with those who bring expertise, innovation, and a commitment to quality to the table.

Interested in learning more about how to navigate the complexities of designing and developing a secure mobile medical device? Reach out to Benchmark for guidance and valuable insights. We can provide valuable information to help you make informed decisions and achieve your healthcare technology goals. 

Stay tuned for the second article in this three-article series, where we will further discuss some of the challenges of testing mobile applications and best practices to address some of the issues presented here.

Medical Connected Devices Design & Engineering

about the author

Jeridiah Welti

Jeridiah is a Systems and Software Engineer based in Benchmark's Winona, Minnesota location. He serves as Benchmark's cybersecurity lead in the design engineering group, championing cybersecurity design practices and processes across the organization. In his tenure with Benchmark, he has led software development for multiple connected medical devices. He serves as an exam developer for the NCEES engineering and ISC2 cybersecurity licensing boards. Jeridiah maintains a CSSLP certification among several other professional certifications, holds a B.S. in Computer Engineering from Kettering University, and is currently pursuing an MS in Engineering Management from Arkansas State University.

up-to-date content