We have tightened access to PLC programming. The engineering project is protected, and downloading a program is restricted. If an attacker still reaches the production cell, could they affect production through the field devices’ own functions?
Looking only at the PLC can leave an important route out of the assessment. The controller’s program matters, but so do the communication settings and commands accepted by the devices it talks to. If someone can change those without authorization, the system may behave differently even though the PLC code stays the same.
Where does a reachable device check whether an incoming operation is authorized?
Does the device enforce the engineering software’s permissions?
We usually commission, discover, address and maintain devices through a vendor application. That habit can make an operation seem possible only through that application. The device, however, receives the request at its own protocol interface. A security assessment needs to examine that interface as well as the restrictions presented to the application’s user.
For example, changing a setting through an application menu may require an administrator account. That alone does not establish that another network function requires the same identity to change the same setting. Each access path needs its own check.
The trust boundary sits between being able to reach a device and being authorized to operate on it. A valid protocol request is not necessarily an operation approved by the organization. If the target does not adequately verify the sender’s identity and permission for that operation, a position on the network may grant more authority than we expect.
When can network access become effective authority?
A device being visible on the network does not mean all its settings can be changed. Several conditions must coincide: the source must reach the relevant interface, the operation must be supported, the device must accept it in its current state, and no device or network control must prevent unauthorized use.
Authentication and authorization answer different questions:
- Authentication: Is the sender really who it claims to be?
- Authorization: Is that sender allowed to perform this operation on this device?
A familiar MAC address is not authentication. An authenticated workstation need not be permitted to perform every operation on every device. If an authorized workstation is compromised, its valid identity may also be used beyond the intended maintenance scope.
Encryption can protect the conversation’s confidentiality; it does not, by itself, decide who may do what. Authentication, operation permissions and message integrity need separate consideration. PROFINET’s security approach also treats these as distinct protection objectives. PI, PROFINET security approach
A concrete example — PROFINET DCP
DCP supports discovery, device naming and IP configuration in PROFINET. These commissioning functions can directly change a device’s communication settings if it accepts the write.
If local Ethernet access is available, the target accepts the relevant DCP write, and no device or network control blocks the operation, the device name or IP configuration may be changed. Siemens’ SCALANCE LPE9403 V4.0 manual explicitly describes changing these settings from the same local network without authentication. In that manual, default write access also depends on the delivery/reset state; otherwise, writing is not allowed by default. This is documented product behavior, not evidence that all field devices use the same settings. Siemens, DCP access rights, §7.9.3
Siemens ProductCERT bulletin SSB-201698 also describes service disruption through misuse of the relevant DCP configuration and reset functions. Its scope covers products that do not comply with PROFINET Security Class 1 and devices supporting the relevant functions. Siemens ProductCERT, SSB-201698
A path inside the cell that does not go through the PLC
Engineering workstation → cell switch → field device. The PLC program is unchanged.
The project expects the device name dolum-io-01.
Assume the engineering workstation has been compromised. The orange path is workstation → cell switch → target device. The workstation has local Ethernet access and sufficient privileges to send DCP. If the target accepts the write, the change takes place directly in its configuration.
This path does not require changing the PLC program, taking over the PLC or using its engineering interface. The vendor’s PLC programming application is not essential either: independent applications can speak DCP. Independent DCP implementation documentation
DCP runs directly over Ethernet rather than through IP routing. The conversation shown does not cross the cell boundary firewall, so IP rules on that external connection do not control this path. VLANs, port isolation and local Ethernet filters can change reachability; sharing a switch is not sufficient by itself. The purple SPAN link matters for the same reason: a sensor watching only the uplink may miss the conversation.
What changes if the PLC code stays the same?
The PROFINET device name helps the controller find the device it expects; IP assignment can also depend on that name. If the project expects dolum-io-01 but the target reports another name, the expected match may fail even though the physical device has not moved. PI, addressing and connection startup, §2.5–2.6
No new PLC code has been downloaded. The configuration on which device communication depends has changed. Whether the effect appears during an existing connection or when a connection is re-established depends on device behavior. The process consequence of a communication loss also depends on the controller’s fault response, substitute values and plant design. A name change does not instantly stop every production line.
Where is the requested value in the packet?
The source workstation can create a DCP Set request understood by the target. Intercepting and altering an existing packet is not a prerequisite; a new request can carry the desired configuration value. The Ethernet header’s source and destination MAC addresses identify the communicating endpoints. The DCP block identifies the setting and the value requested.
On the diagram, 0x8892 is the PROFINET EtherType; it does not distinguish DCP by itself. FrameID: 0xfefd identifies the DCP Get/Set path. ServiceID: Set and ServiceType: Request indicate a configuration request. Xid correlates the response; it is not proof of identity or permission.
The requested change is the Device properties / Name of Station block’s NameOfStation: dolum-io-02 value. The expected project name, dolum-io-01, is not carried in this request; the new name is. BlockQualifier requests permanent storage. The new name occupies offsets 32–42 in this example; different block ordering, VLAN tagging or encapsulation can change those offsets.
This synthetic request was read from a file using tcpdump 4.99.4, with DCP fields decoded by TShark 4.2.2. In that version, tcpdump shows the Ethernet summary; detailed fields come from TShark. Wireshark, DCP field reference
The packet means “change this device’s name to this value.” Being able to create the request does not establish that the change was accepted. The decisive check is at the target: does it permit this source to write? The operation result in the response and the name subsequently reported by the device must then be checked.
What if the configuration is reset instead of renaming the device?
What happens if a field device loses the settings it needs to communicate while the PLC program remains unchanged? A broken naming match may become a need to recommission the device after a reset. The duration and production consequence depend on what was erased and how the system restores it.
DCP’s scope extends beyond names and IP addresses. Siemens ProductCERT also describes misuse of Reset-to-Factory during operation on relevant devices. If local Ethernet access is available, the device accepts that reset in its current state, and no control prevents unauthorized use, this can be another route to affecting a field device without going through the PLC. Siemens ProductCERT, SSB-201698
Reset scope is not a single category. ABB’s DCP reset definitions distinguish the following:
| Reset scope | Examples of affected data |
|---|---|
| Communication | Station name, IP configuration and port data. |
| Application | Persistently stored module/submodule data, such as I&M maintenance and identification records. |
| Engineering | Configuration or application program loaded through the engineering system. |
These definitions do not mean every device supports every mode. The product, firmware and active security profile matter. Resetting engineering data also does not mean DCP can upload any PLC program we choose. The target in this scenario is the field device; the PLC program is untouched. ABB, DCP reset modes
Which stored data can be reset over the network, and how does the device operate without it?
Does the same question arise with other protocols?
Consider communication with a drive using Modbus. The protocol has functions for writing device data; Modbus Organization also uses drive commands as an example. If a writable value actually affects device behavior, the control source is configured accordingly, and no control prevents unauthorized writes, direct communication with the device can provide another route to an operational effect. The device’s data mapping, operating mode and access settings determine what can be written and whether it takes effect. Modbus Organization, protocol use cases
DCP’s local Ethernet access is different from Modbus TCP’s IP reachability; the paths requiring network controls differ. The common question is who is authorized to perform an operation accepted by the target.
Modbus/TCP Security also defines mutual certificate authentication and role-based operation permissions implemented by the product. The protocol name alone therefore cannot establish that unauthorized writes are possible. The protocol’s security profile, any security class, the product, firmware and active configuration must be examined together. Modbus/TCP Security, §6 and §8.4
How should we assess a cell through this lens?
When assessing a cell, consider the accepted operation, the source that reaches it and its consequence for production together:
- Target and function: Which discovery, commissioning, configuration or operational functions are reachable? Which only read, and which change state?
- Identity and permission: How does each interface verify the source, and which operations does it permit? Does a read-only mode, role or source restriction cover the relevant path?
- Lifecycle: Does write access change during commissioning, device replacement or reset? Are controls checked again after maintenance?
- Observation and result: Is the request within the maintenance scope? Did the target accept it, and did its subsequent state change? Is the production effect corroborated by controller and process records?
Legitimate maintenance traffic needs consideration too. A PROFINET controller can, for example, assign names automatically using a defined topology. Seeing a configuration write is not, by itself, evidence of an attack. Read the source, target, operation, new value and maintenance scope together. PI, automatic name assignment
Protecting the PLC program is an important control. The remaining trust needs to be examined at the field devices’ own interfaces: which devices can be reached from inside the cell, and which changes do they allow the source to make?
Technical note — details of the DCP example
Does a power cycle restore the name?
It depends on how the name was assigned. In HMS’s PROFINET devices, a temporarily assigned name is lost on a power cycle, while a permanently assigned name remains in memory. Restarting does not restore the previous name after a permanent write. HMS, temporary and permanent device names
In the Set example above, BlockQualifier requests permanent storage of the new name. If the device applied that write, cycling power may not be enough. Compare the name the device currently reports with the name expected by the project. A persistence choice in the packet does not, by itself, prove what the device stored.
Write access after a reset
The DCP reset definition ResetAndRestoreData also covers restoring installed software to the factory image. Availability and acceptance conditions must be checked on the device. A definition’s existence does not establish that firmware can be changed on every product. The permanent/temporary storage interpretation of a name write does not carry over to a reset block; the field here describes reset scope. ABB, DCP reset modes
Restoring factory settings may also change DCP access. For example, in SINEC OS v3.0, DCP read/write access is enabled in setup mode on delivery or after a reset. It becomes read-only when a new password is assigned at the first administrator login or a configuration file is loaded. This behavior belongs to that product and version; check which settings return on your device. Siemens, SINEC OS v3.0, §12.2.2.1
Before switching to read-only mode, establish who will name the new device. Automatic naming by the controller is also a write operation; disabling access may affect that maintenance step.
What other DCP functions exist beyond names and IP addresses?
Siemens’ bulletin includes DHCP configuration among the settings that may be changed on supporting products. Hilscher’s documented Set Signal activates the identification LED. Finding a device in the cabinet is different from writing a process setting. A field appearing in a discovery response does not establish that it is writable. Siemens ProductCERT, Hilscher, DCP Set Signal, §3.2.7
A response arrived; did the device name change?
The relevant write was rejected in this example.
An explanatory model of the article’s synthetic responses. After a positive block response, the device’s reported name must still be checked.First, identify the request to which the response belongs. Read the source/destination MAC addresses, service, Xid and time together, then inspect the result for the relevant option/suboption.
Concluding that the name changed from the Response Success header alone would be premature. The first response in the figure has that header, but BlockError in the Control/Response block says In operation, SET not possible: the device rejected the write. The second block result is Ok, indicating a positive response for the relevant operation. Wireshark, DCP dissector
If the block says Ok, the next check is the name reported by the device. If the project expects dolum-io-01 but the device reports dolum-io-02, we can see that the configuration differs from the project. Its communication and process consequences must be followed through controller diagnostics and process records.
Wireshark’s pn_dcp filter can isolate these conversations. The following distinction helps when reading the fields:
| Field | What it means in this example |
|---|---|
NameOfStation | The new name requested in the write. |
BlockQualifier | A request for temporary use or permanent storage in name/IP writes; the same interpretation does not apply to reset blocks. |
BlockError | The response result for the relevant operation. |
| Subsequent device name report | A comparison between the expected name and the actual state. |
An absent response does not establish that the device rejected the request. Mirroring may cover only one direction, a packet may have been lost, or the device may not answer the write request. Closing the investigation before checking the setting through another observation would be premature. Wireshark, DCP field reference