Attacks on these industrial controllers could lead to sabotage of critical infrastructure:
Agencies Claim Threat Actors Use AI Tools To Generate Exploitation
“The actors leverage Internet scanning services to find Internet-exposed PLCs running outdated software or that are otherwise poorly protected,” the agency said in its warning. “The U.S. critical infrastructure sectors most targeted by this threat activity include Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, and Commercial Facilities. This is not a theoretical risk — it is an active threat. Depending on the specific circumstances, exploitation of poorly protected PLCs could lead to disruption of critical industrial processes, safety incidents, downtime or equipment damage, compromise of sensitive data, compliance violations, and cascading impacts across interconnected systems.”
What makes the threat especially dangerous is that the use of AI tools could enable potential attackers to make malicious files look and behave like legitimate monitoring tools. They achieve this by using open-source industrial automation libraries, making it easier for unsuspecting users to fall victim to their attacks. Although the agencies did not specify where these attacks could originate, they came less than a month after the water infrastructure of several states was hit by cyberattacks thought to have originated from Iran.
There were even claims from Iran that networking devices from American and European companies failed during an attack even though they were disconnected from the rest of the world. Aside from these scenarios in active warfare, cyberattacks could also be used in gray warfare, where opponents can inflict maximum damage while retaining plausible deniability, reducing the chances of retaliation.
(Score: 2) by VLM on Thursday August 27, @03:26PM (5 children)
You can play with Codesys Inc stuff for free, so I do. Its really cool being able to do supported CI/CD type development on PLCs and it works well IMHO.
HOWEVER... once you get on the treadmill you can never get off, you're committed until the production line is shut down to keep on patching early and often and continually which is annoying on production lines. If you ever stop upgrading at version 1234 its murphys law there will be a zero day found in 1233 that was patched six years ago in version 1236 and now you're totally screwed.
You can safely attach PLCs to the internet but the labor cost is eternal and high. Oh well I guess.
(Score: 5, Informative) by PhilSalkie on Thursday August 27, @04:31PM (4 children)
And in many production setups, you can't patch control systems software. Ever. There may be a tedious, documentation laden method to do a change to the user software, but to update system firmware? Forget it. It's working, it's commissioned, it's Validated - there's no way to prove that changing the firmware won't introduce some weird breaking behavior, and how will you roll that back?
Most PLCs have whatever firmware they were set up with (many are in ROM and firmware can't be changed without replacing the hardware.)
Codesys will be ready for production in another decade or so - I'm already dealing with products from vendors who integrated it as part of their production hardware, got tired of the endless churn, stopped trying to support it and just say "Here's our hardware, go figure out Codesys yourself, you can probably move the old programs over but don't ask us how." My customers who have that stuff are lining up every project they have with it and budgeting replacement for 6 year old hardware.
Compare that to Mitsubishi PLC hardware, where you have to pay for the programming software, but I can take a program written 40 years ago with a DOS tool, import it into the modern Windows software, read that with the next version of the Windows software, and transfer it to modern hardware - forward compatibility is key with them. It's super refreshing.
(Score: 2, Insightful) by shrewdsheep on Friday August 28, @10:23AM (2 children)
Seems like these devices must never be directly connected to the internet, i.e. have a public ip address, but need to be behind another network layer, let's call it a firewall, that authenticates access. Properly sandboxed and authenticated access to insecure devices is acceptable for legacy applications IMO.
(Score: 3, Interesting) by VLM on Monday August 31, @01:34PM (1 child)
"Edge Gateway" type things are a big business, yeah.
https://store.codesys.com/en/codesys-edge-gateway-for-linux.html [codesys.com]
This one is free.
Very popular in the IoT space for the last decade or so.
You set up precisely one application layer firewall with precisely one firewall rule back to the mothership and it generally just works.
With virtualization its reasonable to shut down the gateway completely if you're not supposed to be doing upgrades during business hours and then turn it on during maint windows.
(Score: 2) by PhilSalkie on Saturday September 05, @03:06AM
The problem is that practically everyone who reads Soylent understands what you just wrote. Practically nobody who's installing these systems knows what a Netmask does. Contractors buy a controller, write some code or hire somebody to write some code, then stick the unit on a static IP on the internets and say "Look, this works great!" Some time later, bad things happen...
(Score: 3, Insightful) by VLM on Monday August 31, @01:37PM
Dropdown and click last time I had to do that.
The future is very unevenly distributed, at least in PLC space. It's randomly between 1970 and 2030 depending on provider and specific feature. Still the wild wild west out there.