Hacking pacemakers and insulin pumps is mostly hype; thankfully the scary stories are just that, scary possibilities that could supposedly happen if attackers were to target vulnerable devices. Some people have called it names that are worse than hype. Nevertheless we continue to hear about cybersecurity risks to medical devices as no one wants the problem to move from potential threat to hacked fact.
Last week, researchers suggested that hackers could target vulnerable software in artificial pancreas systems with malware, spyware or even manipulate the device. In April, Wired reported on security holes in drug infusion pumps, flaws that hackers could exploit to raise the “allowable upper limit for a given drug.” Last October, DHS begin investigating 24 cases of potentially deadly cybersecurity flaws in medical devices and hospital equipment.
Today the IEEE Cybersecurity Initiative released “Building Code for Medical Device Software Security.”
The set of guidelines are meant to help companies “establish a secure baseline for software development and production practices of medical devices.” The code applies to software which runs in a wide range of medical devices.
“Similar to building codes that were developed over centuries to guide the production of physical buildings, the elements contained in Building Code for Medical Device Software Security are intended as the beginning of a model code for software security for the medical device industry,” said Carl Landwehr, IEEE Fellow and Research Scientist, Cyber Security Policy and Research Institute at George Washington University.
According to the "building code" document:
The present code focuses on the creation of software that is difficult to subvert through malicious inputs or errors in cryptographic functions. It does not address other security functions—for example, authentication, authorization, and auditing (although security logging is included).
“There are many different types of medical (and more broadly, healthcare) computing devices, including implantable and wearable, as well as hospital bedside and large diagnostic equipment. These device types have different computing capacities and energy sources,” the guidelines state before adding that a mature building code in the future might include variations of the code depending upon device type, capabilities and operating environments; for now that is considered “beyond the scope” of the code presented.
The “building code” for medical device software security was put together last November by 40 experts with diverse backgrounds in healthcare, medical devices, software engineering, development and security. According to the guidelines (pdf) released today:
The aim in specifying this code is not to assure that future medical devices can resist every imaginable attack, but rather to establish a consensus among experts in medical devices, cybersecurity, and computer science on a reasonable model code for the industry to apply. Metaphorically, the aim is to specify the needed properties of the bricks used to build the structure, not its architecture. The reason for focusing on the “bricks” at this time is that the majority of vulnerabilities actually exploited in cyberattacks are errors in implementation rather than design. By focusing on the desired implementation properties, this code aims to ensure that these bricks are indeed sound in that they are free of most vulnerabilities currently exploited.
Portions of the guidelines address specific elements such as assuring the proper use of cryptography and the integrity of firmware updates. Security event logging is an example listed under code elements which are intended to enable detection and attribution of an attack. The least-privilege principle is one of the recommendations under code elements meant to impede attacker analysis or exploitation.
Examples of elements that assure software integrity yet do not remove code flaws include digitally signed firmware, updating software without allowing fraudulent updates to be installed by validating encrypted checksum via a trusted path, and whitelisting “to avoid execution of untrustworthy, possibly malicious applications.”
However there are no code proposals under elements to support privacy requirements, to assist in safe degradation of function during attack, or to assist in restoration of function after attack as these are all "design" considerations.
“This is just a starting point that developers can use to rule out the most commonly exploited classes of software vulnerabilities during the implementation phase,” Landwehr added. “There is more work to do, so we encourage the industry to participate in our effort to create a foundation for a more complete code for the medical device industry to apply.”