IEC/ANSI 62443 Example 1 - SL-A to SL-T Basic Component

IEC/ANSI 62443 Example 1 - SL-A to SL-T Basic Component

The 62443 series, provides detailed technical control system or control requirements (SRs or CRs) associated with the seven foundational requirements (FRs) described in ISA-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: Current component (RS-485 Port) security measures only achieve SL1 (SL-A Achieved Security Level), as per mandatory project installation zone requirement the component must be compliant with SL2 (SL-T Target Security Level).

Requirement: Threat model the component for both SL-1 & SL-2 to determine the control measures required to achieve the target security level.

Method:

1. Select the required SL Trustzone: IEC/ ANSI 62443-Sl1
2. Select the component to be considered, in this case, the Serial Interface RS485 and allocate it to the SL-1 Trustzone
3. Repeat this process for the SL-2 Trustzone.
4. Once the threat model has been updated, the threats and countermeasures will automatically be imported. Then move to the countermeasures tab to review the applicable controls for both SL-1 & SL-2.

Set the status of the SL-1 currently active controls to “Implemented”. This will provide the remaining controls to achieve the SL-2 as “Required” This last step effectively says that the component has already achieved SL-1 compliance and is seeking SL-2 compliance.

Architecture:

Threat Model Output:

To achieve SL-2 the following CR’s (Or SR’s in the case of 62443-3-3) must be implemented or disregarded corresponding to the RS-485 Component:

• CR2.11 RE 1 - Assets shall provide the capability to create timestamps that are synchronized with a system wide time source.
• CR3.1 RE 1 - The asset shall provide the capability to employ cryptographic mechanisms to recognize changes to information during communication.
• CR6.2 - Assets shall provide the capability to be continuously monitored using commonly accepted security industry practices and recommendations to detect, characterize and report security breaches in a timely manner.
• CR7.1 RE 1 - Assets shall provide the capability to maintain essential functions when operating in a degraded mode as the result of a DoS event.
• CR7.8 - The asset shall provide the capability to report the current list of installed assets and their associated properties.

In IriusRisk, these countermeasures include the detailed description of how they should be implemented as well as their implementation status:

‍

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 how to move a component from one SL to another and see the corresponding changes to the countermeasures required.

Learn more about IriusRisk and IEC/ ANSI 62443 here.