Perhaps there exists an easier middle ground solution such as somehow putting a safe proxy machine in between the unsafe machine and the internet using a very simple controlled communication to the unsafe machine?
Should they be scrapped? Maybe not. But not just left as they are either.
Most importantly: don't BUY that next MRI if it's approved only for a certain OS version and it's a general purpose OS such as Windows, and it will be connected to the internet. If you DO buy it - calculate with writing it off within the support window for the OS. That will show its true cost.
Further, equipment using general purpose OS'es should stop being approved for one version and automatically qualify for newer versions. Alternatively the approval should not be valid beyond the support window unless the machine is air gapped.
I wonder if it would be feasible to protect them with some dedicated firewall/proxy boxes or plug-in modules which could be cheaply updated (compared to the cost of updating and revalidating the whole machine), supplied by multiple vendors, etc.
Of cause not, but the hospital knew that the Windows XP running their multi-million dollar scanners would be end-of-life before the scanner it self. They should have required that the software be placed in escrow for the life time of the scanner, so that other parties could do any needed updates, if the supplier failed to do so.
I'm sorry, I get that you can't throw away expensive hardware, just because Microsoft no longer patch that version of Windows required to run the software but: EVERYONE knew that the hardware would be in use beyond end of life date for the operating system. So why isn't that included in contracts and support plans? Do banks and hospitals even care enough to ask how the supplier plans to deal with an EOL operating system?
People do that?
And "if company ceases to maintain and release updates to product, we will receive the source code for our use" doesn't sound like too poison of a pill for Sales to push through.
Well, maybe there's more to a complex organization like a bank or hospital than software licensing. Maybe their service contracts had these exact contingencies but they've run into other problems that nobody could have predicted when XP was new, like:
* That there would be a Great Recession that would wipe out a lot of firms, including banks, hospitals and medical device manufacturers.
* That there would be a massive new piece of legislation that would tax medical devices heavily, thus changing the way that market works.
* That the same piece of legislation would encourage hospitals to merge into each other through various incentives that were intended to limit the cost of healthcare.
* That Microsoft would decide to break backward compatibility sharply compared to what they did before. Don't laugh at this one; they were business for nearly 30 years when XP came out and never broke backwards compatibility as much as they did in the past 10.
I suddenly feel less good about my next dentist appointment.
Plot twist: this has already been going on for decades.
The fact that people are trapped on XP is Microsoft's fault. Because some manager in Microsoft decided that getting the upgrade numbers up by breaking hardware drivers was a good idea, you have a security nightmare decades on.
The medical device was validated with a certain version of the OS and any special configuration placed on it. If you change the OS/configuration setup in anyway, you (the manufacturer) have to analyze it for impact and potentially re-validate it. The user cannot make this change This would be a violation of FDA regulation.
Now, the hospital can say that they're going to stop using your equipment until you "fix" it --- many such products are leased, not purchased and they may use the lack of security to break the lease. But that presumes they can get a replacement that works as well, train personnel in it, update the supply chain, storage, incoming inspection, etc. for this new product and any supplies it needs...
It's not as simple as running down to MicroCenter and installing a copy of Windows 10!
(Bit of a moot point in agreement, but thought I'd share my 2c)
The fault lies entirely with the manufacturer for not providing a system fit for use/sale.
It would still cost money, but at least there's a legal path forward.
Better still would be having a device that operates on some commodity connectivity using standard protocols (APIs/etc) which can be soft-gaped by a firewall / guard that only lets well formed (or at least expressly authorized) requests in.
The open source OSes do go extremely out of their way to provide and keep userland APIs stable, in many cases modern hardware that would be completely unsupported in XP or some other proprietary OS, and again, if something that used to be depended on somehow falls out of support you're at least actually free to pay someone to add in the support you need.
1. Well, maybe you could do that with your abundance of skill and time, but not everyone running a hospital/bank/other-large-organization has the time or budget to slap together and maintain that kind of amateur hour rope-and-tin cans proxy shit.
2. Not everything people use a computer for happens over a network. Some people write software because they need to communicate directly with hardware devices. You can’t intercept network traffic when there is no network traffic to intercept.
2. I believe we're talking about network accessible devices here. Otherwise why would parent make comment about air-gapping infeasible?
2. The parent mentioned networking, but networking is not the only threat vector that must be accounted for. Malware can spread through removable media, and most organizations outside of the military or federal government simply don't have the sort of security policies in place to prevent that. So the unpatched vulnerabilities people are talking about can still be exploited even without the network stack doing anything.
Honestly, the cost of it getting broken into seems to be significantly higher than the cost of upgrading the systems.
We don't necessarily know what the costs of "getting broken into" are. It depends on who you are and what the breakin does. It could only cost the time it takes for IT to restore a backup and plug the hole. I mean, yeah, if you suffer a spectacular ransomware attack and are screwed so badly that you must pay the ransom and everyone finds out, that's probably more expensive than updating. But that's not the only threat or even the most likely threat your organization may contend with.
We also don't necessarily know what the costs of updating are. If you're just doing boring office stuff, the costs are low and you should just fork over the money to Microsoft and get it over with. If you need to update a bunch of custom drivers for some devices that are important to your business because the device manufacturer went out of business, that could be a vastly expensive software development project that your organization can't afford to do. Certainly that costs a lot more than having Bob in IT rewind the tapes when Russian hackers get ransomware past the firewall.
They can (sometimes) put in intermediary proxies and the like, but that's not a cheap process.
It's the only way that large institutions will come to properly value the security trade-offs of their decision to buy closed-source, proprietary systems.
Why should the VA get to externalize part of their purchasing decision on to Microsoft?
These devices run embedded Windows because they all always have. There's almost no competitive advantage in changing OS vendors in the space, because it doesn't differentiate the product. Even if a device ran CentOS or whatever, you wouldn't be able to update it significantly without going back to the FDA.
Lobby to change the market instead of externalizing costs; pool money to change the market instead of externalizing costs; etc.
I'm sick of people defending poor long-term decisions by saying they're short-term efficient. The providers aren't helpless entities these things are just happening to: they chose to go down a route that was expensive long-term, but cheap short-term and now are asking to not have to face the consequences of that. I can guarantee that every single institution facing this concern received a technical report pointing out exactly this issue -- and chose to ignore it so a manager could have a bigger bonus.
Instead of addressing the problem, they're asking to be let off the hook of their poor decision making and laying the groundwork for the same mistake. Continually bailing out such poor decision making isn't prudent.
Why would they ever change if there's no consequence?
This isn't a long-term strategy we can afford to support, so we're obligated to let it blow up in their face.
>I'm sick of people defending poor long-term decisions by saying they're short-term efficient
I'm not defending poor long term decisions, I'm simply describing the reality of a complex set of intersecting political and business systems. Sure, maybe it would be good to lobby the FDA to change rules about updating embedded software, but what should the new rules look like? How do you make sure new linux drivers for an x-ray machine won't have a buffer overflow or off by 1 error that kills people? It has happened.
I'm not even sure that Linux is definitively the right answer for embedded operating systems for safety critical systems. Do you have any evidence to support that claim, which you seem to be making? I'll be happily persuaded if you can clarify why open source is intrinsically better for long lived embedded systems like this.
Private organisations/companies? Less likely. Would they even have the ability to do a build from the source code?
Thanks for that one, I didn't put those together before.