The short answer
Program Change Detection
Controllers can tell you when their program changes: most report a change counter, a program checksum, or a signature that the SCADA can poll and alarm on when it moves, and many keep an audit log of online edits and downloads with the user and the time. Version control products upload each controller on a schedule, compare it with the stored project, and record the differences with who and when. Keyswitch and mode monitoring alarms when a controller is placed in program or remote-program mode. Passive network monitoring recognizes the vendor protocol messages that carry a download or an online edit and alerts as they happen. Each catches something the others miss, and the practice is to run at least two: the signature alarm in the SCADA, which costs one tag per controller, and either scheduled compares or network monitoring. A detection is matched against the change records, and one that matches nothing is treated as an incident.
Key points
- Poll the controller change counter or signature from the SCADA and alarm when it changes; one tag per controller.
- Scheduled uploads and compares record what changed; the signature alarm only says that something did.
- Controller audit logs name the user and the time where the platform keeps them; forward them.
- Mode and keyswitch monitoring catches the controller being opened for editing, before the edit.
- Network monitoring sees the download on the wire, whoever sent it and whatever the controller logged.
- A detection that matches no change record is an incident until it is explained.
Why it matters
The attacks that have damaged physical processes did it by changing what the controller does, and the controller did exactly what its new program said. An unauthorized program change is also what a well-meaning technician does at 2 a.m. to get a pump running, and what an integrator does during a support session that nobody recorded. All three look the same to the process; the difference is whether anyone knows. Detection turns a silent change into an event with a time, which is the beginning of both an investigation and a proper change record.
The methods
| Method | What it catches | What it misses | Cost |
|---|---|---|---|
| Change counter or signature polled by the SCADA | Any change to the program or configuration that changes the value, within one poll | What changed and who; some platforms do not change the value on every kind of edit | One tag and one alarm per controller |
| Scheduled upload and compare | Exactly what changed, in the program, with a record | Changes made and reverted between compares; the compare interval is the blind spot | A version control product, or hours per month by hand |
| Controller audit log | Downloads, online edits, mode changes, with user and time where the platform supports authentication | Platforms without logs or without user identity; logs that are overwritten | Configuration and log forwarding |
| Mode and keyswitch monitoring | The controller placed in a mode that permits editing | Edits on platforms that allow online changes in run mode | One tag and one alarm per controller |
| Passive network monitoring | The download or edit message on the wire, with the source address, in real time | Edits made through a serial port or a USB cable; encrypted vendor protocols | A monitoring sensor and someone to watch it |
| Physical access control | Who was in the room with the controller | Network changes | Door alarms and a log |
The signature alarm
Most controller families expose a value that changes whenever the program or the configuration changes: a change counter that increments, a checksum of the program, a signature computed at download, or a timestamp of the last edit. The SCADA polls that value like any tag, stores the expected value, and raises an alarm when the live value differs. The alarm says which controller and when, to the poll interval, and it is the cheapest detection there is. It is configured once per controller, its expected value is updated as the last step of every approved change, and the alarm goes to the same list as process alarms so that it is seen. On platforms where some edits do not change the value, the scheduled compare covers the gap.
When a detection fires
- 1
Confirm
Which controller, what time, which method. Read the controller audit log and the SCADA event log for the window.
- 2
Match
Against the open change records and the vendor session log. A change record with that controller and that window explains it; update the baseline and close the record.
- 3
Ask
The engineers and the integrator, if no record matches. An undocumented but legitimate change is recorded now, and the process that let it go unrecorded is fixed.
- 4
Investigate
If nobody made it: upload the program, compare with the baseline, and read exactly what changed. Assess whether the process is at risk. Check the network logs for the source of the download. Treat it as an intrusion until proven otherwise.
- 5
Decide
Revert to the baseline if the change is unexplained or harmful, with the process in a safe state and the reversion itself under a change record. Rotate the controller credentials. Preserve the evidence.
- 6
Close
The record, the baseline update, and the lesson: what allowed the change and what will detect the next one sooner.
What to do about controllers that cannot be watched
Older controllers report no signature, keep no log, and change mode with a keyswitch nobody monitors. For those, the scheduled upload and compare is the only program-level detection, and the surrounding controls carry the rest: the controller reachable only from the engineering zone, the programming software on a workstation with individual logins and logging, physical access to the panel controlled and logged, and network monitoring that sees the vendor protocol. When the controller is replaced, program change detection is on the specification.
Frequently asked questions
- The controller checksum changes when an operator changes a setpoint. How do I separate that?
- Some platforms include data in the checksum, so setpoint writes change it. Use a value that covers the program only, if the platform offers one, or move setpoints to a data area excluded from the signature, or accept that the alarm on that platform covers data as well and rely on the scheduled compare to tell program from data.
- Can the SCADA itself make the change and trigger the alarm?
- The SCADA writes data, not programs, so it should not change a program signature. If it does, the signature includes data and the answer above applies. A SCADA that can download programs to controllers is a design that should be reconsidered.
- How fast should detection be?
- The signature alarm is as fast as the poll, seconds to a minute; network monitoring is real time. The scheduled compare is hours to a month. For the controllers whose compromise would hurt people or the environment, real-time detection is worth the cost; for the rest, the poll and a monthly compare are proportionate.
- What is the first thing a small utility should do?
- Configure the change counter or signature alarm on every controller that reports one, this week; it costs nothing but an hour. Then start a monthly compare of the critical controllers against the stored project with the vendor tool, and put the mode and keyswitch status on the HMI.
Related topics
- Controller Program IntegrityKnowing that the program in the controller is the one that was approved: checksums and change counters, the scheduled compare against the trusted backup, signed and protected projects, what an unexplained difference means, and making the check routine.
- Configuration BaselinesA known-good record of how every part of the control system is configured, captured at acceptance and kept current through change management: what to baseline, how to capture and store it, how to compare on a schedule, and what an unexplained difference means.
- Change Management for OTA change process sized for a utility control system: what counts as a change, the request with risk and rollback, owner approval, the window, backup before and verification after, the baseline update, the emergency path, and the record.
- Controller Mode Switch and KeyswitchThe physical switch on the front of a controller: what RUN, REMOTE, and PROGRAM mean, why most controllers are left in REMOTE and why that matters, a policy for a utility, how mode is monitored and alarmed, and what to do on platforms with no keyswitch.
- Passive DiscoveryFinding out what is on a control network by listening rather than probing: why active scans are risky around older controllers, how a mirror port feeds a sensor, what the traffic reveals, the blind spots, and how the sensor becomes continuous monitoring.
- Controller HardeningWhat can be locked down on a PLC or RTU: keyswitch and mode, credentials, unused services, access lists, firmware, and the engineering workstation that is the real target.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.