[ransford]

It's good to see attention paid to the day-to-day challenges hospital IT folks face when grappling with medical devices. These folks deserve better.

As an industry of thing-makers, we've done a pretty poor job of supporting use cases involving big diverse populations of devices that aren't centrally managed. Devices don't identify themselves in any consistent way; device makers don't allocate MAC addresses predictably from their assigned ranges; security folks often don't have link-layer visibility into their own networks; and so on.

Result: hospitals are desperate to "secure" their medical devices, yet they don't know what those devices are, what patch levels they're at, or what their "baseline" behavior is supposed to be, among other things that are crucial for security.

The security industry has decided that medical devices are a special case of IoT, and you can now choose from a wide variety of AI blinky boxes to send you anomaly alerts. That has been going about as well as it does in other domains.

Two things that may help hospital tech workers in the coming years are: efforts like IETF's MUD [1] to make devices state their purpose clearly; and efforts like the NTIA's software transparency initiative [2] that are aiming to make manufacturers say what's in their devices. The FDA is also cracking the whip on medical device makers to incorporate security into their development processes, and they love comments from nerds who can help.

</soapbox>

(I am one of the academic researchers behind the defibrillator hacking [3] that inspired the Homeland episode mentioned in this article, and I've been cutting my fingers on innumerable sharp corners in hospital wiring closets on and off since then.)

[1] https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/

[2] https://www.ntia.doc.gov/SoftwareTransparency

[3] https://www.secure-medicine.org/hubfs/public/publications/ic...

[marcosdumay]

> Devices don't identify themselves in any consistent way

SNMP standardized that before sysadmins everywhere decided it was devil's reincarnation and banned all of it that they could. When working on an equivalent standard, it may be useful to think about why your standard won't suffer the same fate from the same reasons.

[FooHentai]

>SNMP standardized that before sysadmins everywhere decided it was devil's reincarnation and banned all of it that they could.

Dunno what you mean. SNMP Write is certainly a hard sell to allow, but SNMP read has been a consistently useful element of monitoring strategy across many organisations I've worked for.

V3's still a tricksy, time-sucking devil to implement ubiquitously, though.

[marcosdumay]

Information gathering is entirely in the read part of the spec.

Things have been improving, but SNMP used to break at every network bridge, no matter if any part of it was external or had any kind of difference security requirements. It was completely reliable that if you got into an organization, you wouldn't be able to communicate with anything in a different network segment, even for status messages. This was one of the obstacles for IPv6 adoption, since it used to require status messages for setting datagram sizes (I think that changed).

It looked like every sysadmin on Earth would look at SNMP, say "I don't want an attacker to have status and infrastructure information of my network", and block it. As did all network security guides on the Web.

I once worked for a company that basically had a client software that transmitted the same information of SNMP-read over HTTP. When I would go at clients I often asked their sysadmins why SNMP was blocked, they would always say "security", then I would tell them that they were buying this that was exactly the same as SNMP, and they would just say it's different somehow...