Hacking OT Is Like Going Back In Time
On 27 August the NCSC published an alert warning about increased targeting of operational technology across multiple sectors, including in the UK. The important part was buried in fairly restrained language: some of this activity has already caused limited real-world disruption. Not modelled disruption or a tabletop exercise, but real systems being affected.
I have spent the last ten years working across UK critical infrastructure, from defence and energy to factories running robots, production lines, packing systems and building management systems. As a penetration tester, OT is probably my favourite environment to test because walking onto a plant network can feel like going back in time. I have exploited EternalBlue on live production networks more than once in the last few years. MS17-010 is nine years old and most IT teams now regard it as ancient history, but on a factory floor you can still find it sitting on an engineering workstation that nobody wants to patch because it is considered part of the machine rather than part of the network. I have connected to VNC and found myself looking directly at a live industrial process with full mouse and keyboard control, with no password or prompt. I have also found vendor default credentials, printed in the manual and shared across every unit of that model, still working years after commissioning.
None of this is particularly clever, and that is precisely the problem.
The boring stuff gets you
Cyber security has a habit of becoming distracted by whatever makes a good headline: juice jacking, evil twin WiFi, Flipper Zeros. Meanwhile, the things that repeatedly cause real problems are far less interesting: exposed services, reused passwords, default credentials, old VPN appliances and unpatched systems sitting on the edge of networks. That is why the NCSC alert is worth paying attention to. Its recommendations are remarkably ordinary: remove control systems from the public internet, replace default credentials and keep the systems protecting the OT boundary patched and supported. There is no exotic ICS exploit required when somebody has accidentally left VNC exposed to the internet.
One of the difficulties with OT security is that the usual IT answer of "just patch it" often is not realistic. You can walk onto a production floor and find machinery worth millions of pounds that still performs its job perfectly. The controller works, the mechanics work, but the HMI may be running an operating system that stopped receiving security updates years ago. Changing it may require vendor approval, a maintenance window or, in the worst case, replacing part of the production line.
I have a lot of sympathy for the engineers running these environments. They are measured on uptime and production, and nobody is going to shut down a functioning line for two weeks because somebody from cyber security has pointed out that Windows 7 is old. So you work around that reality. You isolate what cannot be patched, control who can reach it, secure the boundary, remove default credentials and monitor the traffic around it. Old does not have to mean exposed.
About that air gap
The NCSC makes another important point: never assume OT is inaccessible from the internet without actually verifying it. I have tested plenty of supposedly air-gapped environments and I am still waiting to find the perfect air gap. Instead, you find the vendor support connection installed during commissioning and never removed, an engineer's laptop connected to both networks, a firewall rule created for a project five years ago and forgotten, or a reporting server sitting between IT and OT because management needs production data. Sometimes you simply find hardware with connectivity nobody realised it had.
None of those things necessarily appear on the network diagram, and that gap between the diagram and reality is where a lot of the interesting stuff lives.
Monitoring OT has its own problems as well. You cannot simply install the same EDR agent used across the corporate estate onto a PLC or RTU. Some engineering workstations are too old to support modern tooling, and vendors may prohibit third-party software entirely. The network traffic is different too: industrial protocols such as Modbus, PROFINET, EtherNet/IP and S7comm are not necessarily understood by tooling designed to monitor a corporate network. The result can be an environment where activity that would immediately generate alerts in IT produces very little noise in OT.
There is an upside. Industrial networks are often extremely predictable. Machines generally talk to the same machines, using the same protocols, doing the same things every day. Once you can see that traffic properly, unusual behaviour tends to stand out.
So what do you actually do?
Start with visibility. Find out what you really have, what can reach it and what it can reach, rather than relying entirely on the network diagram. Then deal with the easy wins: remove directly exposed PLCs and HMIs from the internet, change vendor default and shared credentials, harden and patch the firewalls, VPN appliances and gateways protecting the OT environment, disable unnecessary remote programming and monitor the traffic crossing the IT/OT boundary. Make sure you can recover as well. Backups of controller logic and configurations are only useful if somebody knows how to restore them.
None of this requires replacing the production line.
Testing OT is different
There is one final point worth making: you cannot simply point a normal IT penetration testing methodology at a production network. An aggressive scan that is harmless against modern servers can crash old industrial equipment. Credential testing can lock an operator out of an HMI. Fuzzing an industrial protocol can stop production or, potentially, cause something physical to happen.
Our approach is therefore conservative. We start passively wherever possible, and the IT/OT boundary and engineering DMZ normally take most of the active testing. Anything active inside the control network is agreed in advance, performed against specific systems and, where necessary, carried out during a maintenance window with engineering staff present. If there is a lab or spare equipment, that is where the aggressive testing belongs. Extreme care is not a disclaimer added to an OT penetration test. It is part of the methodology.
Where I would start
If the NCSC alert has landed on your desk, I would not begin by asking whether every device is patched. Ask something simpler: what can actually reach our OT environment, and how do we know?
Answering that question does not require touching a production controller, and it will probably tell you more about your real exposure than another spreadsheet of patch versions.
At Tarian Labs we carry out OT exposure reviews and IT/OT boundary assessments with exactly that in mind: establish what is genuinely reachable, test the paths into the environment and produce a remediation plan that recognises one fairly important constraint. The factory still has to run.
What can actually reach your OT environment?
A scoping call takes thirty minutes and ends with a fixed-price proposal. Passive first, and nothing active inside the control network without your sign-off.