Why OT attacks send valid commands, and how to tell a human from a script
The attacks that do real damage in control systems rarely look like exploits. They send commands the controller is built to accept.
When people imagine an attack on a power station, they picture an exploit: malformed packets, a crashed controller, a screen full of code. The attacks that do real damage in control systems usually look nothing like that. They send commands the controller is designed to accept, from a machine it is designed to trust.
The control system does what it is told
A PLC exists to execute commands: open this valve, change that setpoint, trip this breaker. Many industrial protocols were designed for closed networks and carry no authentication at all. Classic Modbus, for example, accepts a write from any device that can reach the controller. Even where newer protocols add security, the controller still trusts the HMI server and the engineering workstation, because that is where the operators work.
So an attacker does not need a flaw in the controller. They need a foothold on a machine the controller trusts. From there, every command they send is valid: the right protocol, the right function code, the right register, from the right source address.
What that looks like in practice
The best-documented public example is the attack on electricity distribution companies in Ukraine in December 2015. The attackers spent months inside the companies' networks, and on the day they opened breakers using the operators' own control software and remote-access tools. Customers lost power for hours. To the substations, the commands were the same as an operator's.
The pattern is the same at smaller scale: malware on an HMI server that writes setpoints, a remote-access session used by someone who is not the vendor, a script left behind by an integrator that keeps running after the project ends. In the ICS security course, one of the labs captures Modbus traffic and then writes to a real controller from another machine on the network. Students are usually surprised by how little it takes.
Why the usual defenses miss it
- Firewalls allow the HMI server to talk to the controllers. That is what they are configured to do.
- Antivirus on the HMI server is often missing, out of date, or limited by the vendor's support terms. A script that uses the HMI's own functions is not malware in the classic sense anyway.
- Network intrusion detection sees a valid command from the usual source. It can flag a new device, a port scan, a firmware download or an unusual function code, and it should be there. A single setpoint write from the HMI server still looks like normal shift work.
- Logs record that the HMI sent the command. They do not record who, or what, was behind it.
The real question: who is at the console?
If the command itself is valid, the question that separates an operation from an attack moves one step back. Did a human operator issue this command at the HMI, or did software issue it in their name? A person working a console behaves differently from a script. In general terms:
- A person acts through the interface. They open a screen, select an object and confirm. A script can send the command without touching the interface at all.
- A person works at human speed and rhythm. A script can issue many commands in a fraction of a second, or at three in the morning when nobody is logged in.
- A person's commands fit the state of the process and the work of the shift. A script's commands are whatever the attacker decided in advance.
No single signal is conclusive, and an attacker who knows them will try to imitate them. That is why the check belongs where the command originates, on the HMI server, and why it has to weigh several signals together rather than rely on one rule.
How SPARTA approaches it
SPARTA (SCADA Protection And Real-Time Alert) is the module ICS Security, the company I founded, built for this problem. It runs on the HMI server as a software module and combines intrusion prevention and intrusion detection with algorithms and artificial intelligence. Its central job is to confirm, to a high degree of certainty, that an input came from a human operator and not from malware.
Several properties follow from where it sits:
- No new components on the control network, and the vendor's warranty is preserved
- Monitoring of the assets on the network: PLCs, RTUs, HMI servers and clients
- Layered protection against attacks from outside and inside the network
- The HMI server itself is stopped from attacking other assets on the network
- It works with GRAPHENE, our passive network IDS, to strengthen detection
- It is compatible with NERC CIP and NIST, and with a range of HMI platforms and controllers
SPARTA is protected by US patent 11,621,972 B2, granted on 4 April 2023, with Ilan Shaya, Shimon Zigdon and Avishay Savir as inventors. Ashdod Port chose SPARTA to protect its control system, as TheMarker reported in 2021.
What to do in any case
Whether or not SPARTA is the right fit for a plant, the same principle applies: make it hard for anything but a person at the right console to change the process.
- Limit which machines may write to controllers at all; give viewers read-only clients.
- Keep the engineering workstation separate, and connect it only when it is needed.
- Use individual operator accounts, not a shared password taped to the screen.
- Whitelist the operations each HMI is expected to perform, and alert on the rest.
- Put limits in the controller logic, so that an extreme setpoint is refused, and keep the safety system independent of control.
- Monitor the network passively, so that the scan or new device that comes before the command is seen.
- Rehearse what operators do when the screen shows something they did not command.
For the record: I invented SPARTA. The architecture designs I write are specified so that any qualified vendor can bid on them.