Charles Marrow
|
Head of Center of Excellence - Embedded Device Security
December 2, 2021

IEC/ANSI 62443 Example 2 - Motors Shaft and Panels

The IEC/ ANSI 62443 series, provides detailed technical control system or control requirements (SRs or CRs) associated with the seven foundational requirements (FRs) described in IEC/ ANSI 62443-1-1 including defining the requirements for control system capability security levels, SL C (control system). These requirements would be used by members of the industrial automation and control system (IACS) community along with the defined zones and conduits for the system under consideration while developing the appropriate control system target SL, SL-T(control system), for a specific asset or system.

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

Example Scenario:This example provides an insight into the convergence between control system, network infrastructure and local access to devices. Buildings, offices and public services may have critical components exposed and provide an open attack surface. This example shows the fundamental requirements to threat model the entire system including any devices that are accessible to the general public by means of direct or remote access methods. The depicted architecture could represent a corporate building, public or private transportation system (train, automobile, or aircraft) or critical infrastructure utilities station.

Requirement:Threat model an existing system architecture to define the scope and controls requirement for introduction into the Risk Assessment for IEC/ANSI 62443-3-2.

Method: 

  1. Select the required SL Trustzone: IEC/ ANSI 62443-sl2
  2. Select and place the required components as per the existing system architecture and allocate accordingly in the SL-2 Trustzone
  3. Once the threat model has been updated, the threats and countermeasures will automatically be generated. Then move to the countermeasures tab to review the applicable controls for the entire system. 
  4. Controls can then be managed on a component basis if required.

Architecture:

DiagramDescription automatically generated
Architecture

Threat Model Output:

450+ Threats have been imported to the threat model, a brief summary of total threats per component is shown in the table below:

 Component  Total Threat Count
 Actuator - Compressor,Motor,Drive  39
 Android, iOS, Windows  56
 Controller - PLC, ECU, ControlServers  46
 Ethernet  24
 Gateway, Router  54
 HMI, GUI, Display  56
 RF Interface - 802.11 Wifi  36
 RF Interface - Bluetooth  35
 Sensor  42
 Sensor - Meters  42
 Switch L2/L3

 53

Grand Total

483

500+ countermeasures and controls have been defined and would be required to comply with SL-2 as per 62443 3-3 & 4-2. A brief summary of total controls per component is shown in the table below:

 Component  Total Threat Count
 Actuator - Compressor,Motor,Drive  47
 Android,iOS,Windows  65
 Controller - PLC, ECU, ControlServers  55
 Ethernet  30
 Gateway, Router  63
 HMI, GUI, Display  65
 RF Interface - 802.11 Wifi  44
 RF Interface - Bluetooth  39
 Sensor  54
 Sensor - Meters  54
 Switch L2/L3

 61

Grand Total

577

Risk countermeasure and weakness summary graphs:

In IriusRisk, these countermeasures include the detailed description of how they should be implemented as well as their implementation status. This supports the user, developer or engineer with the implementation of each individual security control down to a component level. All seven foundation requirements are observed in the threat model output: 

1) Identification and authentication control

2) Use control

3) System integrity

4) Data confidentiality

5) Restricted data flow

6) Timely response to events

7) Resource availability

Summary:This example shows how IriusRisk can be used to quickly and easily determine what the specific countermeasures for a given Security Level should be; and the importance of including the critical infrastructure, local equipment or devices in the threat model during the design or risk assessment phases.