From PLC Exposure to Engineering Risk

Internet-exposed PLCs are not a new problem. They have been repeatedly identified through internet-wide scanning for years, and the guidance from CERTs and CISA has been consistent: control systems should not be directly exposed to the public internet.  In August, CISA, the NSA, the FBI, the Department of Energy, and the EPA published a joint advisory (AA26-231A) on an active threat to Siemens S7 Series controllers. It follows the familiar pattern: threat actors use internet scanning services to find reachable PLCs, then probe them. What is less familiar is the detail that, according to the advisory, the tooling was generated with AI.

The advisory is about one product family, but the exposure is not a Siemens problem. Controllers, HMIs, and engineering interfaces from many manufacturers show up in these scans. Most of the time they are reachable because of how a system was deployed, connected, and maintained, not because of a flaw in one vendor’s product, which ultimately makes understanding and managing the exposure part of the asset owner/operator’s responsibility.

This blog is about what happens after internet exposed devices are identified. Most OT (Operational Technology) security teams can say whether a controller is reachable and whether a known vulnerability affects it. Far fewer can fully comprehend what an attacker could do to the process through that controller.

Exposure is where the risk starts

A vulnerability advisory describes which products and versions are affected and what to do about them. Your own asset inventory and exposure data tell you whether you run those products and whether they can be reached. Put the two together and you get a list: these controllers, reachable, affected. That is the right starting point, and the basics still apply: remove exposure that has no reason to exist, segment, and control remote access.

What the list cannot convey is consequence. It does not know whether a controller runs an auxiliary pump or the pressure control on a reactor, and a CVSS score treats the two the same. In IT, impact can usually be derived from the data a system holds and the systems it connects to.  In OT, a controller participates in a control system that ultimately influences physical equipment and process behaviour. What an attacker can do with it is limited by that equipment and by the protections the process was engineered with.

 A vulnerability-led view can therefore miss material risk. The advisory describes actors getting in with default or weak credentials and then reading from and writing to controller logic. None of that needs an unpatched flaw.

The path from an exposed controller to a physical consequence has mainly six steps. Exposure and vulnerability tools cover the first two. The rest depends on engineering and contextual knowledge.

Steps 3 to 6 are where the consequence is decided: what logic the controller runs, which equipment it commands, what process depends on that equipment, and what happens to production, plant, and people if that process is pushed outside its limits. How far an attacker gets along the path depends on their objective, their capability, and the maturity of the target’s own defences.

From cyber asset to engineering reality

Answering the consequence question requires information that usually sits outside the security team: the controller’s configuration and logic, the I/O and tag mapping that ties each signal to a physical device, P&IDs (piping and instrumentation diagrams) and equipment relationships, process data, and the interlocks and safety instrumented functions (SIFs) that protect the unit. Automation and process safety engineers hold most of this knowledge. Security tools see none of it, and engineering systems rarely carry any notion of cyber exposure. Neither side can answer the question alone.

This is the gap we describe as Engineering Intelligence for Cyber-Physical Systems: connecting the cyber asset to the engineering function, the process that depends on it, the protective barriers around it, and the potential consequence.  For a specific exposed controller, it lets a security analyst ask what an attacker could influence and what stands in the way, and get an answer grounded in the plant’s own documentation instead of an assumption.

Take two controllers that look identical from the network: same model, same firmware, same vulnerability, same reachability.

PLC A controls an auxiliary pump. If it is compromised, the effect is probably limited and contained, provided nothing critical depends on that pump, which only engineering context can confirm. PLC B controls a critical process function with interlocks and safety instrumented functions around it.  The potential for operational or safety consequence may be materially higher, and how much higher depends on whether those protections are independent of PLC B and still working.

Nothing in an IP address, a vulnerability identifier, or a typical asset inventory separates the two. The difference sits in how the controller, the equipment, the process, and the protection around it relate to each other.

That does not make PLC A unimportant. It is still a foothold inside the OT network, and an attacker who can read its logic and configuration learns something about how the plant runs. It means the two should not sit at the same place in the remediation queue.

Do the barriers hold?

Process safety already has a way to describe this: the bow-tie model. At the centre is the top event, the point where control of the process is lost, for example a loss of containment. Threats sit on the left and consequences on the right. Preventive barriers sit between the threats and the top event, and mitigating barriers sit between the top event and the consequences. In a cyber scenario, the threat is an attacker using the exposure to reach the controller, and the question is what lies between that and a top event.

The barriers include access controls, control logic and interlocks, safety instrumented functions, physical safeguards such as relief devices, and operating procedures. They are not equally dependable against a cyber threat. Process safety studies typically assume protection layers fail independently of each other. A cyber attack is a common cause that can break that assumption. An interlock implemented in the same PLC the attacker controls is not an independent layer, and a   safety system that shares critical resources, engineering access, or other dependencies with the compromised control environment may also have less independence than its functional role suggests. The barriers most likely to hold whatever an attacker does are the ones that do not depend on the control system at all, such as mechanical relief devices.

A barrier on paper is not the same as a barrier in service. Whether it is correctly configured, currently bypassed for maintenance, proof-tested, and relevant to the particular attack path can only be established from evidence in the engineering environment. That evidence is often held by a different team from the one looking at the exposure.

Breaking the path

The advisory raises a timing question as well as a technical one. It describes threat actors using AI to generate exploitation scripts from publicly available information. . It does not say attackers are using AI to work out what a controller does to a process. That is a prediction, not something the advisory reports, but it is a plausible one: the step is mostly about reading documentation and making sense of an unfamiliar system, which is work AI tools are good at. It has historically needed plant-specific engineering knowledge and time. If that time shrinks for attackers, defenders have less of it, and the aim should be to make the connection from asset to consequence before an incident rather than during one.

The practical steps are not exotic. Remove exposure that has no reason to exist. Where something must stay reachable, make it a harder target: restrict which hosts can connect, remove default credentials, disable services it does not need, and apply firmware updates where the plant can accept the outage. Patching helps but cannot carry the whole load. Many PLCs cannot be updated without stopping the process, some cannot be updated at all, and as the advisory shows, access does not always depend on a vulnerability.

Exposure will also come back. Legacy equipment, remote and unmanned sites, third-party access, and ongoing IT/OT integration all see to that, even in well-run programmes. So, every exposed controller needs an assumed breach questioning: if this were compromised anyway, what is the path to a top event, and would the barriers on it hold?

 A count of exposed PLCs measures how much work the security team has. The number and effectiveness of the independent barriers between an exposed PLC and a top event is a more meaningful indicator of engineering risk. The first number is easy to produce. The second usually is not. And when nobody can say with confidence whether those barriers are intact, independent, and effective, that uncertainty is itself a risk finding.

Book a demo with Indurex and see how Safety, Cybersecurity, and Agentic AI come together to build greater resilience in CPS: https://www.indurex.ai