Um, excuse me. Do you have clearance to patch that MRI scanner? Healthcare regulations oblige medical equipment vendors to focus on developing the next generation of technologies rather than addressing current cybersecurity issues, according to experts presenting at the eighth Israel Cyber Week. Ophir Zilbiger, partner and head of the BDO Cybersecurity Center Israel consultancy, said …
Very true, but as always the problem is the same: money and convenience.
Some hospital staff need external internet access, and also internal. But no one will do a red/blue network and separate terminals for air-gapping it, or even a properly thought out system on common networking to have logically separate VLANs, white listed web sites, strongly sandboxed applications, etc, etc, because they already have a running and generally working system and don't want / can't tolerate the disruption of a massive overhaul.
"they...don't want / can't tolerate the disruption of a massive overhaul."
It needs to be presented to them in the form of "You can have the planned disruption of the overhaul now or you can have the more serious, unplanned disruption of something like Wannacry later with the media and public pointing at you and blaming you. Which is it to be?".
you can have the more serious, unplanned disruption of something like Wannacry later
.. which will then be blamed on IT not doing their job properly rather than on the lack of funding to actually produce a proper secured network.
There's always a rouge engineer you can blame. (Other facial paints are available)
Generally this is not a possible solution to a hospital as a whole. It certainly needs to access the national health insurance system(s), prescription systems, vendors and possibly many others.
Maybe some crucial infrastructure may be kept offline for security but than you need to revert back to 20th century technology having to burn DVDs of all the scans etc. and carry them manually to computers of doctors.
The article conflates confidential data on hospital networks with remote access to diagnostic equipment, and these should be separated.
I don't see why the MRI machine needs to networked. Transferring the data from the MRI to the hospital Intranet via sneakernet makes it significantly harder for hackers to gain unauthorized remote access to the machine, and is the work of a few moments. Securing the data on the hospital Intranet is then a different issue that is simplified because it doesn't involve trying to get the MRI scanner to issue security related patches.
Getting the correct patient details onto the scan requires access to the hospital records, relying on manual entry results in getting them wrong. Neither do you want to tie up the machine console with burning multi-gigabyte DVDs (seriously) to get them off the scanner and then have someone have to manually push them onto the system at the other end for each scan. Besides which, this only safeguards the system running the scanner itself, your images (with identifiable information) are now in both places. Not to mention creating a mountain of optical media that needs to be disposed of securely (I used to have a literal stack of such CDs that needed to be kept locked up until we could arrange to have them shredded).
Smooth Newt - are you serious? A huge amount of effort has gone on over the years in networking scanning equipment such as this. They use a standard called DICOM
https://en.wikipedia.org/wiki/DICOM
How would you propose to do this? Writing DICOM studies to removeable media then a radiographer puts the media in another terminal and reads it in to the PACS system?
What a waste of time and sheer drudgery for someone. Hopefully in your scheme the tags for the patient ID etc. are automatically read in.. rekeying anything like that is an invitation to a mixup.
Also what removeable media? I don't know the lifetime of MRI scanners these days I must admit.
When I worked in PET scanning we archived to DAT tapes and gave patients a copy of the scans on Sony Magneto Optical disks. That was many years ago, but I doubt you would be able to get a reader fro these MO disks today.
Smooth Newt - are you serious? A huge amount of effort has gone on over the years in networking scanning equipment such as this. They use a standard called DICOM?
The problem addressed is that the diagnostic equipment is on the Intranet and so is exposed to security risks, possibly via something else on the network getting compromised. Mitigating these risks seems insurmountable if the code cannot be regularly updated. By far the best solution for keeping a system secure is to air gap it. It isn't perfect but it is the best there is.
I am sorry if it is "sheer drudgery" to vastly decrease the likelihood of the devices being compromised, but it is hardly a "waste of time". And it is less tedious than many other activities which take place in hospitals.
How would you propose to do this? Writing DICOM studies to removeable media then a radiographer puts the media in another terminal and reads it in to the PACS system?
Yep, pretty much.
There is, alas, more to DICOM than getting studies from one place to another. DICOM has been in common use since the early 90s & even today is probably one of the most complex standards in common use. It is one of very few standards that is (almost) plug-and-play between vendors globally.
For example, outside of the IT security concerns, a serious (like, very serious) patient risk is mis-identification of data. I.e. one patient's data going to another patient's 'folder'. DICOM has this solved (I think noted in the discussion above) which itself requires a series of handshakes between provider and client.
Putting the data onto media & resorting to airgap is, alas, one thing DICOM has not been great at. Vendor interpretations of the file 'format' (known as DICOM Part 10 - yes the file format is only part 10 of dozens of elements of the standards) has meant such transfer is still quite unreliable.
Yes, early versions of DICOM did have a specification of RS232 transport - but a lot of folk have done a lot of work in the meantime and partying like its 1993 probably isn't a great way forward.
Oh and a lot of these devices (especially but not exclusively outside Radiology) would also use HL7 for data transfer. That's a different kettle of fish.
The closest you could probably get is a set of separate VLANs for medical devices with NAC and a heavily locked down layer2 firewall. Given that WannaCry by all accounts only affected admin functions this may already be the case. However you still have to protect the admin network otherwise patients don't get their ops/scans etc.
It seems like it was the admin net that was the source and the major victim in this case - and that matches the experience when my SO had a serious illness - the medical side was fine, but the admin was so woeful and creaky at the hospital she was diagnosed (to the extent that had to *fax* critical docs between departments on the same site, and managed to lose her entire case history) that we demanded she was moved to another (UCH) which was vastly better.
NHS has amazing staff and medical expertise but the inconsistency of admin procedures, tools and more importantly investment across the estate seems to be the major breaking point.
Transferring the data from the MRI to the hospital Intranet via sneakernet makes it significantly harder for hackers to gain unauthorized remote access to the machine, and is the work of a few moments.
Of course you then need to guard against loss of the removable media - teaching doctors to encrypt thumb drives, etc. You secure one gap but introduce a new failure mode.
The obvious solution would be literally two machines next to each other, with a USB key on a chain so it cannot be walked away with. The key can then lift scans from the MRI host to the network terminal onto the fileshare, where doctors in the hospital - or indeed the patient's GP - can access them.
Still needs thinking about though, as Group Policy in many healthcare networks would disable removable media precisely to prevent data theft/loss on removable media...
Sure, you can make an exception on that one terminal, but then you need to ensure that the USB ports are only ever used to receive data from the (chained) USB storage/MRI host onto the network, and that no one is using that open box to egress other data off the network using the USB drive on their keyring.
Or you could keep the USB ports disabled and have a stack of DVDs, with a shredder next to the desk to trash them after the file transfer. Seems slow though - as others have mentioned these can be multi-GB files, so having to wait for the scan to finish before you can write to DVD, then import it on the network console and wait for it to write across is a significant bottleneck in the workflow.
What's probably better is having your MRI console on a separate network with no internet access - in fact the only thing it connects to is the file server where it has only write access and cannot read out. The file server then makes those files available on the main network via another, physically separate interface with bridging disabled so neither network can see t'other.
"Transferring the data from the MRI to the hospital Intranet via sneakernet makes it significantly harder for hackers to gain unauthorized remote access to the machine"
You don't have to go that far. Just provide a link that is one-way image data only. You could even connect from the RS232 port of the MRI computer to a computer that is on the network, but have only the outgoing wire connected (Tx from MRI to Rx of networked computer). Or have both Tx and Rx connected but ensure that the only commands that will be recognised by the MRI computer from the RS232 port cannot do any damage.
You could even connect from the RS232 port of the MRI computer to a computer that is on the network,
As MRI data sizes are expressed in GB, using RS232 appears suboptimal. I think you'd want something optical (easy to make sure the receiver cannot send) with speeds of at least 100Mbit/s. And only hardware flow control signalling back to the sender.
The ethernet guys need to create a one way networking standard for stuff like this (SCADA being another good example of something that needs one way networking, though RS232 is usually reasonable for its data rates) This would get them off the drudgery of creating this never-ending soup of 2.5, 5, 25, 40, 50, 100, 200, and 400 Gb ethernet over multiple types of fiber and copper media...can't understand why there are ANY copper media standards aside from twisted pair!
I saw some designs for one way ethernet cables for fast ethernet - you needed to fool it with voltage on the return path so it wasn't as simple as cutting wires but doable and would work perfectly well for a protocol like UDP that doesn't need acknowledgement. Having a serial cable as a side channel for checksums and requests to resend when checksums don't match would turn the "U" into a "R" without needing two way communication on the network link.
"You don't have to go that far. Just provide a link that is one-way image data only."
This is a sufficiently common situation that I'd be astonished if someone couldn't come up with a generic solution. Even putting something like a raspberry pi in between the unpatchable equipment and the hospital network would let the IT admins isolate the risk and patch the sole point of contact.
This. You've got a multi-meeelion eurodollar device which you dare not patch for various (some good) reasons. Stick a 1,000 eurodollar firewall/ips system between the network and the device. Allow what needs to be allowed but nothing else. Nail down the config. You can patch the firewall/IPS.
Yes, I know a Raspberry Pi does not cost 1,000 eurodollars but it must be in a case with a fancy logo, right?
Edit: Should have read more of the comments before jumping in - the point's been made further down but earlier.
"I don't see why the MRI machine needs to networked."
I don't see why it is allowed to be. In security terms, if the hospital isn't in control of it, then it is no safer than a laptop belonging to a random member of the general public. (The system owner may be innocent in both cases, but because of the lax patch regime, you don't really know *who* is controlling the machine.)
Qubes is a single user system, by design, even if it hosts multi-user VMs. What you propose would better be addressed with a VDI and/or app container setup such as Docker.
For the issue of internet accessibility versus security, the issue is the same as ANY OTHER NETWORK. It requires planning, knowledge and consistent implementation. My experience with medical facilities is that they focus only on the physical aspects of patient care and are often underfunded for that. Tell them their systems may need to be down for patching and they start playing the "it's a matter of life or death" card and straight up ignoring the very real risks they are accepting by kicking the information security can down the proverbial road. It's not that they don't understand IT or have expertise in IT, it's that they don't want to know or to deal with it because it is outside their wheelhouse.
For background, I have worked with several military medical commands. I also have had to spend more time in hospitals than I want, but nurses love to talk shop. From a security perspective, hospitals rate below public schools in my book, both physical and information.
This is an interesting comment, as a lot of the NHS in the UK used to be linked together by an internal network known as 'N3' (Mostly supplied/interlinked via Zen I believe) and is now known as 'The Health and Social Care Network (HSCN)', meaning they are all interconnected semi-internally. I'm afraid I don't know enough about the Layer3 access implications but such a network does indeed exist in the UK healthcare sector.
internal network known as 'N3' (Mostly supplied/interlinked via Zen I believe)
In the days I was forced to use it (as a 3rd-party supplier) it was run by BT - with all the dysfunction that that implies[1].
If it is run by Zen nowadays that can only be an improvement. Mind you, it'll still be DHS overseeing it so some level of dysfuntional fail is inevitable.
(Oh - and as a 3rd-party supplier we were supposedly firewalled off from N3 and only the contracted ports were allowed. Except nmap proved that I had pretty much full access. And I made damn sure to have a proper frewall protecting me from N3 since they didn't even bother to filter SMB packets. The idea was that N3 was supposed to be a 'trusted' network - as if a national network connecting thousands of sites with little or no firewalling could ever be considered 'trusted').
[1] For an example, if I wanted access to another IP address or IP/port combo, I had to fill in a form. By hand. Which then had to be sent to BT. I once asked if I could fax it and was told I could. Except that the N3 admin office had no fax number.. And didn't accept submissions by email. And only had a PO box number for submissions - that had a roughly 50% loss rate. And didn't accept anything other than the original form - but yet allowed you to phone their service desk who would do changes on the fly if you gave them valid details.. One of the many, many reasons why I was happy to leave that job.
"... don't connect your damn hospital's internal system to the damn internet!"
It's a problem that has been solved elsewhere. There are several approaches to transmitting data from inherently insecure systems to secure systems and for managing internet connectivity. However the work involved is rarely considered when purchasing Medical systems, SCADA systems etc. The people controlling finance usually consider security as "something that gets in the way and costs money". Real PHB stuff.
Diagnostic equipment and patient records should be on separate (v)LANs to the user/public/internet systems and each other. There should be a controlled gateway which enforces separation and antique systems that don't get patched should be regarded as being as much of a threat as the Internet.
I think this report seems to be looking at it the wrong way round, indicating that someone thinks that medical systems should be frequently patched/updated. Yes that's one way of doing things but it's not as good a solution as the above and it causes the regulatory headaches mentioned in the article.
Here's how it works: patient details on central booking system and RIS (Radiology Information System), patient arrives and is booked as 'attended', patient demographic data sent to radiology modality (CT, MRI, CR, DX &c. on the 'worklist'). Patient goes to be examined, radiographer picked patient from worklist - this ensures all patient demographic details are correctly added to image files.
Images taken, sent to PACS (Picture Archival Communication System) and (possibly) a local workstation. Images then available for reporting on workstations and use for physicians/surgeons.
An MRI study may be a GB or two, a CT can easily be 5GB to 10GB. So no, sneakernet or USB is a bloody silly idea; it would introduce huge delays in getting demographic data to modality and even bigger delays in exporting images. We'd need to find ten times as many scanners and staff to run them.
Let's be clear, when someone has their head hanging off in A&E, you really do't want to be pratting around manhandling data for an hour before the traumatologist gets to see it. Neither do you want to introduce the high risk of sawing the wrong leg off by manually inputting data with no verification.
In addition, manufacturers have restricted access via N3 for service and QA purposes, kill that and you'd increase downtime and, of course, waiting list delays.
A gigabit dedicated filter upstream of each modality might work, you'd only need to open it to maybe 3 ports. (Dicom Q/R and RIS, plus some more secure way for service access).
I can remember delays of a couple of years before FDA approval came through to upgrade CR readers from XP to Vista - and that's only 3 or 4 years back (and I think they are still on Vista) - similarly approval to put antivirus on.
Right now, there are still a load of dedicated modality (£50K+) workstations running XP from manufacturers that I can (but shouldn't) name. Plenty of others have shifted to Red Htt, however.
If there is intent to actually use the data in a meaningful way, at some point there must be a gateway/switch/something between the MedDev network & the primary network. Attacker gets into the primary by whatever means, exploits gateway (probably not an amateur's job admittedly) and then bingo. Random fly-by attacks (ransomware etc) maybe low-risk but a targeted attack should be on a risk register at the very least.
> "This creates a problematic situation in cybersecurity because when a medical device has been tested and sold to a hospital, a vendor is focused on creating the future wave of whatever medical devices they are working on," Zilbiger said.
Healthcare regulations should mean devices have to be thoroughly tested and validated. Full stop.
I don't see how that affects what a device manufacturer chooses to develop next, or when it chooses to do so.
Should a licenced device manufacturer find out a device has been hacked and it's performance has been changed affecting patient safety, then that would fall under the "vigilance" part of a manufacturers obligations. eg
https://www.gov.uk/government/collections/medical-devices-guidance-for-manufacturers-on-vigilance
So are scanners etc being let off the hook by not being licenced like heart valves, glucose test strips, scales, treadmills etc or are manufacturers just keeping their fingers crossed.
So are scanners etc being let off the hook by not being licenced like heart valves, glucose test strips, scales, treadmills etc or are manufacturers just keeping their fingers crossed.
Anything important or critical to life would be patched.
What it means is that (prior to WannaCry), they were not going to bother going through the entire re-certification process to implement SMB3 on the console. It worked as sold and as described.
The mood is now turning that they are going to be required to keep up with technology. If you sell a bit of hardware with a projected 10-20 year life span, you are going to have to port your software to newer OSs and patch for things like TLS/SMB version deprecations instead of requiring customers to keep old servers around to talk to your old XP-based consoles.
There are two aspects here - regulators need to require it and hold vendors accountable, but they also need to make their approval processes quick and streamlined.
You might be able to put your software through a ruinously expensive one-off testing and approval process the first time, but if the process is based around one-off approvals and is too difficult and expensive for things like point updates (e.g. disabling SMB1/implementing SMB3), then it won't get done. Ultimately the cost of that is borne by the customer (the hospitals), who have a finite budget. So the regulators need to ensure they're striking the right balance between being vigilant, but also letting vendors get updates out in a timely and cost-effective fashion.
Take an old controller PC and a new one. Feed them the same inputs, and check you get the same outputs. You don't even need to hook them to a real scanner. You had a test suite, right?
Divide the cost of the retesting between your customers - Just add it to their maintenance contracts. It's cheaper for them than buying a new scanner or killing someone.
I've been arguing this for years, and no-one has ever given me a reasonable explanation of why I might be wrong. Maybe this time
is to keep personal data off the devices in the first place. We have devices in space , for example that are quite capable of having the analysis of their data collected elsewhere.
the matching of other personal data, mapping, and diagnostics can be done on a secured system. the reliance of these devices to try to perform everything on-board will of course make changes difficult not to mention requiring outages and probably requalification's.
Yes, because there's no way that you need to be able to link an MRI scan or a clinical chemistry record to the patient that the results refer to.
The potentially-insecure device should only have a "transaction record" number. Send the device the parameters it needs, along with the transaction number. After the scan/procedure, send the corresponding data back up to your data storage, where a secured and regularly re-evaluated system connects the raw scan data to the patient record. You my need a *secured* terminal for the device operator to confirm the data and the patient are properly matched, but this in no way needs to be connected to the insecured device.
I also expect this equipment should not be connected full-time. Burst transmissions should be adequate; receive the parameters in one burst, send results back in another burst. Firmware updates done with a laptop, checked for cleanliness/security before being brought to the device to be updated, with the device's "burst network" disabled. The less time equipment spends connected, the less chance of vulnerabilities being exploited.
"They are really not investing too much effort into upgrading the previously sold medical devices because of security reasons. They might fix something because of health issues very quickly but they're not really looking into improvements that need to be made to [existing] equipment because of cybersecurity.
Cybersecurity is a must and the past few years have just proven what we already knew.
If these businesses don't care about security then there needs to be fundamental changes to the way they operate.
If hospitals started demanding security updates for the devices that are sold to them instead of just accepting the status quo maybe things would change. If hospitals don't buy their equipment the industry might just start to listen.
"If hospitals don't buy their equipment (from an industry where all the players operate very similar licence terms) people might die"
Whereas if hospitals *do* buy their equipment from vendors that are running a file sharing protocol that was superseded on security grounds over a decade ago, then people might die.
One issue that I heard about was that the device(s) have a far longer life than the OS on the underlying support terminal. So your MRI/CT whatever scanner might have been built before a newly discovered problem with a 5/10 or more year old device becomes apparent. So how do you find a way to solve that issue within a budget? It is not a machine function issue, as it still works fine for the role it was signed do, but rather in many ways it is a site management, i.e. 'client' issue. Just as driving a truck into the building, losing power, or having someone walk off with an essential part - or even use the embedded 'terminal' for some 'foreign', i.e. not the task it was installed to do, purpose, I had someone do that with a (non medical) in service live device years ago. They were not happy when it overwrote their data - naughty boy.
One issue that I heard about was that the device(s) have a far longer life than the OS on the underlying support terminal. So your MRI/CT whatever scanner might have been built before a newly discovered problem with a 5/10 or more year old device becomes apparent.
I fail to see exactly *WHAT* there is to any of these control systems (medical, industrial, etc) that is SO operating-system dependent. Seems like if something is so dependent on a particular brand/revision of an OS, it was shitty design/coding in the first place. And I can only see *that* element getting worse.
One computer to handle the medical function networked by an internal link to a firewall/security computer. All control of the medical device is on one computer that runs the approved (and often years out of date) software for the device. The second (firewall) computer as it does not control the device can be kept up to date to deal with evolving security threats. There must be NO external (outside the device) network connection except via the firewall computer. Any USB (or similar) ports on the control computer must be behind locked access panels (or disabled with epoxy glue).
"All control of the medical device is on one computer that runs the approved (and often years out of date) software for the device."
There's an additional problem if that computer fails and the approved S/W is unable to run on current H/W. There's a periodic need to update the S/W to keep up with what's available in the market place.
"There's an additional problem if that computer fails and the approved S/W is unable to run on current H/W. There's a periodic need to update the S/W to keep up with what's available in the market place."
That one is easy. You insist that the vendor either maintains it for the period specified in the contract or publishes sufficient information for you to do so. Failure to do either results in paying back x% of the purchase price, where x% is the percentage of the advertised product lifetime that turned out to be untrue.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
