These things do not belong anywhere near the internet, patched or not.
This isn't just about hacking. A device that crashes hard when it receives a POST with an empty body may do the same thing if there's a physical glitch with its connection, or if a cosmic ray flips a bit somewhere. Devices that control industrial machinery should be more reliable than that.
If this were a hobbyist project, or a toy, that would be one thing, but these are specialized devices that cost a lot of money. They're fragile liabilities that don't belong anywhere near a shared network.
Yeah - I can see even the simplest of network vulnerability scans wreak havoc on a device like this.
This business reality is going to get worse as time goes on. Companies would be receptive to change if people at the executive level were educated first. The carrot being more cost effective system development.
This is already turning into a major problem with IOT devices from supposedly reputable companies i.e. home thermostats that let pipes burst because of a bad or incorrectly pushed update. Now consider if that bad update could instead kill someone.
bad updates are bad updates. they are incompetence on the part of the programmer. but the worst they should be able to cause is minor equipment malfunction or the physical system has been poorly designed.
Or something dumber, maybe they pushed a temp variable to the wrong type of memory (say flash eeprom) that updates every cycle of the control loop, and then did a push to an entire line of manufacturing equipment. Congratulations, all of those are going to brick in an hour or so when the memory hits it's maximum write cycle lifetime and you'll have to get new boards shipped in while your entire line is down.
Remote pushing needs to be handled very carefully when controlling real world equipment.
I have made a total of at least 7,500 remote updates over maybe 25 different control systems. In fact we basically get it working well enough the operators can handle day to day stuff and then go remote after that, because who wants to stay away from home at some dirty industrial site eating crappy food. The exception to that is backup power for hospitals, no remote access there and it is a simple enough system we can test all the different scenarios and then walk away.
Generally the last thing I put before an output in a PLC is some rate limiting. If it is a discrete output it won't be allowed to operate more than once every 5s for example. If it is an analog output it is limited to achieve the maximum desired actuator velocity or acceleration. This is a good catch all to avoid damaging equipment. I watched somebody learn this the hard way as a DC motor starter exploded when it was told to start and stop the motor 10 times a second.
Certainly I have made errors. A bad one was I forgot to limit a position so that it could not be less than 0. The position was subtracted from some other number. Substracting a negative number is adding! That was a nasty positive feedback loop that resulted in fast oscillations in the position of a 1m diameter pressure reducing valve. However that was during on site commissioning not remote.
Certainly for major changes I will require a shutdown and co-ordinate with the operators, but it is a judgement call on my part as to what I can program and test at the office and unleash on remote equipment vs. what needs to be tested on the actual equipment. Most testing on the equipment is required to determine the equipment characteristic.
What terrified me most is not only the state of ICS nowadays (it's pretty much fucked), but also the fact that cyber-security vendors try to make a profit from that by shoving their products down the throats of scared managers.
And what @donquchotte says is pretty much true - on facility there I practiced, all PLC were connected via TeamViewer to company network, passwords were written on stickers and slapped on monitors. They used Modbus over TCP, plain-text packets easily viewable with Wireshark.
On the first day I accidentally broke my S7 because of wrongly uploaded configuration, it took them 3 days to find some special Siemens laptop to connect to this PLC and reset it. Also tried to play around with Metasploit and follow the work of Beresford [1,2], but the most trivial attack of mine was just flood on PLC's IP with random junk - it stopped responding to any commands.
[1]: https://www.youtube.com/watch?v=33kouEKm0zo
[2]: https://github.com/moki-ics/s7-metasploit-modules