The Role of Track B in OT Cybersecurity 

Track B is designed for larger operators with intermediate to advanced cybersecurity maturity. It provides detailed risk and vulnerability assessment, aligning with international standards such as IEC 62443, ISO 27005, and TS 50701/IEC 63452. 

Practical Steps: From Risk Scoring to Security Level Targets 

Step 1: Identify the System under Consideration (SuC) 

Define the scope of the OT system to be assessed, by identifying the SuC’s boundaries and document the system’s architecture. 

Step 2: Identify Assets 

Create an inventory of OT assets within the SuC, by listing the physical and logical assets and group these assets into zones, based on their criticality and function. 

Step 3: Define Risk Criteria 

Establish scales for impact and likelihood to evaluate risks. Assess consequences in terms of safety, operational availability, and financial impact. Evaluate the Likelihood of a cyber incident based on threat actor capability (e.g., skill level, resources) and vulnerability exposure. 

Step 4: Identify Threats and Vulnerabilities 

Define the threat landscape for the OT system, by identifying threat actors (e.g., hacktivists, nation-states, insiders) and document vulnerabilities in the SuC. 

Step 5: Conduct an Initial Risk Assessment 

 Evaluate the inherent risks in the SuC, by assigning risk scores based on impact and likelihood. To help you determine the risk level (Low: 1; Medium: 2, High: 3, Critical: 4) use UITP’s risk matrix.  

Step 6: Translate Risk Scores into Security Level Target (SL-T) 

The SL-T is transformed into a 7-dimension matrix based on the 7 Foundational Requirements (FRs) defined in IEC 62443’s / EN 50701. 

Step 7: Perform Zoning and Define Zone Criticality 

Group assets into security zones that should reflect common security requirements (e.g., safety-critical vs. business-critical) and assign Zone Criticality Levels (ZC-L) based on the worst-case impact of a breach. 

Step 8: Implement Mitigation Strategies 

Apply controls to meet SL targets, for each of the 7 Foundational Requirements. In order to do so, each defined Security Requirement must be addressed.   

For example, if a signaling system is assessed with a risk score of 3 translated into a SL-T3, the Security Requirements in red in the following table must be met for FR5 (Restricted data flow). The same process applies to the 6 additional Foundational Requirements. 

This is where cyber technologies play an active part in the process. For example, a network architecture based on firewalls could achieve SL1 for FR5 but would require additional means to meet SL2 (SR 5.1.(1): physical network segmentation), whereas a unidirectional gateway would inherently meet SL1, SL2, and SL3 for FR5. 

Step 9: Address Tail Risks 

Modern risk management introduces the concept of “tail risk”. The notion that some risks could bring down organizations or even entire industries has now entered the sphere of best cybersecurity practices. Even with robust risk mitigation, tail risks—low-probability, high-impact events—pose a real challenge. For instance, abusing a fail-safe mechanism to generate the derailment of a passenger train or of a freight convoy carrying dangerous goods could be considered a tail risk. Mitigation Strategies may include increasing the security Level target (e.g.: from SL-T3 to SL-T4) or beefing up the resilience planning (by implementing backup systems and manual overrides) and the incident response plans by preparing for worst-case scenarios.