Hacker News new | comments | show | ask | jobs | submit login

This 100x. I know it's extremely easy to Monday morning quarterback hospital IT but it's not as simple as people think. There's legal and, far more importantly, medical implications to updating software at a hospital. Oh you think it's ridiculous we use i.e. 7 in compatibility mode? It's because our mission critical emr only works in that (well it really works in everything but it's certified in 7) and if we use anything but the certified software load in accessing it the vendor puts all blame on us.



Yes, it actually is.

Life critical systems should be small, fully open stack, fully audited, and mathematically proven to be correct.

Non-critical systems, secondary information reporting, and possibly even remote control interfaces for those systems should follow industry best practices and try to do their best to stay up to date and updated.

Most likely many modern pieces of medical technology have not been designed with this isolation between the core critical components that actually do the job and the commodity junk around them that provide convenience for humans.


Maybe you really think it's just as simple as mandating exactly what you wrote here. But I'd imagine you'd agree that even doing this would have real and significant costs, which means tradeoffs are going to have to be made, e.g. some people won't receive medical care they otherwise would.


> some people won't receive medical care they otherwise would.

which is what happens when your whole computing network is remote-killed


The problem is that the technology stack required by modern equipment is too large to be satisfied by anything but a general-purpose OS. Good luck trying to get a mathematically proven OS.


Pretty sure you can build an X-Ray/MRI control software in Rust on top of seL4, and do lightweight verification (or, even better: hardware breakers of some sort) around issues like "will output lethal doses of radiation". That is a general purpose enough kernel and a general purpose enough programming language, without having to drag in tens of millions of lines of code intended for personal GUI systems... Then for malware issues you simply don't plug that device directly into the internet, nor allow it to run any new code (e.g. your only +X mounted filesystem is a ROM and memory is strictly W^X).


Rust has a lot of nice safety features, but the compiler hasn't been formally verified at all.


Yeah, I am aware. The problem is that using, say, CompCert might result in less security in practice, since although the compiler transformations are verified, code written in C is usually more prone to security issues. It also puts the burden of proving memory safety on the developer, which is a requirement for proving nearly anything else. I don't know Rust well enough to know if this applies for sure, but I think it is a lot less to ask from the manufacturer that they produce a proof of the form "assuming this language's memory model holds, we have properties X, Y and Z" and then just hope the compiler is sane, versus requiring a more heavy-weight end to end proof. Also, eventually there might be a mode for certified compilation in Rust/Go, at which point you get the best of both worlds.


This is true, but work is in progress, and some parts of the standard library already have been. And some of that work has found bugs too: https://github.com/rust-lang/rust/pull/41624


https://sel4.systems/ is a formally verified microkernel.


Does this distinction between critical and non-critical systems make sense for medical equipment? Displaying the information to humans (doctors and nurses) is probably life-critical. If the display is broken, it's not working.

It's not like medical devices have an entertainment system like cars and airplanes.


The display and the business end of the equipment are critical and should not be network-connected (or even have USB ports, for that matter). The part that uploads to whatever big server should have updates all the time. The critical bit should either be connected to the non-critical bit by a genuinely one-way link (e.g. unidirectional fiber) or should use a very small, very carefully audited stack for communication.

This is all doable, but it adds a bit of BOM cost and changes the development model.


An alternative would be to expose these subsystems on a network and have strict API's, encryption, and authentication between them. This would allow you to audit/update components individually rather than the whole device. So your display would act as a networked display and only have a very limited set of functions.


Yep. That worked fine for the Iranian uranium centrifuge guys...


stuxnet jumped airgap over usb, did it not?


We already have that distinction in our current regulations... some devices need FDA approval, some don't


Which is why bog standard COTS OS shouldn't be used for these types of devices. They should use a proper hardened embedded OS that has some form of mandatory access control / capability isolation system.

The long and short don't use standard desktop Windows (or even standard embedded Windows), Linux or MacOS to run these devices.


It's fine to certify devices for certain software, but a device must either be free to maintain and secure or it's not connected to a network.

If someone has a computer hooked to an MRI machine and to the hospital network, and it runs outdated/insecure software then someone made a mistake somewhere.


> If someone has a computer hooked to an MRI machine and to the hospital network, and it runs outdated/insecure software then someone made a mistake somewhere.

If you want a system to reach 100% it can't rely on not making mistakes. If all operating systems are supposed to be updated, then this has to be enforced as part of the software. The software e.g. shouldn't accept traffic unless it's up to date.


Oh you think it's ridiculous we use i.e. 7 in compatibility mode?

It's certainly ridiculous if you don't keep it utterly sandboxed and limited to only required use.

Also ridiculous is anyone falling for - or being allowed to fall for - a mail based phishing attack anywhere in the organisation.


Oh come on. They are doctors and nurses, not programmers.


But isn't it part of their job to care for their equipment?

This is a failure of management to properly train their employees.


Anyone disregarding common sense security advice anywhere in any organisation should leave the premises under escort within ten minutes. Would have upped standards everywhere years ago if implemented.


I'm curious, not trying to be smart: 1. Would running Windows 7 in a VM violate the certified software load? 2. Is new device software being written to run in containers/hypervisor level?

I could understand if 1 would be a violation, but perhaps, after today, the FDA could fast track manufacturer patches to run software loads on VMs?

I don't imagine 2 would solve current infrastructure issues any time soon given the size of investments in current equipment, but could it be a best practice going forward?


Usually you get the system integrated into some panel of the device. It's not the software itself that's certified. It's the device as a whole with everything running on it, hypervisors included.


Many years ago, early days of War on Terror, there were 'cyberstorm' exercises by the TLAs of the U.S. military allegedly on some mythical networks that were not 'the internet'.

In 2006 this involved a nice virus that sent all your photos and emails off to people they were not intended to go to, there was a psychological aspect to what was going on with this payload plus a full spectrum dominance aspect - the media were briefed with the cover story but I don't think any journalists deliberately infected a machine to see for themselves.

At the same time that this was going on there were some computer virus problems in U.K. hospitals, those same Windows XP machines they have today. The Russian stock market was taken down around this time too.

Suspiciously I tried to put two and two together on this, but with 'fog of war' you can't prove that the correlation = causation. The timing was uncanny though, a 'cyberstorm' exercise going on at the same time that the BBC News on TV was showing NHS machines taken out by virus.

https://www.dhs.gov/cyber-storm-i

http://www.telegraph.co.uk/news/uknews/1510781/Computer-bug-...

So that was in 2006. A decade ago. If you found a hole in a hospital roof a decade ago they would have had ample opportunity to fix it. They had a good warning a decade ago, things could have changed but nothing did.

I had the pleasure of a backroom tour of a police station one night, don't ask why, luckily I was a 'compliant' person, no trouble at all, allowed to go home with no charges or anything at all. An almost pleasant experience of wrongful arrest, but still with the fingerprints taken - I think it is their guest book.

Every PC I saw was prehistoric. The PC for taking mugshots was early 1990's, running Windows 95 or 98. I had it explained to my why things were so decrepit.

Imagine if during the London riots of 2011 if the PCs PC network had been taken down with all of that police bureaucracy becoming unworkable?!? I believe that the police computers are effectively in the same position as the NHS, with PCs dedicated to one task, e.g. mugshots, and that a take down of this infrastructure would just ruin everything for the police. I think that targeting the UK police and getting their computers compromised (with mugshots, fingerprints, whatever) and then asking the police to pay $$$ in bitcoin before they were locked out for good next week, that would have made me chuckle with schadenfreude.


Just wait until Congress tries to impeach Trump, people are rioting in the street, various factions fighting each other, and then the shit you just described happens. Maybe the Education Secretary's brother has some resources in contingency for such an event.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: