The PLC engineers I had contact with usually had an electrical engineering background. That's why they like PLCs in the first place with the ladder logic programming languages, grafcet and if they feel fancy a bit of structured text (assembly like) or structured control language (pascal like). They indeed did not know much about software security but a great deal about machine safety.
A real security nightmare are older OPC servers (OPC-DA) which is super reliant on DCOM. OPC is quite important to connect the PLCs to SCADA systems or 3rd party devices.
Then someone plugs in a cable because boss wants something "over there" and there's already a network that runs "over there". Or optimizes to a smart switch with vlans, and then someone else optimizes to a single vlan. It's not hard to not give a shit, or not understand, network security.
In reality it'll likely first be noticed ten years down the line, by someone who lets out a big sigh, mutters something about "incompetent dipshits not updating documentation", and moves on with their day.
I'm saying that's what you do in order to solve the issue. You have to actually try, and you have to do actual engineering.
If the local planning commission submits a call for proposals for a bridge to cross a 400 foot chasm over sharp rocks, and they insist that it absolutely, positively must be made out of popsicle sticks, local civil engineering firms aren't going to take up the project, because that's insane.
Why do we give the management of these places a pass for PLC and SCADA systems that could give massive problems - up to and including the loss of human life - if they're hacked?
On my project the service I wrote was doing bidirectional communication with the PLC over OPCUA. The server running this pod was connected to the internet, so it was critical to have proper TLS for the OPCUA client/server. Rotating LetsEncrypt certs on the system every 45 days is a lot of toil, but using a self-signed cert that expires in 2040 from some dev laptop doesn’t pass muster in most organizations either.
That’s just the OPCUA path.. In these projects You also typically see WinCC HMIs that can talk to the PLC from anywhere on the network without TLS. And also SIMATIC Web Server pages - minimally secured by default, and the amount of info you can grok about the system in Chrome Dev Tools is troubling.
admin/admin is on a post-it stuck to the monitor because everyone we hire is perfectly capable of rooting a machine they have physical access to.
What is unique about your system using LetsEncrypt that you can't automate certbot to handle this task as it was designed and intended to be done?
Some PLCs run extremely expensive machines. Some machines can't afford to have their control systems stutter or fail because that can lead to physical damage and production outages of enormous proportions. A PLC that stops communicating because a certificate just expired is absolutely not acceptable in some plants.
Running certbot on a random PLC isn't happening.
Not really dissimilar from the human upbringing: leave a baby with "bad" guardians, and it will grow up corrupted. That's a feature, not a bug: if you knew what behaviour exactly you wanted (other than "whatever Simon says"), you would just bake it in in the first place, right?
Stuxnet was over a decade ago.
There should be a simple rule that everyone with the ability to understand things like PLCs should be able to grasp: your equipment does not touch the internet or external storage, period.
Those who can't grasp this concept should be shown the door with a recommendation that they find a less mentally-taxing line of work.
The worm was designed to jump across network air gaps via USB flash drives, and spread across isolated networks to other hosts. Finally, it targeted what was likely going to be a service technician laptop, which had to connect to the PLC via a data cable to update and adjust its configuration.
An attack like this can only be avoided if you never transfer any data from the outside to the inside. But that means you won't ever be able to install any form of software update or upload new config files without manually typing them in - or even reinstall the OS on any machine...
Fact is if the customer wants to put their worksite management on AWS, you inevitably expose the OPC server and/or PLC to a Intranet. This is then inevitably connected to the internet in some way. The customer may or may not put barriers between them, but that's not up to us to decide.
This becomes especially a problem if they have multiple sites across a country or countries.
We have a customer that runs a factory on god forsaken WIFI, then dares to complain about a bad connection to said equipment. Thankfully, they have their own internal IT department.