The IEC 62443 series is one of the standards that is globally used as Industrial Control System (ICS) cyber security assurance guidelines. It comprises over 14 standards from part 1 to part 4.

Part 3-2, which covers “Security Risk Assessment for System Design, ” is the specific part that explains in more detail the risk management framework, a concept adopted in IEC 62443 in terms of risk management, the approach to performing risk assessment, incorporating the Security Level into the risk assessment process, etc.

IEC 62443-3-2 has quite different flow steps in terms of incorporating the way of performing risk assessment as an integrated risk management framework. Since the concept of Security Level should be accommodated during the assessment itself. By exploring the standard in-depth, the following table depicts the core content of how a risk assessment under IEC 62443-3-2 should be conveyed.

The first step in defining SuC (System under Consideration) or what is known more popularly as “Asset Characterization and Inventory, ” is a core step that should be performed to gain a thorough understanding of the system in place and how things are correlated within an ICS environment.

The outcome of this step can be in the form of an asset inventory list that informs us about the type of assets (hardware, software, functions, locations, availability of critical spare parts, etc.) that will be very useful for tracking future changes, understanding the current situation of the system in place, and performing better risk assessments by having proper inventory that covers objects as expected.

In IEC 62443-3-2, a risk assessment should be conducted in two stages. The first stage is known as the “initial risk assessment, ” which serves as a preliminary risk assessment to identify certain risks from SuC to determine which will proceed to the second stage, called the “Detailed Risk Assessment, ” and which are sufficient with the current situation.

This risk assessment step is crucial in determining the criticality of assets as the baseline for determining the criticality level of each SuC. The more critical the SuC, the more protection it will require Compared to the less critical one, the determination of such asset criticality level plays an important step in ensuring the organization has a more precise action in selecting, optimizing, and protecting certain assets by using its criticality level.

During the initial risk assessment step, we were also required to define the zones and conduits for each SuC that are being covered under the scope of assessment. The determination of zones and conduits can follow the approach of defining it from an operational perspective and then moving on deeper to the functional perspective of each SuC until the zone and conduit arrangement can be strategized well.

After screening all existing risks from the SuC, we move forward to the next step, called “Detailed Risk Assessment”. In this step, we conduct the risk assessment as per the normal risk assessment process under the other standards (NIST SP 800-82, ISO 31000, etc.), but the main difference between the other risk assessment steps with IEC 62443-3-2 is defining and assigning the Security Level Target (SL-T) for the SuC.

The assignment of SL-T should be made to each of the seven (7) Foundational Requirements (FR), which means we need to assess each FR and define the Security Level that we will put as the target based on our judgment against SuC (mapped into zone and conduit as per resulted in the “Initial Risk Assessment” step). If certain FRs are not applicable, the SL-T can only contain 1 or a few FR being mapped to, such as SL[T]: (1 0 0 2 0 4 0). A more detailed explanation of how to represent the value of such SL can be found in IEC 62443-3-3.

In the detailed risk assessment step, the very crucial process is to determine the SL-T, as it can take longer time compared to the conventional risk assessment process. Since we need to assess and define each SL-T for each zone and conduit that should be mapped into 7 FR. The rest of the process is considered similar to the other risk assessment processes as covered under different standards.

After the detailed risk assessment step is completed, we have almost finished our milestone of performing risk assessment according to IEC 62443-3-2. The next step that we should take is to prepare documentation and reporting to cover the risk assessment activities that we have previously performed. This document and report should also cover the asset criticality level, zone and conduit determination for each SuC, risk comparison between initial risk assessment versus some company risk profile, and Cyber Security Requirements Specification (CRS) to document mandatory security countermeasures of the SUC.

The CRS covers all detailed risk assessment information, including the proposed countermeasures to manage the risk with certain assigned responsibilities and projected completion dates.

All the risk assessment results, as covered in the risk assessment report, should have asset owner approval of risk posture and its countermeasures as the legitimate acknowledgment and the organization’s willingness to perform further action to manage the risk to the desired level.

Continuous improvement by stewardship, which can be in the form of a specific team being assembled to track the progress of CRS, is also a crucial step to ensure any countermeasures are being conveyed and actioned properly. The use of a change management process to track the countermeasure completion process can provide better tracking capability and proper close-out reporting in case the gap is already fixed.

The reassessment step after all countermeasures are completed should be performed to ensure the proper risk level is valid by having verified countermeasure(s) in place; therefore, a periodic risk assessment should be included as part of the long-lasting activity of the entire ICS cyber security assurance process.

Another mechanism to capture a further risk profile posture is through performing a vulnerability assessment and penetration testing. These activities are very common in an IT environment, but in an ICS environment, they should be performed with some technical consideration and execution customized to reflect certain ICS environments in specific organizations. This ensures the safety of operations during execution and helps capture a more detailed risk profile of an ICS environment.

For more information on how to perform risk assessment in an ICS OT environment to ensure cybersecurity assurance, explore our ICS OT cybersecurity courses at the following

link: https://fedco.co.id/ics-ot-cyber-security-courses/

For any consultation and technical assistance in ICS OT cybersecurity assurance milestones, explore our services at the following link: