Restrict the type of connections and available data for 3rd party interfaces. The connections and/or data interfaces should be well defined and restricted to only allow read/write capabilities for the required data transfer. 

Guidance

In some cases, due to long cable runs or a large exchange of data, interfaced data connections present a better business case than hard-wired data exchange between two separate parties. 

The following guidelines should be considered and followed where practical when designing and implementing a third-party data exchange interface: 

• Use a dedicated communications module, either directly connected to the 3rd party PLC or data exchange equipment or use dedicated network equipment physically segregated from each party’s core network.
• The MAC address of connected devices is typically available in system variables for any ICS Ethernet-enabled device, making it possible to verify device identity with a multi-factor approach (IP address + MAC maker code = trusted device). This practice is certainly not foolproof, as MAC & IP addresses can be spoofed, but it serves to raise the bar in terms of communications between trusted ICS systems and devices.
• When selecting a protocol for 3rd party interfaces, choose a protocol that minimizes the ability of the third party to write data to the owner’s system.
• Choose a connection method and connection port which prevents the 3rd party from being able to configure the owner’s PLC or data exchange equipment.
• The third-party should not be able to read or write to any data that has not been explicitly defined and made available.
• Use a watchdog timer for monitoring communication so that commands are not sent to a PLC in fault mode.
• Serial Connection: Use a dedicated communication module for each 3rd party interface with a restricted array of data. Ensure the owner’s side of the connection is the Initiator and that the third party is the Responder.
• Ethernet/IP: Some PLCs allow for communication modules to function as a firewall and can perform Deep Packet Inspection (DPI), or restrict communication module interfaces to limit the data exchange to a predefined subset. If these features are available, and an Ethernet/IP protocol is in use, ensure the features are enabled and configured.
• When operational or contractual requirements prevent the owner from accomplishing the previous items, consider using a separate “data concentrator” (aka proxy/DMZ) PLC in order to buffer the data and protect the owner from unwanted writes/programming from the 3rd party. Ensure the backplane of this PLC cannot be traversed from the 3rd party network. 

Example

• Pipeline or Lease Automatic Custody Transfer (LACT) units which transfer and meter hydrocarbons or water exchanged between an upstream producing or pipeline company and a midstream pipeline company with network or serial interfaced connections sharing metering, state, and permissive information between companies.
• Regional potable water purveyor (importer) sharing turnout water flow rate being delivered to a local municipality’s water plant. 

Why? 

References

What’s next?

In the next article of The Top 20 Secure PLC Coding Practices series, you will find out about defining a safe process state in case of a PLC restart.

Do you require help with secure coding of your PLCs?

If you have any questions or require help in securely coding your PLCs, please contact SEQRED.

SEQRED specialises in providing bespoke OT and IoT cybersecurity solutions.
Our services cover such areas as Critical Infrastructure Protection, Cloud Services Security or Audits, and Threat Intelligence. For a full list of our services visit our services page – https://seqred.pl/en/services/

About this article

You can download the full copy of the Top 20 Secure PLC Coding Practices by clicking here.

The series of these articles is written under the following license:

Powiązane wpisy

Dodaj komentarz