The intersection between security and medicine is a strange place. While it has created many benefits to patients and healthcare professionals, it has also raised issues that both medical and security professionals have never even considered. On the positive side, patients are directly benefiting from automation replacing manual processes through a wide range of connected devices. They are also benefiting from increased availability of their data for self-management, as well as access to historical monitoring data through the internet. Integration of consumer technologies like mobile phones means that patients and caregivers alike can have on demand access to data and use that information to make informed decisions. All of these items are intended to increase the quality of care for patients. However, the increased reliance on the internet and use of various connected devices, including mobile phones, present significant security concerns. Recent articles on cybersecurity issues related to pacemakers and defibrillators highlight how security can take front and centre in the media. Even if safety concern is not present, events like this can still cause concern and worry among patients, and in the worst case scenario, patients may even decide to forego beneficial therapies because of a potential security risk.
Another item that can be particularly challenging, is to design adequate security while maintaining usability. Some aspects of usability are driven by the patient population that will be using the device. For example, an older patient population has a different foundation for using technology than a younger one, and a system that is usable by younger patients may not be usable by older patients. One example of the intersection of security and usability is provided by passwords. Password-based systems have technical security controls that can provide the necessary security, but only under certain conditions that are directly influenced by the person selecting the password. This is the reason that web sites ask for passwords of a certain length, with numbers, letters and special characters.
From a security perspective, very long and completely random passwords offer the best protection. But those are difficult to remember and are therefore not very usable. Password managers allow storage and retrieval of long, random passwords so that a user does not need to remember their password. Security experts consider use of a password manager a requirement for people to securely use any password-based system. That presents a problem however, because medical devices often do not allow users to install additional software like a password manager. The result is that users will use a weak password, which can be easily guessed, circumventing all the security controls within the system. Finding the appropriate balance in this type of problem is essential to maintaining both usability and security. The patient population, use scenarios, and use environment all affect the kinds of security controls that are reasonable.
Connected medical devices typify this issue. On August 30, 2017, the FDA published a Safety Communication noting that patients using any of six specific pacemaker and CRT-P (cardiac resynchronization therapy pacemaker) devices should consider applying a software update to fix the security holes. The security patch release by the FDA demonstrates some of the difficulties for connected medical devices. Among those difficulties are the tension between safety and security, the ability of patients and doctors to evaluate security risk, and the long product release cycles required for medical devices.
The security patch was released to fix a hardcoded unlock code present for enabling emergency care. This showcases the tension that exists between safety and security of the implanted device. Medical devices often need to have functionality that supports delivery of emergency care so that patients can obtain potentially life-saving therapy when necessary. However, that same emergency use case contributes to security risks that could potentially be exploited to cause harm. Balancing this kind of tension during product development is essential, and provides an exemplar scenario for why security needs to be driven from a comprehensive, program level initiative such as those observed through the BSIMM study.
Overall, medical products fundamentally provide benefits to patients while also introducing risks. Some of the most familiar of risks are called out as side effects of prescription drugs. Take cough medicine as an example. The same drug that reduces coughing may cause extreme drowsiness in a small per cent of the population. Surgical procedures are something familiar where doctors talk with patients about the benefit of the surgery, but also about potential risks, such as infection. These risks can sometimes be very serious, but their rate of occurrence is very small. In these examples, the risk-benefit discussion between patients and their doctors are informed by scientific studies categorising the risks as a percentage of people who experience the risks. Most people can grasp the concept of ‘1 out of 1,000 people experience extreme drowsiness’ and are able to make an informed decision around that. However, that kind of data isn’t present in security vulnerabilities, and because of that the risk-benefit discussion between patients and their doctors is not based on empirical evidence, and an alternate means of communicating the risks and benefits needs be used.
The significant length of time required for a patch to be released is typical in the medical device industry. While the FDA has noted releases strictly for security vulnerabilities will not be subject to the same regulatory process, it is still the responsibility of the manufacturer to ensure that any change to their system is safe and effective. In other words, the software patch that is deployed still needs to go through a rigorous process of analysis, development, verification and validation to ensure that it is operating as intended and not introducing new risks. The recent Meltdown and Spectre vulnerabilities are a great example of how patches may have adverse performance impacts (as much as 30 per cent), and manufacturers need to perform the necessary testing to ensure all patches work appropriately.
Medical device security is fundamentally about risk identification and reduction. Manufacturers need to be incorporating security risk management processes throughout their entire development lifecycle in a similar manner to how they have incorporated safety risk management. This means performing activities such as architectural risk analysis, threat modeling, automated code reviews, and security-focused testing activities.
This is an issue that is broadly about healthcare and security as much as it is about patching individual devices.
If you’re downloading a medical focused app, there is a significant probability that your data is going to be available for uses that you may not be aware of. Even encryption, which in the medical space should be a must-have before going to market, is missing from a large portion of apps. Consumers should understand that to get the benefit of some of the mobile medical apps, they will be losing control of their private health data.
Additionally, imagine a situation where the data you unknowingly submit through a mobile application is used to link your biologic information to a potential medical disease. Should that information be communicated to you? How should it be presented? Did you even want to know if you were trending towards something that may not happen?
To conclude, security can be an enabler of new healthcare models that can deliver great benefits to patients, but it also remains a source of major concerns. For patients to fully benefit, security must become a top concern for healthcare organisations.
You're the expert! Write for The Engine or share your articles, papers and researchAdd your content
Add your content
Sign up for Ignition, our regular, ideas-packed newsletter