Hacking Medical Devices

A Cause for Insomnia

Imagine you are on a hospital bed attached to devices and sensors that a malintent individual across the world can digitally find and manipulate. This is a nightmare scenario. By some accounts, a typical intensive care bed has more than a dozen sensors, most of which are network connected, and at least few of them are connected to the Internet. 

These Internet-connected devices are constantly being probed for weaknesses, and nefarious characters are usually few steps ahead of security protocols (laughing at the very concept of regulations). 

To understand the scope of the challenge, we need to recognize the nature of healthcare and medical device industry. In general, the healthcare system is a conservative industry that is extremely resistant to change. Compound this with myriad regulations and bureaucratic red tape, and the word “security” conjures up a headache. 

Three distinct problematic situations can arise from security lapses in medical devices. First, if a medical device cannot perform the service it was designed for, or is operated outside the designed range, the safety of patients will clearly be in jeopardy. Second, a breach of privacy may expose confidential records to iniquitous actors with a wide range of aims. Incidentally the latter is well-covered in the U.S. by the HIPAA regulation, however, regulators did not address the root causes for most common privacy failures. And finally, data loss can cause the ripple effect of major service interruptions where fallback mechanisms such as data redundancy are not in place. 

A likely scenario for a financially motivated antagonist is the digital hostage-taking called ransomware, which denies access to mission-critical data while demanding untraceable bit-coin payment for restoration. This is not a new concept, in fact, Forbes magazine warned about this focus on the medical industry more than a year ago, and risk managers in Europe recognized this vulnerability well before the FDA took any steps.

Recent ransomware cases have caused concern and panic in the medical field. There is a real cause for concern as the most likely scenario for the health industry is a service-oriented ransomware breach. 

Robust Response Lacking
What if the government and industry were to work together to address these issues? This is a huge IF to say the least. Until now, the response to these challenges has been weak and sporadic. The U.S. Food and Drug Administration (FDA) began to consider the security of medical devices back in 2013 and has kept updating its list of recommendations and requirements. The National Institute of Standards and Technology (NIST) approach is arguably more actionable but, as expected, the collaboration between the two agencies has been suboptimal. 

The FDA focus is on sharing vulnerable data, yet falls short of establishing more than a voluntary security framework. 

The biggest problem with its lukewarm recommendations that medical device manufacturers incorporate security mechanisms in their products is that there are no FDA specifications or standards that must be met. This leaves the door wide open for interpretation and allows device manufacturers to define their own level of “sufficient security” steps. Given that few vendors really understand the complexity of cybersecurity today, the FDA’s subjective stance will only add to the confusion.

FDA regulators are not security experts and, to a degree, operate in a silo devoid of industry experiences. A better approach is requiring system-wide security at healthcare facilities coupled with embedded security in each medical device. FDA can demand the medical device builders show proof of best security design and practices as a part of its Product Development Lifecycle (PDLC) plan. 

By issuing clear, unambiguous standards, the FDA would be able to force the implementation of secure medical devices. By finding manufacturers liable in lawsuits brought by service providers, the courts could also play a key role in public safety.

The European Union attempted to tackle the issue of medical device security years before FDA. However, that approach was to retrofit standard IT rules to the medical device industry while giving manufactures a great degree of discretion in defining an acceptable risk threshold. As a result, we are dealing with a set of so-called guidelines that lack cohesion and normalization. 

On the other hand, the security industry has offered piecemeal solutions that reflect its own fragmentation. Some vendors offer boutique approaches like deception tools (using honeypots and decoy systems) to “fool” the attackers. These solutions lack imagination because a sophisticated attacker can readily circumvent these defenses by simply targeting all vulnerable (not just the easiest) devices. 

What are Reasonable Steps?
The question then, is what would be the reasonable security taxonomy for design and operation of medical devices? As far as medical device development is concerned, security must be an embedded element, not an afterthought. Gartner recommends that organizations “make application self-protection a new investment priority, ahead of perimeter and infrastructure protection.” That means addressing the potential weaknesses of firmware and software that run in medical devices. 

Both static and dynamic code analysis offer systemic and deep security posture checks with a high probability of discovering exceptional operational failures. Intelligent fuzzing techniques can test even theoretically hardened devices and expose deficiencies. Once the systems are deployed in the fields, a robust operational model must take control to ensure reasonable network security. Not all medical devices need Internet connectivity or direct user input; operators can make certain that their deployment cases are security-justified. 

Like other mission-critical networks, medical systems must separate the control (management) plane from the data (operational) plane, and avoid cross-contamination in the event of a security breach in either domain. 

Despite all steps, and knowing that security is not fool-proof, a comprehensive risk-based approach as an overall operational management philosophy is paramount. Security policies must consider both mitigation as well as residual risk measures. DevOps must concatenate risk mitigation assertions in the risk assessment policy to make sure each procedure or control that is stated in the risk assessment has a relevant metric contained in the policy. Residual risks (what a mitigation can miss) should also be dovetailed into the deployment model as an exceptional metric. Moreover, any viable vulnerability assessment must be sorted by descending score on mitigated risk and priority control if it is to objectively determine which controls are more important to audit and confirm their efficacy. As the final step, DevOps must also perform gap analysis to provide protections and safeguards for remediation of risks.

Whitelisting is another effective tool in preventing rouge applications from running in medical services networks. Whitelisting partially addresses the challenges with authentication failures and authorization tools – but it is not a cure-all. 

It is noteworthy to also mention the externalization of IT, which is closely linked to cloud computing. Without hardening medical devices and services, it would be unwise to embrace the model given its pitfalls and uncertainties. 

Let’s get the terminology right; many in the industry refer to a breach as a hack. While hacking is not uncommon, it normally requires sophisticated manipulation of security controls to gain access to critical data or assume unauthorized control of devices. A breach, on the other hand, is more descriptive of common security failures that we witness today. Any hack is a breach but not every breach is a hack. 

___
Hamid Karimi is the VP of business development at Beyond Security, a provider for automated security testing solutions including vulnerability management, based in California. For the past 15 years, he has focussed exclusively on the security space – covering diverse areas of cryptography, authentication, vulnerability management, malware threats, and cloud and network protection.