Slashdot Mirror
FDA Issues Guidance On Cybersecurity of Medical Devices
chicksdaddy writes "The Security Ledger reports that the U.S. Food and Drug Administration (FDA) has issued final guidance on Wednesday that calls on medical device manufacturers to consider cyber security risks as part of the design and development of devices. The document, "Content of Premarket Submissions for Management of Cybersecurity in Medical Devices," asks device makers seeking FDA approval of medical devices to disclose any "risks identified and controls in place to mitigate those risks" in medical devices. The guidance also recommends that manufacturers submit documentation of plans for patching and updating the operating systems and medical software that devices run. While the guidance does not have the force of a mandate, it does put medical device makers on notice that FDA approval of their device will hinge on a consideration of cyber risks alongside other kinds of issues that may affect the functioning of the device. Among other things, medical device makers are asked to avoid worst-practices like 'hardcoded' passwords and use strong (multi-factor) authentication to restrict access to devices. Device makers are also urged to restrict software and firmware updates to authenticated (signed) code and to secure inbound and outbound communications and data transfers.
I don't need some pranksters deciding to play Flatliners on me.
If the bored hacker with the killer app doesn't get you, you'll learn the hard way that violating the EULA and losing your license to operate a copy of the software really gets personal when that software is substituting for some organ system rathr than an external function...
As someone who relies on an insulin pump, which is accessible wirelessly, I wonder about this kind of thing. I'm planning on getting a lead pouch soon.
Ransomware is installed to give you a permanent erection. Pay up or your penis will inflate until it bursts like a balloon. This is going to be messy. (Recruiting malware coders now for female edition. Killer cramps will kill you for real. Your period will bleed you to death, period. As soon as the coders are done coding.)
Now, in addition to dealing with measuring voltages in the sub-millivolt range, buggy compilers, incompletely documented hardware and similar issues, I also need to consider cryptography.
Is the Government, FBI, NSA, etc going to demand a backdoor into these devices so they can be able to scan them for info in case terrorist or child pornographers are hiding info there?
Be seeing you...
As someone who has released network-capable medical products professionally, I can say that the FDA has already been requiring companies to provide all this information anyway. All that's new here is that there's now a final guidance in place that means less guesswork in trying to determine exactly what information they care about and what format to provide it in.
That term is only used by people without a clue. Professionals call this "IT security" or sometimes "ICT security".
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Device makers are also urged to restrict software and firmware updates to authenticated (signed) code and to secure inbound and outbound communications and data transfers.
Should the patient be in control of the choice of certificate through which the signatures are verified? If not, why not?
The patient does not have the skills, knowledge of the device's internal hardware/firmware/software design, testing tools, or the time to make sure an update is safe and won't break the device.
Do you intend this reasoning to apply only narrowly to medical devices, more broadly to all electronic devices, or something in the middle? And even in the field of medical devices, do you intend to exclude a third party from being able to refurbish a medical device that has reached end of support with updated firmware and get this new firmware approved?
Besides, "signed" doesn't necessarily mean the same certificate-based chain-of-trust process that most people are familiar with. It could be much simpler (and usually is for firmware or software on embedded devices).
I was using "certificate" more broadly to refer to any data structure including a public key against which a message's authenticity is verified. In video game consoles, for example, this certificate is hardcoded at certain levels of the boot process.