Reference: IEC/TR 62443-3-1:2009 (ISA-TR99.00.01-2007), Clause 5.9
Related:
Clause 5
|
SR 1.2 Software process and device identification
|
ZCR 3 Zones and conduits
|
FR 5 Restricted Data Flow
|
Modbus TCP
Technology categories: Overview | Cl. 5 | Cl. 6 | Cl. 7 | Cl. 8 | Cl. 9 | Cl. 10
Clause 5 pages: Cl. 5 | 5.1 RBAC | 5.2 Password | 5.3 Challenge/response | 5.4 Token | 5.5 Smart card | 5.6 Biometric | 5.7 Location | 5.8 Password management | 5.9 Device-to-device
Network service authentication between controllers, servers and field devices so that a peer request is accepted only from an authorised device or process — not only from an authorised human at an HMI.
Spoofed masters, unauthorised engineering tools, and rogue hosts injecting writes on protocols that trust any speaker on the wire.
Certificates or pre-shared keys between servers; protocol-native session security where it exists. Many classic IACS protocols have none.
The TR’s assessment: protocols used in IACS generally had inadequate or no network-service authentication. That remains true of unmodified Modbus/TCP and similar. Adding crypto can add latency and break vendor support.
Follow vendor practice where a protocol or gateway authenticates devices. Where it does not, compensate with zone/conduit filtering rather than assuming the protocol will refuse a fake peer. Teaching note: OPC UA, CIP Security and similar exist now; the TR’s gap statement still describes a large installed base.