In-brief: a new publication by IEEE lays out a “building code” for medical device makers to help address security and privacy issues in products.
Software insecurity in medical device hardware and software is an acute issue, with security researchers warning of widespread vulnerabilities and weak configuration that could render clinical environments and even patients vulnerable to malicious attack.
Still, improving the quality of medical devices is akin to boiling the ocean, given the involvement of so many players – from medical device firms to their customers: hospitals and clinical networks, to federal regulators like the Food and Drug Administration.
Now the IEEE and the National Science Foundation are proposing a set of standards – which they liken to a “building code” – for connected health products. The codes, which govern everything from software updates to application design to protections against attack, are laid out in a new proposal, published by the IEEE.
The document, “Building Code for Medical Device Software Security” was released for public review this week.
Citing the example of building codes which, since ancient times, have led to the construction of safe and sound living structures, the report lays out a similar set of broad standards that would govern the creation of applications for use in the medical setting.
The authors, Tom Haigh of Adventium Labs and Carl Landwehr of George Washington University, said the goal was to ensure that the “bricks” of future medical devices was sound, while avoiding prescriptions about what the “architecture” of those devices might be.
The report casts a broad net in defining “medical device,” also. Everything from implantable and wearable health management devices to large scale diagnostic machines (like MRIs) to electronic health record (EHR) systems were included.
The report proposes specific actions up and down the medical device software stack. Attention must be given to preventing memory-based exploits like buffer overflow and use-after-free errors. Application code should be designed and written following secure coding best practices. In addition, code should be scanned and analyzed for vulnerabilities, with proper resources given over to fixing issues that are identified.
In deployment, companies should require digitally signed firmware updates. And organizations should deploy technologies like application whitelisting and ‘user least privilege’ policies to limit the attack surface around medical devices.
The security of health devices has become a serious issue. The FDA issued its first ever Safety Communication specifically targeted at software vulnerabilities last week. The agency warned hospitals and doctors offices of vulnerabilities that would allow an attacker to “access the pump remotely and modify the dosage it delivers, which could lead to over- or under-infusion of critical therapies.”
That advisory follows a warning by the Department of Homeland Security in April. DHS’s Industrial Control System Computer Emergency Response Team (ICS-CERT) warned of drug infusion pump management software sold by Hospira contains serious and exploitable vulnerabilities that could be used to remotely take control of the devices.
In October, the FDA issued guidance for manufacturers to address cyber security issues in the design of connected medical devices. That document, “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices,” asks device makers to submit documentation to the FDA about any “risks identified and controls in place to mitigate those risks” in medical devices. The guidance also recommends that manufacturers submit documentation of plans for patching and updating the operating systems and medical software that devices run.