FDA Calls On Medical Devicemakers To Focus On Cybersecurity

alphadogg writes "Medical device makers should take new steps to protect their products from malware and cyberattacks or face the possibility that U.S. Food and Drug Administration won't approve their devices for use, the FDA said. The FDA issued new cybersecurity recommendations for medical devices on Thursday, following reports that some devices have been compromised. Recent vulnerabilities involving Philips fetal monitors and in Oracle software used in body fluid analysis machines are among the incidents that prompted the FDA to issue the recommendations."

Comments

Simple standard?

[Okian Warrior]

Network security is an add-on, largely viewed as an externality by corporations.

I think that it's largely because of this (and that mostly due to Microsoft) that people don't use good security features.

Suppose the socket layer had a function to generate a key pair, and a function call to set the key used for encoding and decoding. (Possibly a bit in the protocol to send a message using or not-using encryption). If it was that simple most products would use it, certainly safety-certified products would use it.

(There's Transport Layer Security, but it's not really simple to use.)

Since there is no simple universal way to use good security, everyone ends up having to implement their own version, which costs time and money.

Simple secure communications should be an OS feature.

Re:Simple standard?

[Darinbob]

I suspect most of these devices have either minimal operating systems, home grown operating systems, or no operating system at all. Even if security is in the network stack it doesn't fix things. Ie, do you require your hospital to run IPsec everywhere for every device? Having a top of the line IPsec enabled networking doesn't prevent hacking things if there are bugs due to injecting packets of the right type (ie, it isn't breaking through security to read data, but it is crashing the machine or corrupting data).

The other thing is that when these machines are hacked it is very often due to reverse engineering the machines. These don't run windows or linux, there's no pre-built hacker kit available, the attackers have access to actual machines and have cracked them open, read the flash or monitored the bus to figure out what the software is doing or what style of OS it has, scanned through to find out if there's a recognizable file system type, etc. When you're up against sophisticated attacks like that then your builtin OS security isn't going to be much defense.

I suspect most of these successful attacks are happening on machines that use Windows internally; ie, an app on a turnkey system, or Windows bolted onto the side of a device to provide a front end. But Windows already has a built in securre communication feature.

Re:Simple standard?

[Okian Warrior]

You're correct in that the programs should be tolerant of bad data, and much of the safety certification process addresses this issue. For example, as part of the certification process you need to show that buffer overflows cannot happen, that all cases of input data are covered (bad data is handled gracefully), and so on.

I believe the original article was referring to data transfer and firmware upgrades. These would be conveniently handled over the internet, if only we could guarantee the security and integrity of the data. This means that no one can snoop the data or synthesize false data.

The other thing is that when these machines are hacked it is very often due to reverse engineering the machines. These don't run windows or linux, there's no pre-built hacker kit available, the attackers have access to actual machines and have cracked them open, read the flash or monitored the bus to figure out what the software is doing or what style of OS it has, scanned through to find out if there's a recognizable file system type, etc.

Symmetric encryption handles this situation. If the private key is held by the company, the device can refuse firmware upgrade requests not correctly decrypted by the public key held in the device NVRAM. It does the attacker no good to discover the public key - without the private key, they still cannot form a correctly-encrypted upgrade command.

A similar situation exists for the device/recorder interface. If there were a symmetric key pair for each monitor/recorder, the hackers could only reverse-engineer the keys for each device they take apart. You could even use the "Sears Garage Door Opener" model where a monitor is brought near the logger, press the "learn" button on both machines, key exchange happens, and now the logger and monitor are linked and using secure communications.

(Some may balk at having a per-device key, but note that medical devices often have a per-device stored serial number.)

True security, and privacy, and the solution to a lot of the ills of the world we're seeing right now, is actually straightforward. We only lack the will to implement it.

For example, SMTP has "experimental" protocol headers (X-something). Way back before Google mail existed, the Mozilla mail reader was popular. If the designers had implemented a checkbox "keep message private if possible" which would handle key discovery and key logging between senders and recipients, and a green checked circle "this message is private" when a key exists between recipients, it would have been popular, causing other mail systems to implement it in order to be competitive. (No need to actually *store* mail encrypted, just encrypting the channel would bring an enormous boost to privacy.)

As it happened the designers didn't take that step, Google mail is now the popular model, and the government (and Google) reads all our mail.

(Compare with the current Mozilla policy on "do not track" (we'll implement it, but leave it off by default), or ask them whether the features of "ssh everywhere" or "ghostery" should be bundled with the system.)

Re:Simple standard?

[Darinbob]

The devices I worked on in the past had protection in firmware and such. The goal however was to protect against competitors and unauthorized resellers, not random hackers. Ie, trying to crack down on the second hand market where they try to clone the firmware and try to resell old machines as new or to sell license features they haven't paid for. Firmware wasn't encrypted in this case but is definitely signed. Encrypting doesn't help much if the attacker has access to the bus.

Re:Air gap the damned networks....

[Relic of the Future]

Since I helped write a system that pulled live data from medical devices (during surgery) to update patient records on the fly, and that, eventually, those records have to be sent to someone else (using the internet): No. You can't just run an internal network with no access to the internet.

Build layers of security. Don't use hard-wired passwords. I.e., Stop being stupid about security. But no, you can't just air gap.

Re:Patch cycles

[ChumpusRex2003]

The problem with implantable devices is that they are severely power constrained, as typically a battery life of less than 5 years is considered unacceptable, with 10 years wanted for something like a cardiac pacemaker.

This leaves very little power for CPU/communications/encryption functions. Any kind of crypto hardware, or any kind of unnecessary complexity in the firmware (e.g. duplicated bound checking, etc.) is likely to increase energy consumption and shorten battery life.

This is becoming less of a problem with modern silicon which is more power efficient, and the use of NFC and induction coils can support the energy required for communication; so there is less excuse for including some form of well designed security on the device.

I have managed to reboot an implanted nerve stimulator once, by scanning the patient it was implanted in, in a top-end 3 Tesla MRI scanner. Interestingly, everything other than program code, was stored in RAM, rather than flash (including stuff like serial numbers, electronically readable model number!!, as well as treatment parameters). After the device rebooted all these settings were lost. The manufacturer had anticipated this, and the MRI instructions for the device, specifically said that these must be read-out of the device and a hard copy made, with instructions to how reprogram the device if it did reboot.

There are different constrants with non-implanted devices (e.g. laboratory equipment, scanners, servers, etc.) Traditionally, all the specifications for these devices were made at the time when they would be connected a clean, isolated network. As a result, security has been a very, very late arrival to these specifications. TLS support was ratified into the DICOM specification a few years ago (storage and transmission of X-ray/CT/MRI,etc) - but I've never come across a DICOM TLS installation in the field. So little installed software supports it, and the replacement cycle is so long (many hospitals are signing 10 year contracts for a particular version of the software) that it is, at present, completely useless. Even basic level network security is made difficult by certain aspects of the protocol - e.g. DICOM network connections cannot traverse NAT (due to a classic-FTP-like protocol for initiating file transfers, and due to the fact that both client and server nodes must be on pre-configured static IPs) and has enough tricks up its sleeve that it will catch out unwary net admins when they try and configure firewall permissions, or unwary sysadmins who try and set up clustered servers

Re:Doesn't work.

[saleenS281]

This EXACT scenario occurs today in many organizations and it works just fine. You act as though this were an impossible feat prior to the invention of networking and that's just not true.