Keywords

1 Introduction

Breakthroughs in quantum computing (QC) where the computational power of quantum computers exceed all possible classical computer systems are happening more regularly. In 2019, a team at Google demonstrated quantum supremacy by checking the validity of random samples [5] on their superconducting-based Sycamore 53-qubit quantum chip. More recently in 2020, a team in China also demonstrated quantum supremacy with Gaussian Boson sampling[44], this time using a photonics-based quantum setup. While these breakthroughs bring about potential advances in science and technology [31], it also threatens the security of classical computer systems. On a quantum computer, Shor’s [35] algorithm can solve integer-factoring and discrete-logarithm problems in polynomial time which means that public key cryptosystems that are built on Rivest-Shamir-Adleman (RSA), Diffie-Hellman (DH), and Elliptic-Curve Cryptography (ECC) algorithms are no longer secure, and can be crypt-analyzed easily. Another example is Grover’s [14] algorithm, which on a quantum computer provides a quadratic speed-up in performing brute-force attacks against symmetric-key and hash-based cryptography. Applications that rely on cryptography to achieve confidentiality, integrity, authenticity and non-repudiation for their data, users and communication will need to use alternative mechanisms or have the security and trust eroded due to quantum computers. The National Institute of Standards and Technology (NIST) is currently running on a Post-Quantum Cryptography (PQC) contest [26] to standardize suitable quantum-resistant asymmetric key algorithms for key exchange and digital signatures and is expected to finalize the standard by 2024 [24].

The good news is that current quantum computers are not sufficiently powerful to run Shor’s or Grover’s algorithm on a large-enough scale. Shor’s algorithm has been demonstrated up to a 7-qubit quantum computer [41] and none of the current-day noisy intermediate-state quantum computers (NISQ) [28] are fault-tolerant enough to beat classical computers at asymmetric key cryptanalysis. On the other hand, NIST mentions in 2016 [8] that by 2030 with a budget of $1 billion, a quantum computer could likely be built to break RSA-2048 keys. So how can organizations be sufficiently prepared to face the threat of quantum computers? The study by Arslan et al. [4] listed 4 areas that are all cryptography-specific. We intend to dive deeper and use threat modelling to find the answer.

The rationale to use threat modelling is logical. Organizations face circumstances and situations that can impact and cause harm to the organizations’ own, other organizations’ or even national assets, personnel, processes, mission, function, image or reputation. These circumstances or situations are potential violations of security are known as threats and are caused by threat sources [6]. Any environment where the system operates may have both known and unknown vulnerabilities or weaknesses and can be exploited by one or more threats causing a breach of the system’s security processes or policy. As technology continually evolves (in the case of QC), new threats and even threat types emerge. NIST describes threat modelling as a risk assessment method that is used to model aspects of both offensive and defensive sides of a specific logical entity, which can be a system or an environment, an application or a host or even a piece of data or information [37]. Here, we have distinguished the difference between a threat, vulnerability and risk.

  • Threat. The word “threat” has an extensive range of different meanings associated with it and it can be understood as people or person, event, weakness or vulnerability and in the context of cybersecurity, also as malware, criminal activity, and espionage. A threat can be described as an event or a development of events that are possible and harmful. Compared to danger which is more tangible and well-defined, a threat has a more uncertain evolution phase and has to be dealt with using risk management procedures. During the risk management process, threats are usually decomposed further to threat events and threat sources to give a more detailed picture of threats, their impact and possible mitigation. In essence, a threat is an undesired event or something malicious that can happen to or through a system/product/service.

  • Vulnerability. A vulnerability refers to any trust assumption that can be violated to exploit a system. It is a weakness in a system, process, individual, control, implementation, architecture or even organizational structure and external dependencies. These weaknesses can be exploited, and vulnerabilities revealed to provide attackers with the window of opportunity.

  • Risk. A risk is uncertainty or insecurity affecting objectives. Risk causes a deviation from expected and can be positive, negative or both, although the word “risk” is often associated with being implicitly negative. A risk usually contains an evaluation of the likelihood and impact and it has a score based on these estimations [37]. In the case of Cyber-Physical system (CPS) and other critical infrastructure, there is an added safety risk to the human operators, system and environment that must be considered.

In this paper’s context, the advent of quantum computers poses a threat to classical computing systems because adversaries can run Shor’s algorithm [35] on quantum computers to exploit vulnerabilities in RSA/DH/ECC asymmetric key cryptography and, to a lesser extent, run Grover’s algorithm [14] to carry out faster brute-force attacks on encrypted data, passwords, and hashes, thus rendering such cryptographic primitives inadequate to provide the necessary security primitives that the application requires. What is less known or un-quantified is the potential extent of the threat and therefore the risks faced by present-day applications and data.

Highly operational systems such as CPS require to go through regular threat modelling exercises to update their design and/or processes to remain secure. But not all threat modelling methods (TMM) are suitable for evaluating and mitigating QC threats. Our paper attempts to complement the post-quantum cryptography (PQC) standardization efforts by NIST [24, 26] by identifying an appropriate TMM that system owners can use in their preparation for the post-quantum computing era. Our contributions are:

  • Performing a study of different threat modelling approaches and evaluating 20 TMMs to select PASTA, when complemented with Attack Trees and STRIDE, as the most appropriate TMM for evaluating QC threats for existing systems.

  • Carrying out a threat modelling exercise using PASTA on a generic CPS set up to demonstrate its efficacy at evaluating QC threats, and providing the outputs of the exercise including mitigation strategies.

The rest of this paper is organized as follows. In Sect. 2, we perform a landscape study of different threat modelling approaches and methods to select an appropriate TMM for evaluating the QC threats. In Sect. 3, we carry out a threat modelling exercise using our selected method on a CPS setup to demonstrate its efficacy before concluding in Sect. 4.

2 Threat Modelling Landscape Study

Different threat modelling methodologies, frameworks, and tools have been developed. Some are more comprehensive than others; some have a higher abstraction level while some focus on one or a combination of a few domains with greater granularity. Different methods can be distinguished by the logical entity that is being modelled (data, software, system, service, product), the phase of the entity’s lifecycle and the goal of the threat modelling. TMMs and tools can be consolidated with other methods and even risk management processes to create custom tools for special needs.

In selecting an appropriate TMM, it should be comprehensive enough to effectively communicate the relevant threats and risks to the management but should also have ample details for those responsible for mitigating the threat. Threat modelling is a continuous process against newer threats and matching it with the existing mitigation efforts. The key benefit from routine threat modelling is the precision of modelling results from the increased frequency in which newer data from the system is obtained, reviewed, and reported. We are mindful that as the evolving nature of QC still presents numerous facets of factors and considerations, it is unlikely to address all the QC threats by designing a perfect TMM. Instead, we start by identifying suitable threat modelling approaches that can be used, before narrowing them down to the most appropriate TMM for evaluating QC threats.

2.1 Threat Modelling Approaches

We describe the different (non-exclusive) approaches [36] and their suitability to analyzing the QC threat.

Asset-Centric Approach. An asset-oriented approach begins with the identification of critical assets and impacts or consequences towards them. Asset-centric modelling focuses on questions, such as what one’s most valuable assets are and what can go wrong with them. A list of valuable assets is then cycled through, and each asset is considered one at a time. Threat scenarios that can have an impact on the asset are described and prioritized. Assets that have a supporting role or can be used as a secondary asset to harm primary assets should also be included [36]. In modelling for QC threats, we expect the effort to be large but the results to be comprehensive since the threat modelling exercise will cycle through each asset to evaluate the QC-specific vulnerability. Relevance: High.

Attacker-Centric or Threat-Centric Approach. In the attacker-centric approach, potential adversaries’ intent, capabilities, resources, characteristics relationships and/or behaviour are consolidated as a type of threat model. Understanding what adversaries seek to achieve for their actions against a system, may give an organization more understanding and insight into the Tactics, Techniques, and Procedures (TTP) of these adversaries. Adversary behaviours can be organized using a cyber kill-chain model into a threat scenario or attack scenario. Threat sources and/or events are usually identified first, and threat scenarios and the developments of threats are described in more detail. Adversary characteristics and behaviours as well as intents and motivations are the key elements when identifying impacts [6]. Attacker-centric modelling focuses on questions, such as what the attacker wants and why as well as how attackers gain their objectives. In modelling for QC threats, this approach is efficient in narrowing down the scope as the QC threat posed by the cryptographic weakness is already known and the threat modelling effort can be targeted at identifying and mitigating negative outcomes. Relevance: High.

Software-Centric. Software-centric threat modelling is performed during the software design and development process to reduce vulnerabilities in the software [37]. Software-centric modelling focuses on questions, such as what the system is and how it works, as well as what can go wrong and how it can be used incorrectly or harmfully. Hence it is often requirements and vulnerability oriented. In software or system-centric modelling techniques, data flow diagrams are usually used to first model the system, data, and boundaries and then determine which threats are relevant to each component and trust boundary-crossing. In modelling for QC threats, this approach is useful mainly for developers since the vulnerabilities are well understood which allows the software to be designed and evaluated accurately. On the other hand, the unknown impact of QC threats may lead to a large number of overlapping threats being identified. Relevance: Low.

Data-Centric Approach. Data-centric threat modelling focuses on protecting types of data/ information within a system instead of hosts, operating systems or applications. The system and data of interest are identified and characterized and prioritised. The focus is on the characteristics of authorized locations for storing, transmitting, executing, inputting and outputting data within the system: data flows between authorized locations, security objectives and people and processes authorized to access the data [37]. In modelling for QC threats, this approach is efficient since a large proportion of the cryptographic implementation is meant for data protection. However, we are concerned that this focused approach may not be ideal for non-data-related considerations such as business-impact analysis. Relevance: Medium.

2.2 Risk Management

Risk management [40] is usually not a stand-alone threat modelling approach, but one that integrates risk considerations and processes into one or more of the approaches mentioned in Sect. 2.1. While it increases the overall effort in performing the threat modelling exercise, the outcome is a more comprehensive and complete picture, especially in threats where the resulting impact is not well defined or known. It also allows organizations to take on a more preventive posture when dealing with such threats. In modelling for QC threats, risk management extends the known QC threats into identified risk areas for application owners to calibrate and manage. It can help organizations assess, quantify and prioritize the various risk areas including business costs, probable losses, organizational preparedness, safety, etc., and embark on both technical and non-technical preventive and/or mitigation actions.

2.3 Threat Modelling Methods (TMM)

TMMs are used to create an abstraction of the system, profiles of potential attackers, including their goals and methods and producing a catalogue of potential threats that may arise. Some TMMs are typically used on their own while others are used in combination with others. We performed a landscape study that included a total of 20 different TMMs (see Table 1). The study includes all 12 TMMs studied by Shevchenko [33] and all 6 most popular TMMs listed by EC-Council [12].

In our study, we are looking for an asset-centric approach TMM that includes risk management techniques and can be complemented with a threat/data-centric approach to provide QC threat focus. This criterion is likely to yield the most appropriate TMM candidate for evaluating QC threats while balancing between completeness and efficiency.

2.4 Result of Study

PASTA [40], incorporating Attack Trees [32] and STRIDE [18], stands out as the TMM that is suitable for evaluating QC threats. The purpose of PASTA is to provide a process for simulating attacks to systems (even as a subset of just applications), analysing threats and mitigate the risks and impacts that these threats present to organizations. PASTA comprises a seven-stages process for modelling attacks and analysing threats to a particular system and environment. The objectives are curtailing risks and their associated impact on the organisation or business. Organisations or businesses can address the adequate level of countermeasures or risk mitigation measures to be deployed to mitigate the risk from threats and attacks by following this process. A description of the PASTA threat modelling method, along with Attack Trees and STRIDE, is found in Appendix A.

We chose PASTA over OCTAVE [7] due to the former’s ability to incorporate attacker-centric and data-centric to its asset-centric approach. This allows the threat modelling exercise (see Sect. 3) to be more efficient in identifying and addressing the QC threats as compared to a generic threat modelling method. We chose PASTA over IDDIL/ATC [25] due to the former’s availability of documentation and use-cases, and its ability to address risk at a strategic level.

Table 1. List of TMM studied on suitability for QC threat evaluation.
Full size table

3 QC Threat Modelling Exercise

We perform a threat modelling exercise using PASTA on a generic CPS set up as a walk-through on how QC threats can be identified, evaluated and mitigated.

3.1 Generic CPS Model

In [19], Lee described the CPS problem as the intersection between the cyber and physical problems and all three areas need to be examined and addressed separately. The environment we define in our model therefore comprises three parts, namely, physical environment, CPS and cyber IT, as shown in Fig. 1. The physical environment includes the external physical operations that control the inputs and manages the supply to the CPS. It includes several maintenance features that manage the external assets and the associated physical processes. The CPS layer is intermediate, and it involves the supervisory control system, the internal communication system which manages the sensors and controls the actuators. The operations of this layer are managed through command and control operations of the Programmable Logic Controller (PLCs) that use sensory data acquisition to take action based on the input as well as output from the sensors and actuators. Finally, the cyber IT environment involves parts supporting remote invocations and accessibility through the external communication network. This layer helps with the management of features of CPS allowing control over the cloud.

Fig. 1.
figure 1

An overview of a generic CPS model.

Full size image

The security requirements for a CPS system extend beyond the traditional technical security requirements that govern a cyber IT system. The additional interface with the physical environment means that the security of the CPS system can impact the physical environment and vice versa. In NIST’s “Guide to Industrial Control Systems (ICS) Security” [38], the health and safety of human lives as well as damage to the environment are identified security considerations that a CPS system, but not a cyber IT system, may face. Conversely, the CPS system is required to maintain its robustness and resilience [2] against possible events, such as weather hazards, acts of war, and power outage, that the physical environment may impact the safety and security of the CPS system.

In the rest of this section, we will only flesh out QC-relatedFootnote 1 threats and risks.

3.2 PASTA Stage 1 to 3

The first 3 PASTA stages require us to define the objectives, define the technical scope, and perform the decomposition of the system. The guiding questions we use at these stages are:

  • Stage 1 - Define Objectives

    • What are the key business objectives?

    • What are the critical functions and assets that might be affected by a QC threat?

    • What are the system safety standards at risk?

    • How does the compromised system cause catastrophic or irreparable damages?

    • What are the risk tolerance levels concerning Confidentiality, Integrity, Availability and Authentication?

  • Stage 2 - Define Technical Scope

    • What is the system architecture and the boundaries?

    • What are the security controls and draw bridges?

    • What is the Data Flow or Process Flow, and interdependencies?

    • What are the external interfaces? (Cyber to CPS interfaces)

    • What are the protection measures in this external infra (i.e. power sources, security system, enterprise IT system)?

  • Stage 3 - System/Application Decomposition

    • What are the different components/environment in the system assessed? (cyber, physical, cyber-physical)

    • What are the possible QC threats/vulnerabilities arising from these different components/ environments?

    • Where are their entry points in a different environment?

    • Where are the “trusted environments/zones”?

    • What are the supply chain weakness in the system? (i.e. suppliers of a thumb drive, backup storage media, cloud enterprise system that needs transfer)

Output. We reference a generic CPS model, as shown in Fig. 1. To evaluate QC threats, there are no changes to the boundaries of the technical environment and interdependencies between its infrastructure and application. Overall, the boundaries are depicted between the Physical environment, Cyber-Physical System (CPS) and the Cyber-IT environment. We next add on the objective that the critical systems and assets in the CPS can continue to operate safely and resiliently in the post-quantum era.

Fig. 2.
figure 2

Generic CPS setup with data flows identified.

Full size image

We then divide the CPS boundary into the cyber layer, cyber-physical layer and physical layer, and identify seven major data flows (diagrammatically shown in Fig. 2) that could be affected by QC threats. These are:

  1. DF#1:

    This refers to the data flow from an external supervisory control centre to the onsite supervisory control system via remote access. This allows a central body to remotely manage and monitor multiple CPS setups.

  2. DF#2:

    This refers to the data flow from an external computing system (e.g. Enterprise IT or Cloud computing) via the external communication networks into the CPS setup. Updates and patches can be transmitted via this flow. Employees with access to the Enterprise IT or Cloud computing service might fall prey to social engineering and will in turn infect the CPS with transferred files, programs or malware.

  3. DF#3:

    This refers to data flow from external assets and physical processes to the CPS setup. This can be in the form of external contractors conducting support and maintenance works on the CPS. For example, CPS patches handled by contractors via thumb drive, hard disk or vendor laptop will inevitably expose the CPS setup for exploits.

  4. DF#4:

    This refers to data flow from external physical infrastructure providers into the CPS setup. For example, the electrical or water supply contractor might tweak the readings or measurements of the supporting environment system.

  5. DF#5:

    This refers to the data flow from on-site supervisory control (e.g. Human Machine Interface) to the PLCs. Commands are likely to be sent via API to the PLCs for executing controls.

  6. DF#6:

    This refers to data flow from PLC to actuators within the CPS setup. PLC commands are sent directly to the actuators to execute the designated actions like opening and closing of valves or the starting or stopping of pumps.

  7. DF#7:

    This refers to the data flow from CPS sensors to PLC. Sensor readings are being routed back to the PLC as feedback signals. These include status information such as water level in the tank, temperature readings, or alerts.

3.3 PASTA Stage 4 to 6

The next 3 PASTA stages require us to perform the threat analysis, vulnerability and weakness analysis, and attack modelling. The guiding questions we use at these stages are:

  • Stage 4 - Threat Analysis

    • What are the threats that the STRIDE model tells us?

    • How does the attack/hack take place? What are the probabilities of each of the attack vector?

    • What does the identified threats correlate with the severity and fix-ability of the threats from the available threat intelligence?

    • What is the analysed impact of these identified threats?

  • Stage 5 - Vulnerability and Weakness Analysis

    • What are the available vulnerability and penetration testing reports?

    • Any recent audits or vulnerability scanning or penetration testing conducted?

    • Are there trends of certain vulnerabilities being exploited?

    • What are the false positives and false negatives trends?

    • What is the overall vulnerabilities score?

    • What is the security posture from vulnerabilities?

  • Stage 6 - Attack Modelling

    • From the Attack Tree, for each application that uses public-key cryptography, how can Shor’s algorithm be used to compromise the system? Can the algorithm be replaced with a PQC candidate algorithm [26]?

    • From the Attack Tree, for each application that uses symmetric key cryptography and hashing, how can Grover’s algorithm be used to compromise the system? Can we increase the key size?

    • How are the vulnerabilities and attacks vector associated?

    • Are there attack vectors that have been made less effective with the vulnerabilities remediated?

    • Any vulnerabilities that could not be fixed?

Fig. 3.
figure 3

Attack Tree for generic CPS setup when evaluating QC threats.

Full size image

Output. We use a combination of Attack Trees [32] (see Fig. 3) and STRIDE [18] to analyze the data flows to list out the threats in Table 2.

Table 2. STRIDE threat evaluation of data flows
Full size table

3.4 Stage 7 - Risk and Impact Analysis

This step requires the analysis of the business impact in both qualification and quantifiable terms. There is also a need to propose some countermeasures and residual risk mitigation measures. Lastly the need to identify and recommend some risk mitigation strategies for the system owners. The guiding questions we use at this stage are:

  • What are the key business objectives and critical services that are affected?

  • How else can the risk of safety be minimized? How resilient is the system to an unaddressed QC threat?

  • What is the degraded mode of operations/ services?

  • What mitigating / remediation measures are possible to counter the remaining threats?

Output. As the last step of PASTA, the broad mitigation strategies we identified for mitigating the threats brought about by QC are as follows:

  1. 1.

    Strict Network Segregation. Where algorithm replacement is not possible, this will ensure that the core CPS setup is separated from any external connectivity. This includes a clear delineation from Enterprise IT network and Cloud computing services. It will require that remote access to the supervisory control system to be terminated if the security measures cannot be strengthened to guard against QC threats. CPS should build an alert system to flag any illegitimate external connectivity or devices modification.

  2. 2.

    Tight Supply Chain Controls. Contractors and vendors will remain the weakest link in the entire ecosystem of the CPS. To prevent the unauthorised and unauthenticated actions by these contractors and vendors, there is a need for close monitoring and checks on the actions such as patching and system maintenance of the CPS setup.

  3. 3.

    Internal Supervisory Controls and Monitoring. To circumvent the malicious insider threat, procedural security clearance and monitoring need to be put in place. There must be a “check and balance” system to only allow authenticated actions by the staff and against any unsolicited actions.

4 Conclusion

In this work, we studied the different approaches for threat modelling to find the most appropriate TMM for evaluating QC threats. Although the cryptographic vulnerabilities exposed by QC on classical asymmetric and symmetric key cryptography is known, much of the potential impact from the threat of QC is still unknown and evolving. Hence, an asset-centric threat modelling approach with strong risk management, when complemented with a threat/data-centric approach to provide focus, is the criteria we used. We narrowed the field of 20 TMMs to find PASTA as the most appropriate TMM. We then carried out a threat modelling exercise using PASTA on a generic CPS setup to test its efficacy and showed the output of the threat modelling exercise. The effect of including risk management in the threat modelling exercise allows us to consider the possibility that some QC threats may not be completely addressable (due to constraints in time, resources, know-how, etc.) and hence adopt additional broad-based mitigation strategies.