The best systems are implemented either in-house or by a team of consultants working hand-in-glove with the in-house IT or ops teams, then maintained in-house. That's been my experience. Unfortunately your average municipal wastewater plant is probably run on decades-old systems by the same IT dept. that fixes the city council's printer.
It sounds dramatic but every update or change to the system rocks the boat and exposes it to a whole new tranche of dangers. So we spend most of our time observing. There's no such thing as a casual QoL update in SCADA.
Most SCADA systems date from the 1970s and a lot of them don’t really think about network security or even have a concept of it. So, they don’t think about the consequences of connecting it to the Internet for remote access. It’s just a feature they want.
> So, they don’t think about the consequences of connecting it to the Internet for remote access. It’s just a feature they want.
This is the disconnect that's so confusing.
Operators understand how important having them connect to PLCs and various bits because failure can mean you can take out parts of whatever it’s controlling, the power grid, oil pipelines, etc. So, you need to be very aware of what you are doing when you do these upgrades. There’s a lot of process to ensure you don’t break things.
But, you tell them about network security and or having to have Modbus messages wrapped in TLS and some of them will tell you to shut up and get out of their way. These systems have literally been just ported from the equivalent of a PDP/11 to Linux. So, not the most robust things when you come from a network security perspective. They really are 1970s systems and it’s really annoying, but I don’t think there’s any money in really doing anything about it and a lot of people make good money consulting around for these things.
No profit in security/dependency upgrades. Propriety SCADA protocols to enforce full stack manufacturer lock in.