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.

Re: This is good

[Anonymous Coward]

Wish i had known that before i bought those piece of shit dr. dre beats headphones.

Something to look forward to...

[fuzzyfuzzyfungus]

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...

Re:

[Joe_Dragon]

just hope they are not running MS software on there as there EULA not for use in Medical Devices

Re:

[Anonymous Coward]

Maybe you can upgrade to a wired version and have a UTP cable run out your ass?

Re:

[Smerta]

Presumably Jay Radcliffe's research [bloomberg.com] is old news to you, correct? If not, I'd take a quick look-see [blackhat.com]...

Oh great.

[Ihlosi]

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.

Re:Oh great.

[necro81]

If you are making a medical device where there is the potential for someone to hack the software or communications, resulting in death or serious injury, then yes, you do. No sense in whinging about it - that's the reality of the world. Computers get hacked, and that can have serious consequences, so you'd better examine the risk and mitigate it. This is nothing new, especially on /.

If anything, you should be asking yourself: if the FDA is only now issuing this guidance, and you haven't already been worried about security in your devices, how far behind are you?

Re:

[frank_adrian314159]

If anything, you should be asking yourself: if the FDA is only now issuing this guidance, and you haven't already been worried about security in your devices, how far behind are you?

If anything, we should all be asking ourselves where the secure OS'es (and, by this, I mean as verifiably secure as we can make them, via proof, extraordinary levels of test, etc., to the point where they can be insured for a relatively small amount of money) and languages that we can use to build secure systems? Not to mention

Re:

[DoofusOfDeath]

buggy compilers, incompletely documented hardware and similar issues

Well yes, as the husband of someone who wears an insulin pump, I do expect you to get your shit together before shipping the product. And considering how much we pay for these pumps and sensors, I think it's reasonable for you to demand properly documented hardware and correct compilers from your suppliers.

I also need to consider cryptography.

OR... you could stop trying to make medical devices that try to be part of the Internet of Things

Are these going to need backdoors also?

[Nyder]

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?

Re:

[Nyder]

flamebait? I was going for funny, sheesh, no sense of humor anymore...

Re:

[Feneric]

They never have before, and in fact the FDA would actually consider the existence of such a backdoor a risk that'd have to be evaluated as part of the process.

Already Tracking Cybersecurity

[Feneric]

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.

Use of "Cyber" strongly indicates incompetence

[gweihir]

That term is only used by people without a clue. Professionals call this "IT security" or sometimes "ICT security".

Signed by whom?

[tepples]

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?

Re: Signed by whom?

[bassman2k]

Absolutely 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. Only the manufacturer can do that.

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).

User control of devices, more generally

[tepples]

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 ga