Cyber-physical risk

My S4 presentation was on cyber-physical risk and discussed a method of estimating risk for industrial control systems (ICS) using a semi-quantitative method. Not a popular topic because I think I was the only one addressing the topic during the conference.

Estimating cyber-physical risk has been a challenge for me for almost 10 years since the first question to do this came from an asset owner in the Gulf region. Step by step I learned how to do this and improved the method to find a more accurate result. By gradually growing the team of people to execute this service the method and tooling matured.

A semi-quantitative cyber-physical risk assessment is a holistic approach to determining the OT security requirements for an industrial control system. The method focuses on the loss scenarios of the production facility and determines the needed defensive strength based on the concrete cyber threats and risk criteria of the overall production system. This is while using the same risk criteria as those for process safety.

A semi-quantitative method offers important advantages because the integration with loss impact allows us to determine the so-called Maximum Responsible Investment (MJI) in a similar way to the process safety method ALARP (As Low As Reasonably Practical). This allows us to match cybersecurity investments with the potential loss of a cyberattack and justify investments in the same way as process security.
This is a fundamentally different approach than the ISA / IEC 62443 follows, the ISA / IEC 62443 is a prescriptive method with a focus on the OT cyber domain. The ISA / IEC method offers limited mechanisms to integrate OT security requirements with general production installation requirements. The ISA / IEC 62443 method identifies risk and translates this risk into security levels. These security levels are assigned to security zones and communication conduits, which subsequently define the security requirements to meet. The concept of measuring residual risk after applying security measures is not considered. The concept is that if we implement the defined requirements specified for a specific security level, the risk will be reduced adequately. ISA / IEC 62443 is not a tailor-made approach, once the method determines that your size is XXL, it should fit in all circumstances.

A cyber-physical risk assessment method such as Rings Of Protection Analysis, ROPA, the subject of my S4 presentation, approaches risk mitigation directly related to a specific loss scenario. It is a tailor-made approach considering all details of the ICS and production installation. At first glance, this seems like more work, but in fact, there is much overlap between different loss scenarios, reducing the work to manageable proportions.

Of course, a 25-minute S4 presentation is too short to explain more than the essence of a method, nor does a blog allow me to write an extensive story about the method. So maybe I should write a book after I retire. But let me attempt to address some of the core principles of ROPA I also covered at S4.
• ROPA is a semi-quantitative risk method, so the risk is assessed partially based on risk factor scores resulting from subject matter experts (like in a qualitative risk assessment) and partially based on risk factor scores derived from statistical data (like in a quantitative risk assessment). The risk results are quantitative and expressed as either an event frequency or a probability.

• ROPA reframes the physical ICS network topology into a logical function architecture. So, a single engineer station in the physical topology diagram maybe multiple engineer station functions in the logical function architecture if from this station multiple ICS functions are engineered. But also, the reverse can be true. Multiple physical operator stations can be reduced to a single operator function if these stations are used for a single ICS function. Examples of what I call an ICS function could be a Basic Process Control System (BPCS), a Safety Instrumented System (SIS), a Compressor Control System (CCS), but also the Process Automation Network (PAN), etc. This reframing is done because the consequences of cyber attacks differ per function. A successful attack on a SIS engineering function has different potential consequences for the ICS than a successful attack on a historian engineering function. Such a logical function architecture, a so-called function-scope diagram, shows the targets (assets and channels (protocols)) relevant to the risk analysis and how these system elements are interrelated/connected.
• ROPA risk estimation does not focus on the probability that an attack takes place, the focus of the method is on the probability that the attack is successful, or rather the other side of the same coin that our cyber defense fails to stop the attack. Risk is defined as the probability of attack (p(A) multiplied by the conditional probability of defense failure if attacked p(F|A) times the consequence severity. The focus is on determining the p(F|A) – acronym PFA – a conditional probability representing the strength of the cyber defense.
• ROPA divides the main risk assessment task into sub-tasks per system element (identified in the function-scope diagram) of the ICS. Sub-tasks that are easier to model and then combine the separate results to create a risk profile that encompasses all ICS functions relevant to the cyber-physical risk linked to a specific loss scenario. This is done by threat modeling each ICS system element and estimating the conditional probability that one of the threat actions (TTP) of a cyber attack will succeed (so our defense fails) given the implemented security measures. This is done for multiple threat actors, so in fact, the PFA is a vector. We typically work with 8 threat actor profiles, resulting in 8 PFA results per system element. So, the PFA differs for different threat actors. These PFA results are combined in rings of protection by estimating a new PFA vector for each defined protection ring. A protection ring is essentially a grouping of system elements for which a new PFA is determined. Essentially ROPA works “inside-out”, starting at the system elements that cause/initiate a specific loss scenario toward the direction an external threat actor would come from. This offers a number of advantages:

• Threat modeling an individual system element allows for more detailed analysis because the attack surface is better defined.
• The threat model can be reused because apart from different exposure within different architectures the system element itself remains the same. So over time, very detailed threat models are created.
• The insider threat is better covered this way because insiders can have direct access to a system element. As such insiders don’t need to follow a multi-step attack to get access to a critical system element.
• In the next diagram, I compare the process safety LOPA method to define how many safeguards are required to sufficiently reduce the process safety risk, with the ROPA method defining the required risk reduction through security measures and exposure restriction.

How these rings are defined and the different formulas for estimating the conditional probability of dependent and independent events are too detailed for a blog. But in fact, the inner rings profit (or suffer) from the security measures and exposure of the surrounding rings, ideally reducing the risk of a specific loss scenario occurring.

At S4 I explained the above example based on a reactor process using as an example a thermal runaway loss scenario combined with regulatory and derived business risk tolerance requirements. The main message was that a plant has one set of risk criteria, independent of the source of the risk. Risk requirements are defined for a specific severity and likelihood (event frequency) of the loss and all plant disciplines (safety management, reliability management, and OT security management) must meet the same set of risk criteria.

Sinclair Koelemij

With 45 years of experience in process automation, Sinclair brings a wealth of expertise, with 25 years dedicated to process control and an additional 20 years specializing in networking, security, and risk management for process automation systems. During his extensive 43-year tenure at Honeywell, he played key roles in servicing, engineering, and securing diverse control and process safety solutions, spanning basic and advanced control systems. Sinclair also possesses hands-on experience in software development and the implementation of control and safety solutions for over 100 installations owned by various asset owners, varying in scale from smaller setups with fewer than 1,000 I/O points to large installations exceeding 100,000 I/O points. Furthermore, Sinclair holds several patents in the field of cyber-physical risk evaluation and mitigation..