The short answer
Disabling Unused Services
A controller or a device exposes services on its network interface, and each one that is running is an attack surface whether the plant uses it or not: a web server with a default page, a file transfer service left from the factory, a remote shell for vendor diagnostics, a discovery protocol that announces the device, a management protocol with a default community string, a second Ethernet port bridged to the first, a serial port that accepts programming. Disabling the unused ones removes vulnerabilities the utility would otherwise have to track and patch. The method is to list what each device is listening on with the vendor tool or a careful check, compare with what the functional description and the traffic baseline say the plant uses, disable the rest per the vendor procedure under change management, verify from the network that the services are gone, and record the configuration in the baseline so that a firmware update or a vendor session that turns something back on is detected.
Key points
- A running service is attack surface; a disabled one is not. Most devices ship with more running than the plant uses.
- Find out what is listening: the vendor configuration tool, the device web page, the traffic baseline, and a careful port check on devices that tolerate it.
- The plant needs what the functional description and the conversation map say, and nothing else.
- Disable per the vendor procedure, under change management, one device family at a time, with a test.
- Verify from the network that the service is gone; a checkbox is a claim.
- Firmware updates and vendor sessions turn services back on; the baseline and the audit catch it.
What devices run
| Service | Found on | Needed when | Usually |
|---|---|---|---|
| Web server | Controllers, drives, switches, radios, instruments | The web page is the only management interface, or the plant uses the diagnostics | Disable on controllers and drives; restrict to the management VLAN where it must stay |
| File transfer | Controllers, HMIs, historians | Firmware update or file exchange by that method | Disable; enable for the update window |
| Remote shell or terminal | Controllers, switches, gateways | Vendor diagnostics | Disable; console cable for diagnostics |
| Discovery and announcement protocols | Everything | The programming tool finds devices by browsing | Disable where the tool can address the device directly; it announces the device to everyone |
| Network management protocol with read or write access | Switches, radios, UPS cards, some controllers | The monitoring system polls it | Enable read-only with a unique community string from the management VLAN; disable write |
| Unused industrial protocol servers | Controllers that support several protocols | The SCADA polls that protocol | Disable the ones not polled; a controller with Modbus, EtherNet/IP, and a vendor protocol all listening has three doors |
| Second Ethernet port bridged to the first | Controllers and drives with two ports | Ring or daisy-chain topologies | Disable the unused port or the bridging; an open port in a panel is a live connection |
| Serial and USB programming ports | Controllers, HMIs | Field programming | Cannot usually be disabled; protected by the locked panel and the keyswitch |
| Email, cloud, and vendor telemetry clients | Drives, instruments, gateways with cloud features | The utility has chosen the cloud service | Disable; a device calling out is a device that can be called |
| Time and name services as servers | Some controllers and gateways | Rarely | Disable; the plant has its own time source |
Finding what is listening
- 1
The vendor tool
The programming or configuration software usually lists the services and protocols the device has enabled, with checkboxes. It is the first and safest source.
- 2
The device web page
The network or services configuration page, where it exists, lists the same.
- 3
The traffic baseline
Passive discovery shows what the device actually talks and answers; a service that never appears in a month of traffic is a candidate.
- 4
A careful port check
On devices the vendor confirms tolerate it, a connection attempt to the common ports from the engineering workstation, one device at a time, with the process in a suitable state. Never a full scan across the control network.
- 5
The manual
The list of ports and services the device supports, which is what the firewall rule design needs anyway.
Deciding
The functional description says what the plant does with each device: the SCADA polls it on one protocol, the engineering workstation programs it, the monitoring system reads its health. The conversation map from passive discovery confirms it. Everything the device offers beyond that is unused, and the default is to disable it. The exceptions are thought through: a web page that is the only way to read a diagnostic the technicians rely on stays, restricted to the management VLAN; a discovery protocol that the programming tool truly needs stays, with the firewall keeping it inside the zone; a second port that will be used in a planned ring stays, with a note. Each exception is recorded with its reason.
Doing it
- Under change management, one device family at a time, with the vendor procedure and the release notes read for side effects.
- On a spare or a test unit first, with the plant functions exercised: polling, programming, the HMI, any monitoring.
- On production in a window, with the SCADA communication status watched and the engineering workstation ready to reconnect.
- Verified from the network: the disabled service no longer answers from the engineering workstation, and the traffic baseline no longer shows it.
- Recorded in the device baseline and the inventory, so the audit compares against it.
The ones you cannot disable
Some devices offer no way to turn off a service: a controller whose web server is always on, an instrument whose discovery protocol is built in, a drive whose second port cannot be disabled. For those the control moves outward: the firewall and the VLAN restrict who can reach the port, the passive sensor watches it, the credentials on the service are changed from the default and vaulted, and the device is on the list for the next generation, where the specification asks for services that can be disabled and a document that says how.
Frequently asked questions
- Will disabling the web server stop the SCADA from polling?
- No; the SCADA polls on a control protocol, not through the web server. Disabling the web server removes the management page, which the engineering tool replaces. Confirm on the test unit before production, and keep the vendor tool available.
- The controller has Modbus and the vendor protocol both enabled, and the SCADA uses the vendor protocol. Disable Modbus?
- Yes, if nothing polls it, which the traffic baseline confirms. An unused Modbus server accepts unauthenticated writes from anything that can reach it. If a future device needs it, the change record turns it on.
- Is the discovery protocol dangerous?
- It announces the device model, version, and address to the network, which is reconnaissance done for the attacker, and on some devices it accepts configuration changes. Disable it where the programming tool can address devices directly, and keep it inside the zone with the firewall where it must stay.
- How much does this reduce risk?
- Each disabled service removes every vulnerability in it, present and future, from the list the utility has to track. On a fleet of controllers with web servers, file transfer, and three protocols listening, disabling the unused ones removes most of the advisory matches for those devices in a single outage.
Related topics
- 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.
- 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.
- Firewall Rule DesignWriting the rule set for a control network boundary: default deny, one rule per conduit with its reason, hosts not subnets, protocol and port and function, direction and initiator, logging on every rule, and the review that removes forgotten rules.
- Firmware ManagementUpdating the firmware of controllers, modules, drives, HMIs, switches, and radios without breaking the plant: why firmware lags and why it still matters, tracking versions, deciding what to update and when, and the update as a planned outage with a rollback.
- 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.
- Default CredentialsThe passwords printed in the manual: where they hide in a control system, why they are the first thing an attacker tries, how to find every one on site, and the procedure for changing them without locking yourself out.
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.