
If hackers attacked the hospital (2017) - wglb
https://www.bostonglobe.com/ideas/2017/11/10/hackers-attacked-hospital/S4NQClYCBl0B0TGpb0dEbI/story.html
======
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/](https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/)

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

[3] [https://www.secure-
medicine.org/hubfs/public/publications/ic...](https://www.secure-
medicine.org/hubfs/public/publications/icd-study.pdf)

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

------
pg_bot
I'm surprised that no one ever talks about America's e-prescribing
infrastructure getting hacked. Over 99% of all electronic prescriptions are
handled by a single company (surescripts). It's a massive single point of
failure that could cause chaos if they were no longer able to operate. Most
states are now moving to make all prescriptions electronic. It seems that not
enough people know that this is a problem, but it's also another reason why
prescriptions are more expensive than they should be.

~~~
Thriptic
Luckily most other emerging integrations (payer - provider for eligibility
checks and coverage decisions, provider - provider for real time medical
record transfers, etc) are decentralized by design with a number of large
aggregators. While it's possible for basically any company to get access to
these networks for a nominal fee and thus facilitate a transient DDOS by
flooding the network, it would be relatively easy to drop this traffic and
boot them.

Also doesn't McKesson have their own interface for electronic prescriptions or
am I incorrect?

~~~
pg_bot
You are incorrect.

[https://www.healthcareitnews.com/news/surescripts-
partners-m...](https://www.healthcareitnews.com/news/surescripts-partners-
mckesson)

------
xs
The Boston's Children's hospital was attached once by anonymous. This podcast
covers the story very well.
[https://darknetdiaries.com/episode/14](https://darknetdiaries.com/episode/14)

------
sp332
I thought this story was only 4 paragraphs long, but you have to click the
"continue reading" button to see the rest.

