FDA Calls On Medical Devicemakers To Focus On Cybersecurity 40
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."
Not the American Way (TM) (Score:2)
Isn't the normal solution to this kind of problem for those affected (or their families, since they will probably be dead) suing the manufacturer?
FFS (Score:1)
Like we need more guvmint BS pushing up prices. Look at the cost of an insulin pump, greater than $5K for what is basically a re-purposed pager shell with a syringe pump.
Re: (Score:2)
So it's about time they earned some of that $5K. It's not the government pushing the prices up, it's doctors who don't even bother to know the cost of the things they prescribe.
Government regulation does facilitate the gouging by limiting the number of competing vendors, and it should do something to prevent that side effect, but we really don't want people dropping like flies when their pumps malfunction.
Air gap the damned networks.... (Score:2)
Run an internal network with no access to the internet. Limit the internet to certain devices or terminals.
Re: (Score:1)
Which is fine - except a lot of manufactuers are wanting their devices to have Internet access to automatically download patches and data, and be remotelly accessible for maintainence. And they need to communicate with the rest of the hospital network to pass information.
Re: (Score:2)
Re: (Score:1)
Insulin pumps and glucometers, in particular, can be ...
Not just those, but cardiac implants as well, which go beyond the "pacemaker" of yesterday and include defibrillator and cardiac resync therapy, (CRT), functionality as well. Recording heart function for review is very useful. One problem with this sort of vulnerability is that some might choose to forego the device, and therefore forego a better quality of life, for fear of someone fucking with the device just for the lulz.
Re:Air gap the damned networks.... (Score:4, Interesting)
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: (Score:2)
Re: (Score:3)
Re: (Score:2)
This adds a number of significant additional risks:
It adds a delay.
It adds the risk that the human will mix records, or will fail to do the job without reporting back.
It generates confidential waste that needs to be managed.
I work a specialist hospital, which gets patients from over a wide region, including neighbouring states. The normal way of transferring X-ray/MRI/CT records is by file transfer from one hospital's server to the other. However, for hospitals which are not common "feeders", which haven't
Re: (Score:2)
Simple standard? (Score:4, Interesting)
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 [wikipedia.org], 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? (Score:4, Informative)
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: (Score:3)
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 inte
Re: (Score:3)
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: (Score:2)
Don't you mean asymmetric encryption? Symmetric encryption means it is the same key used, not a public/private key pair. However you are using it for integrity checking not confidentiality, you don't mind who can read the firmware binary, just want to make sure that is not modified in transport. Therefore it is a digital signature you want to use, not encryption.
Obvious NSA joke (Score:2)
In Soviet Russia pace makes you?
What about... (Score:1)
if I want to overclock my pacemaker? Will it stop me from installing Linux?
Obamacare partly to Blame (Score:2)
Obamacare's Medical-Device Tax Kills Patients, Not Just Jobs [forbes.com]
The 2.3 percent Obamacare excise tax on medical devices is a tax is on sales, not profits.
Patch cycles (Score:2)
Re: (Score:2)
Re: (Score:2)
Many device manufacturers use Linux or Windows as an underlying OS as both have a lot of support form development tools and are widely used. This means that a lot of work has been poured into the OS to make it a lot more secure than some home brew system. On the other hand it also means that all vulnerability in the OS also apply to the device. As long as the device was sealed, this was no problem, but once users want to get data from the device, or even get it to interact with various internet-based servic
Re: (Score:3)
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 pro
Re: (Score:2)
What does grampa have to hide, anyway? (Score:1)
"Seal the holes!" screamed the FDA. "Just not this one, and that one, and that one, which the FBI, CIA, and NSA use."
Treat them like a DMZ (Score:2)
I did a bunch of work a number of years back where we had critical (financial services not medical) computers that we absolutely were not allowed to patch. The solution I implemented was to treat any computer that can't be patched as a mini-DMZ.
The computer is firewalled from the rest of the network, put on a locked down VLAN and given only specific destinations, ports and so on as required in order to function. The concept of least privilege can and should be used for computers like this just as you would
More Inefficiency (Score:2)
And the solution is .. (Score:2)