Medical device security: Building it in or bolting it on?
Making connected healthcare devices safer requires building security into medical devices during development, not bolting it on later or relying on patches.
Medical device security is making strides. However, one area that isn’t being addressed is patching. A webinar I attended described a hospital which performed a reconnaissance of their network and found several hundred Windows XP machines. There was no service pack revision; these machines were running the initial release of Windows XP. The medical device manufacturers claimed the systems could not be updated. The National Vulnerability Database reveals Windows XP associated with 1078 CVEs. This is a problem that isn’t going away anytime soon because of the life cycle of medical devices.
Improving security of wireless infusion pumps
NIST recently announced a project through the National Cybersecurity Center of Excellence (NCCoE) that is designed to improve security across wireless infusion pumps. However, the effort is overly focused on an off-the-shelf technology approach. Unfortunately, that limits the ability to influence the actual medical device itself, which is the asset to be protected. The scope excludes security patches or product updates, areas that have consistently plagued the medical device industry. The current effort is essentially wrapping the medical device in a series of traditional IT network security controls. This reflects the industry’s current state of maturity, and while there are some benefits, medical devices need a more comprehensive approach. To truly be effective you have to start from the beginning with design inputs and continue throughout the product development processes, including operational support like patches and updates.
Economic considerations prevent manufacturers from releasing security patches or updates
One particularly troublesome statement in the NCCoE document, states that economic considerations prevent manufacturers from releasing security patches or updates in part due to full-testing being required. While economics will always be a constraint they should never be used as an excuse to ignore the problem of providing long term support for medical devices. Manufacturers should be cognizant of and responsible for the updateability of their devices, and should design processes and systems capable of efficient updates. NCCoE’s effort isn’t helping this problem.
Addressing the problem
One way the problem can be addressed is through architecture. If a manufacturer is building a device on a mainline operating system that is frequently patched, then that device is dependent upon that operating system and should be designed for the inevitable release of patches. Another approach could be to choose a more robust operating system designed for safety-critical environments like avionics. Certainly embedded OS’s can have vulnerabilities and need to be assessed. A quick search on the NVD for QNX results in 38 CVE’s and VxWorks returns 23. The numbers are significantly less than Windows XP in part because they have not received the same level of adversarial pressure, but it is also likely that there are fewer vulnerabilities to be found.
In the event a patch is released I don’t believe full-testing is required. The FDA states in their guidance document that updates for cyber security typically will not need review or approval, but the manufacturer must still ensure the safety and efficacy of the device. In that respect a security patch is no different than a new feature update. But to say that full testing is always required just isn’t true. Regression testing is done all the time in software development and medical devices are no different. A system designed to support regression analysis and testing could greatly reduce the burden associated with verification and validation of security patches.
If NCCoE’s effort were to include the issue of patching in the procurement phase, perhaps more change could be achieved. HIMSS created a questionnaire for application security which uses the concept and asks if vendors will provide patches. However, this stops short of a contractual agreement.
Summing it up
As medical devices and consumer technologies converge, patching is an increasingly important aspect for maintaining security of the system and the expectations of the buyer should be addressed during the initial purchase. If questions focused on the security features and secure development life cycle are asked by those purchasing the device, and subsequent purchasing decisions and contracts are used to enforce expectations and needs, the manufacturers will respond.
Security needs to be driven into the processes used to create the medical device and not built around the device. Change happens slowly in medical devices but the sooner customers start using the medical device development process as a part of their purchasing criteria, the sooner that change will happen.
