The ability to remotely view, configure, and / or control any modern medical device in today's interconnected world is taken for granted -- a device not having such capabilities right now might put the vendor at a great competitive disadvantage.
This added convenience, however, has been subject to well publicized successful remote penetration attempts with scary consequences. To quote an article in Wired Magazine:
"In a study spanning two years, Erven and his team found drug infusion pumps – for delivering morphine drips, chemotherapy and antibiotics – that can be remotely manipulated to change the dosage doled out to patients; Bluetooth-enabled defibrillators that can be manipulated to deliver random shocks to a patient’s heart or prevent a medically needed shock from occurring; X-rays that can be accessed by outsiders lurking on a hospital’s network; temperature settings on refrigerators storing blood and drugs that can be reset, causing spoilage; and digital medical records that can be altered to cause physicians to misdiagnose, prescribe the wrong drugs or administer unwarranted care."
Regulators have long recognized the potential exposure to IT-specific vulnerabilities in an medical device which includes such IT technologies, and have provided guidance on how to apply the existing risk assessment and risk management components of the regulatory frameworks to cybersecurity. This is all nice, however complying with the provisions of the regulatory frameworks themselves are not sufficient to ensure that the actual device, as part of an interconnected system, is immune to such attacks.
Additionally, most vendors have responded to some of these reports by implementing seemingly secure solutions based on off-the-shelf technologies, one of the most popular being the use of SSL to encrypt the communication between the device and a remote client or server. To the uninitiated, SSL seems to be a secure way to connect. All banks are using this, right?
The devil is in the details, however. There are 6 flavors of SSL in use today (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2, with TLS 1.3 coming out soon). Only 2 of these flavors currently in use (TLS 1.1 and TLS 1.2) are currently not compromised; all the other ones can be penetrated today by using well publicized exploits. Moreover, some of the cyphers available for each of these are compromised as well. And if the device is based on the open source library OpenSSL 1.0+ (which most of them seem to be nowadays), it is vulnerable to an external penetration attack unless its heartbeat capability is disabled by a patch. Very few vendors, however, have the sophistication needed to recognize all these nuances -- and even if they do, the willingness to incur the cost of implementing a fully secure solution.
Moreover, with the possible exception of FIPS 140-2 applicable to procurement by the federal government, there are no certification standards applicable to medical devices to ensure that they are cybersecure -- like there are for electrical safety and electromagnetic compatibility testing (UL, CE), fluid ingress, shock and vibration, etc. It is up to the vendor to define what compliance with cybersecurity regulation means. In some extreme cases, that is only a statement based on a superficial risk analysis outcome that the risk of a cybersecurity attack on the device is believed to be negligible ("who would want to hack into our device and why?"), so no cybersecurity countermeasures are needed. In the best of cases, the use of SSL for encryption and the use of a [well known] default password are deemed sufficient (or is it?) So how can we know?
A good start would be to ask the vendor to fill out use-mode specific cybersecurity checklists as part of the procurement process of medical devices. This checklists would have to be detailed enough to include details such as encryption protocols and cyphers supported and / or blocked, list of open and blocked ports, multi-factor security (possibly using biometrics and / or X.509 certificates), password complexity / expiration / history enforcement, role-based security, security logs and alerts, intrusion detection and prevention mechanisms, digitally signed updates, anti-malware, vulnerability monitoring, containment and rapid response policies, statements of immunity to well known exploits like Heartbleed, BEAST. POODLE, etc.
What do you think?
