This
This machines costs hundreds of thousands of dollars.
There should be no excuse for using Windows. None.
I would not be surprised if the "antivirus" thing was some PHB requirement
This machines costs hundreds of thousands of dollars.
There should be no excuse for using Windows. None.
I would not be surprised if the "antivirus" thing was some PHB requirement
The bad decision was installing antivirus software. Otherwise, most any modern OS would be fine. This machine probably shouldn't be connected to a network (if it was), the USB ports should be disabled; data can come off on burned CDs, autorun should be disabled, etc. That's how you deal with IA concerns on a standalone mission-critical system, not by installing antivirus.
Having their software run in a Windows ecosystem that they do not have strict configuration management control over was a bad decision and on the basis of this failure report. That it did not result in patient injury or death was fortunate but is certainly not guaranteed.
No matter what OS you choose it is vulnerable to viruses. You and I will agree that the odds are your Windows system is much more at risk by at least an order of magnitude. But the IA people who demanded that this system run antivirus are just as likely to demand that Linux run antivirus, simply because the vulnerability theoretically exists and making that demand fulfills their CYA requirements. I've worked on standalone Linux systems that IA demanded have antivirus.
> Either you own that decision, and as part of your support your tool provides the necessary antivirus and you also insure through testing configuration management that its configured appropriately, or you choose a different option up to an including writing your own system to manage the "time critical bits".
According to the article, the software runs on the user's hardware. While they certainly could have made a decision to provide their own controlled hardware, it's entirely possible that hospital was not open to that option for cost reasons, for IT management reasons, whatever.
> No matter what OS you choose it is vulnerable to
> viruses.
By writing just enough "OS" to achieve your goals in an embedded system, and then designing a clean access API through which you cannot affect the underlying code (no "here download this new firmware" call) you can avoid that particular threat vector.
it is a common misconception that Windows is still worse a platform than Linux when it comes to security. Not trolling ... I'm using Linux since '96 and built my life and career on it. Opinion of some people in infosec circles (@thegrugq @csoghoian ...) is that Windows no longer lags behind:
https://grugq.github.io/presentations/COMSEC%20beyond%20encr...
* Is Windows security equal to or greater than Linux and OS X (Probably yes)
* Are the overwhelming majority of viruses written to target Windows systems (yes)
I really enjoyed this article on security economics which goes into this in more depth: http://tidbits.com/article/15939
This may be theoretically true, but it is not practically the case. There is a reason Linux and OS X users almost never use antivirus software.
Using Windows on a medical device is inexcusable. It's a heart monitor, not a game system.
Today, doctors from a hospital the other side of the country can diagnose your cancer realtime while you are still in the MRI machine, and they do it with Windows, because that's what humans know and use.
Probably because they've been exposed to it in a many settings, for better or for worse. Windows being popular does not imply that Windows is appropriate for any given task.
> Why shouldn't the devices use Windows?
Is this a serious question?
Windows is probably the least stable production OS in the world today.
Windows is extremely bloated compared to an appropriate embedded OS.
Windows is (practically speaking) the only OS where antivirus software is a fact of life. Viruses should not be a concern for medical equipment.
Windows is not even close to real-time.
I don't want to see "Your heart monitor is restarting for updates in 3... 2... 1..."
> and they do it with Windows
This may be technically true, but this in no way implies that Windows is uniquely suited for or appropriate for the task. They could also do it using a PlayStation, but this is probably not an appropriate platform.
That's not true for what those systems should be really running which is separation kernel platforms. These isolated tasks in partitions using high-assurance kernels designed to not fail in every way you can think of and with almost no code to hit. The apps even donate their own resources for kernel calls. Interface is in untrusted VM that sends checked commands to real software running on isolated partition optionally on Ada or Java runtime for memory-safety. Anti-virus is not available and not necessary given the untrusted part is strongly contained & the trusted part is memory safe.
http://www.ghs.com/products/safety_critical/integrity-do-178...
https://os.inf.tu-dresden.de/papers_ps/nizza.pdf
Just a matter of using right tools for the job. Any medical device using Windows or any other complex OS isn't doing it right. Even OpenBSD would've been a better choice given it rarely is hacked, crashes, or needs updates. Antivirus software wouldn't run as it's not available for these. It would be a network appliance or something that didn't affect running system.
And I would have followed the same steps you mentioned. The machine could work with Windows.
Windows CE might have been a better pick, so you can have things like RO filesystem, etc
"There is no reason to use Windows" is, as you mentioned, not a bad decision in itself, but since they do it the lazy way, it is awful. Not sure if there's an out-of-the-box way of firewalling everything in the Windows versions available at the time that machine was built
* GUI dev tools were an order of magnitude better than under linux
* nidaq (very common daq and dio cards) didn't have or had flaky linux drivers. usb may be a better choice today but was not then available. Plus it's convenient/less expensive to push functionality to the computer side and minimize embedded development.
* in the beginning (though we fixed this mistake), we shipped software, our machine, and a ni-daq card; users provided a computer. This was a nightmare. We ended up shipping whole computers custom built by Dell to our specs with ni-daq cards installed (and later glued in to prevent them slipping out during shipping) plus our custom system images. At the time, I don't think Dell would do this for linux; you could find other vendors that would, but they weren't easy to work with or much more expensive.
* Nobody is eager to switch OSes because every software update to the machine has to be FDA certified (ie kiss at least $100k goodbye), so the company is very risk averse. Beyond even the cost to rewrite what has evolved into a relatively complicated gui app.
* As mentioned elsewhere, once you leave windows you have to train people to use linux guis that historically had window managers / gui toolkits that didn't work like windows.
All of the above is complicated by the fact most of these medical device companies pay their devs shit and have trouble hiring good devs. (Engineering shortage, obviously!)
Interesting. Does that imply that every Windows update Microsoft releases has been FDA-certified already?
Now based on the class of medical device you are developing, you can either get to use SOUP without justifying at all, or you have to explain/justify why you can use SOUP at all.
For example, even if your OS was Linux, because you don't have formal documentation on verifying that Linux infact does all the things its suppose to do (hell, does Linux even have a true spec?), you would then have to justify why you're using Linux. If a kernel update comes out, you then have to justify why you're using it.
What you WOULD have to do is verify/validate that your software that interacts with SOUP (so in this case running on an OS) still works correctly. You would not have to verify/validate the OS update per se.
Trust in the company's ability to properly validate the device is tempered by regular FDA (and other regulatory bodies) audits of their development process and process data, test reports and a general desire to stay in business. FDA can and will take your product off the market if it appears to be unsafe and the company does not respond appropriately.
Our machines were actually purchasable in two ways: one certified for human diagnostics (FDA Class III, I think), and one not, for eg veterinary or scientific use. The former got 1-2x/year software updates, while the latter got monthly releases. We had to enforce usage requirements both with contracts, download restrictions, and in-machine checking. ie you couldn't use the non-diagnostic firmware or software on a diagnostic-certified device. You also had to use certified reagents -- enforced in hardware -- in diagnostic devices.
It's a lot of work, but given some of the software I've seen, and the fact that if these machines get the diagnosis wrong you either won't be treated for deadly diseases or will be treated in very toxic ways for diseases you don't have, the requirements are reasonable.
I wish I was kidding.
I know that "tired person in a hurry" is a trope, but considering how masochistic the health professions are about sleep, it really applies here.
As an aside, if "familiar interface" is your only requirement, I'd suggest to install a door handle or light switch.
With Windows 10, this problem will likely get a whole lot worse. What do you do when MS pushes a forced update to your deployed devices and it bricks some of them? http://m.theregister.co.uk/2016/05/06/microsoft_update_asus_...
What about when you can't disable Cortana (without breaking the start menu) and you're in a HIPAA / PCI environment? http://winaero.com/blog/how-to-uninstall-and-remove-cortana-...
As we've seen with things like SCADA, switching from Windows is not a silver bullet, but in terms of minimizing the complexity and attack surface, Windows seems to be starting at the opposite end of the spectrum.
However, I do question "it looks like Windows" as a valid rationale for what appears to be a single-purpose machine. I don't think it's likely that staff are using the operating room equipment as a desktop machine, so presumably they only care about the in-app user interface. And an application interface can be made to "look like Windows" regardless of what OS it's running on.
If users are never meant to interact with the OS itself (airport terminals, ATMs, displays, etc.) then it makes absolutely no sense to use Windows.
This isn't far from the truth. You'd be better of providing a console with clearly labelled buttons and switches. No operating system exposed to the user. It's not very practical to implement, let alone make changes to, but it would be more dummy proof than any desktop application.
This is also why you see a lot of kiosk-like, full-screen applications, with no ability to actually work with the desktop interface itself. A single kiosk application that cannot be alt-tabbed out of, providing screens that are easy to navigate.
I still think this was a poor decision, but it's a different kind of poor decision
Having an anything-critical Windows machine on the open Internet might not be such a wonderful idea.