That depends heavily on your threat model and who is out to bother you.
I agree that you can't make something custom totally secure - but you can radically reduce the number of people capable of attacking it, and increase the costs of attacking it.
If you're running Windows with Active Directory, the number of people who can attack your network at some level is "Pretty much anyone who cares to learn a bit about hacking." They may not be successful, but if they happen to get lucky around the time some new 0day drops, welp. Timmy Two Thumbs just pwned you.
The more custom your environment in terms of hardware and software, the higher the development costs, certainly, but also the fewer people who can attack you. If you've got a custom limited function OS, no generic hacking tools are going to work on it, so now your attacker scope is things like "Governments who can get a copy of it and are willing to invest the money to reverse engineer it and find vulnerabilities." Which, if you're worried about governments, is certainly a risk - but at that point, the chances of some random ransomware gang taking you down are near-zero, because they don't care about you - they care about easy targets who are likely to pay. Custom reverse engineering isn't really their thing.
There's no such thing as a system secure against everyone - but you can make it a lot harder to randomly target. And, if you're talking about a train system, there comes some point when it's easier to just go blow up the locomotives than to wage a cyber attack. Easier to trace, certainly, and riskier, but that's the point. If you can force an attacker to either expend disproportionate resources, or require them to go down riskier attack paths, you may be able to deter the attack.
You can also ask some reasonable questions about the concept of field upgradeable firmware on critical safety systems. There was some set of malware a while back that targeted some sort of industrial control system, and seemed designed to bypass the safety release valves through a remote firmware update. If you have a safety valve set to pop at 300 psig, why does that need remote firmware updates? It should be set to monitor the pressure sensor, pop the valve and report at 300psig. Allowing someone on the network to remotely update the firmware on the safety system seems entirely silly, because presumably if you actually needed to do that, you'd have been doing some piping upgrades that would make it easy enough to go get the unit, physically touch it to twiddle the write lock, and upgrade it.
I agree that you can't make something custom totally secure - but you can radically reduce the number of people capable of attacking it, and increase the costs of attacking it.
If you're running Windows with Active Directory, the number of people who can attack your network at some level is "Pretty much anyone who cares to learn a bit about hacking." They may not be successful, but if they happen to get lucky around the time some new 0day drops, welp. Timmy Two Thumbs just pwned you.
The more custom your environment in terms of hardware and software, the higher the development costs, certainly, but also the fewer people who can attack you. If you've got a custom limited function OS, no generic hacking tools are going to work on it, so now your attacker scope is things like "Governments who can get a copy of it and are willing to invest the money to reverse engineer it and find vulnerabilities." Which, if you're worried about governments, is certainly a risk - but at that point, the chances of some random ransomware gang taking you down are near-zero, because they don't care about you - they care about easy targets who are likely to pay. Custom reverse engineering isn't really their thing.
There's no such thing as a system secure against everyone - but you can make it a lot harder to randomly target. And, if you're talking about a train system, there comes some point when it's easier to just go blow up the locomotives than to wage a cyber attack. Easier to trace, certainly, and riskier, but that's the point. If you can force an attacker to either expend disproportionate resources, or require them to go down riskier attack paths, you may be able to deter the attack.
You can also ask some reasonable questions about the concept of field upgradeable firmware on critical safety systems. There was some set of malware a while back that targeted some sort of industrial control system, and seemed designed to bypass the safety release valves through a remote firmware update. If you have a safety valve set to pop at 300 psig, why does that need remote firmware updates? It should be set to monitor the pressure sensor, pop the valve and report at 300psig. Allowing someone on the network to remotely update the firmware on the safety system seems entirely silly, because presumably if you actually needed to do that, you'd have been doing some piping upgrades that would make it easy enough to go get the unit, physically touch it to twiddle the write lock, and upgrade it.