IEC/ANSI 62443 Example 4 - OT Communications Protocols

Example xml: https://github.com/iriusrisk/IriusRisk/tree/master/Examples

Example Scenario:

Considering a previously secure process control environment, generally, information could be transferred using insecure or un-encrypted protocols which stayed within the confinement of the plant process area, in effect air-gapped from public networks. Now with the transition to utilizing remote cloud services to increase production or efficiency by means of utilizing extensive computational resources to analyze the variations in process data, the information exchanged is being transported across publicly accessible networks. Insecure protocols used by Operation Technology (OT) include but are not limited to, HTTP, Telnet, and Modbus for example. Devices made good use of these communications protocols and have served their purpose during the device's lifecycle. These protocols are still very fundamental communications methods and will be used indefinitely. In this example, a typical RS485 port equivalent interface using the modbus protocol to communicate will be reviewed for vulnerabilities and identify associated controls. In practice, the modbus data would be encapsulated inside an ethernet packet and transported via the network to the cloud.

Requirement:

Threat model a RS485 modbus interface to determine any relative controls required to secure the information in transit.

Method:

Select the required SL Trust zone: IEC/ ANSI 62443-sl4
Select and place the required RS485 component in the SL-4 Trust zone
Once the threat model has been updated, the threats and countermeasures will automatically be generated by the internal IriusRisk rules engine. Then move to the countermeasures tab to review the applicable controls for the subject interface.
Controls can be managed on a component basis if required.

Basic Architecture:

*Note: The above diagram is a basic overview representation, various standard network elements, and system components are not shown in the diagram.*

‍

Threat Model Output:

7 applicable Threats have been generated and imported to the threat model, these are as follows:

Subject Weakness and vulnerability Overview:

Fundamental component weaknesses corresponding to Threats no. 3, 5, and 6 include but are not limited to:

CWE-5: J2EE Misconfiguration: Data Transmission Without Encryption. An attacker may be able to intercept and read un-encrypted or plain-text data sent over a network. CWE-693: Protection Mechanism Failure. Incorrect functionality or non-existent use of an Intrusion Detection System. CWE-1100: Insufficient Isolation of System-Dependent Functions. The product or code does not isolate system-dependent functionality into separate stand-alone modules.

Controls Overview:

13 controls have been defined and would be required to comply with SL-4 as per 62443 3-3 & 4-2. The controls corresponding to Threats no. 3, 5 & 6 are considered as critical contributors to the subject OT comms Protocols, a non-exhaustive list of related controls are as follows:

In IriusRisk, these countermeasures are aligned to IEC/ ANSI 62443 and include a detailed description of how they should be implemented as well as the implementation status. This example pays special attention to the requirements of encrypting data in transit, using Detection systems (Correctly configured for the relative information to be transmitted), and ensuring fundamental components of the network or plant can continue to function safely even with degraded functionality. This supports the user, developer, or engineer with the implementation of each individual security control down to a component or product level.

‍

Summary:

This example shows how IriusRisk can be used to quickly and easily determine what the specific countermeasures for an industry-standard industrial communications protocol should be; and the importance of taking it into consideration during the design, threat model, or risk assessment phases.

‍