Critical infrastructure faces a growing number of security threats.. Critical infrastructure typically relies on Industrial Automation and Control Systems (IACS) and other non-IT components, often referred to as “Operational Technology.” To effectively assess cybersecurity risks within operational technology (OT) systems, adhering to the internationally recognized IEC 62443 standard is best practice.

IEC 62443-3-2, part of the IEC 62443 series, details the process for conducting a security risk assessment for industrial control systems.

The subsequent sections will elaborate on this risk analysis process while also simplifying certain steps to enhance clarity and understanding of the general idea.

For a comprehensive overview of the workflow, request the ISA whitepaper here (it’s free):
Download Leveraging ISA 62443-3-2 For IACS Risk Assessment and Risk Related Strategies

Identification of the System Under Consideration (SUC)

Initially, defining the scope for the security risk analysis is crucial. The IEC 62443 standard defines the system being assessed as the “System Under Consideration,” or SUC.

Defining the boundaries of the Security Under Consideration (SUC) is an important step. The inclusion or exclusion of systems or components can significantly affect the accuracy of the security risk assessment.

Initial Risk Assessment

The goal of the initial risk assessment is to get an idea of the impact of a successful attack. In this step, it is not assessed, how likely such an attack is, the analysis focuses solely on the impact of such an attack.

To evaluate the impact of a successful attack, appropriate scales for categorizing these impacts are necessary. The scales for categorizing impacts must be established based on the system’s context and operating conditions and should likely include considerations for confidentiality, integrity, availability, and potentially the financial impact of a successful attack.

Zones & Conduits

Next, the system is partitioned into zones and conduits. Zones group assets with similar protection needs, thus sharing common security requirements. A conduit might consist of multiple physical or logical connections / interfaces, which have a similar need for protection. A graphical representation of the zones and conduits offers a rough overview of the system structure from a security point of view.

Further details on defining zones and conduits are available at: How to Define Zones and Conduits

Detailed Risk Assessment

If the risks evaluated in the initial risk assessment exceed the tolerable risk, a detailed risk assessment must be conducted. The detailed risk assessment workflow is being performed on each zone and conduit.

Threat identification

The first step identifies threats to the zone or conduit. Attackers vary significantly in their technical skills, motivations, and financial resources. State actors, for instance, have vastly different resources and motivations compared to disgruntled former employees.

One method for systematically identifying threats is through the creation of an attack tree.

Identification of vulnerabilities

What are the system’s vulnerabilities? These could include publicly known software vulnerabilities with assigned CVEs, as well as other weaknesses, such as inadequate door locking mechanisms of a cabinet housing a control system.

Impact & likelihood and the resulting risk

What is the likelihood of an attack to succeed, and what is the impact of a successful attack? Impact and likelihood can be assessed using scales agreed upon with the asset owner.

The impact of a successful attack can be categorized by its effects on safety, availability, and finances.

Threats vary significantly in both likelihood and potential impact. Some threats identified might be highly theoretical and unlikely to occur, for example, because they require extremely expensive tools, while similar impacts on the system can be achieved by an attacker more easily through other methods. On the other hand, another vulnerability could be easily exploited even by a low-skilled attacker with a low motivation.

The risk associated with a specific threat is determined by its impact and likelihood. Risks are typically visualized using risk matrices.

Security Level Target (SL-T)

The Security Level Target (SL-T) is determined based on the results. The SL-T indicates the necessary protection level for a specific zone, informing component and countermeasure selection.

Countermeasures & Re-Evaluation

If the unmitigated risk (without countermeasures) surpasses the tolerable risk level, additional countermeasures have to be implemented. The initial iteration considers all existing and planned system countermeasures. Countermeasure effectiveness is assessed by re-evaluating each threat’s likelihood and impact, considering implemented countermeasures.

If the risk remains above the acceptable level, further countermeasures must be implemented. The re-evaluation incorporates both existing and newly defined countermeasures.

If the risk remains above the acceptable threshold, the process repeats: additional countermeasures must be implemented until the risk is sufficiently mitigated.

Documentation

Thorough documentation of risk assessments and their corresponding countermeasures is essential.

Security risk assessments are typically documented in a formal report. This report details the assessment methodology, along with any assumptions made and constraints encountered.

Cybersecurity requirements will be derived from the countermeasures. A formal Cybersecurity Requirements Specification (CRS) will document all cybersecurity requirements.

Conclusion

Following the IEC 62443-3-2 standard for security risk analysis provides a systematic method to identify and assess threats, vulnerabilities, and associated risks within a system. This structured approach minimizes the chance of overlooking critical risks, unlike less systematic methods.