Legacy ICS Cybersecurity Assessment Using Hybrid Threat Modeling—An Oil and Gas Sector Case Study

Abstract

As security breaches are increasingly widely reported in today’s culture, cybersecurity is gaining attention on a global scale. Threat modeling methods (TMM) are a proactive security practice that is essential for pinpointing risks and limiting their impact. This paper proposes a hybrid threat modeling framework based on system-centric, attacker-centric, and risk-centric approaches to identify threats in Operational Technology (OT) applications. OT is made up of software and hardware used to manage, secure, and control industrial control systems (ICS), and its environments include factories, power plants, oil and gas refineries, and pipelines. To visualize the “big picture” of its infrastructure risk profile and improve understanding of the full attack surface, the proposed framework builds on several threat modeling methodologies: PASTA modeling, STRIDE, and attack tree components. Nevertheless, the continuity and stability of vital infrastructure will continue to depend heavily on legacy equipment. Thus, protecting the availability, security, and safety of industrial environments and vital infrastructure from cyberattacks requires operational technology (OT) cybersecurity. The feasibility of the proposed approach is illustrated with a case study from a real oil and gas production plant control system where numerous significant cyberattacks in recent years have targeted OT networks more frequently as hackers realized the possibility of disruption due to insufficient OT security, particularly for outdated systems. The proposed framework achieved better results in detecting threats and severity in the design of the case study system, helping to increase security and support cybersecurity assessment of legacy control systems.

1. Introduction

For many years, malicious cyberactors have been targeting the industrial control systems (ICS) that manage our critical infrastructure. An ICS incident may have the following potential consequences: impact on national security—facilitating an act of terrorism; reduction or loss of production at one or multiple sites simultaneously; injury or death of employees; environmental damage; release, diversion, or theft of hazardous materials; violation of regulatory requirements; product contamination; criminal or civil legal liabilities; loss of proprietary or confidential information; and loss of brand image or customer confidence. Security has become a high priority for operational technology (OT) systems in recent years due to targeted cyber-incidents. Previously, the primary focus of these systems was reliability, but today, security also holds significant importance. To improve the security in industrial systems, it is necessary to understand the flaws and provide countermeasures [1].

The ENISA (European Union Agency for Cybersecurity) Threat Landscape (ETL) report, which is in its 11th edition [2], offers a comprehensive view of the cybersecurity threat. The report emphasized the continued rise in cybersecurity attacks in the latter part of 2022 and the first half of 2023, not only in terms of their number and vectors but also in terms of their impact. The Russia-Ukraine crisis has ushered in a new era of cyber warfare and hacktivism. Additionally, state-sponsored threat actors will intensify their reconnaissance efforts against OT networks, enhance their capabilities, and progressively target them in the near future, particularly during periods of armed conflict and crisis. Given their adaptability and ability to target a wide range of victims and equipment used in a variety of industries, we can infer that state-backed actors interested in attacking OT networks will continue to allocate resources and develop extensible ICS malware frameworks.

In addition, Fortinet’s 2022 State of Operational Technology and Cybersecurity Report says that organizations around the world are not doing enough to protect ICS and Supervisory Control and Data Acquisition (SCADA) systems in the relatively new world of connected OT. Cyberattacks on OT systems have increased over the past decade because they are more vulnerable to offsite attacks. While OT systems were traditionally air-gapped from IT systems, these two infrastructures are almost universally integrated today. OT systems, now connected to the internet and theoretically accessible from anywhere, significantly expand the attack surface for industrial organizations, further bolstered by the increasing ubiquity of Industrial Internet of Things (IIoT) devices. At the same time, connected OT systems are vulnerable to an IT threat landscape that is getting more advanced [3].

Kaspersky Lab’s ICS-CERT report highlights the threat landscape for industrial automation systems in Q1 2024. The percentage of ICS computers that blocked malicious objects during the quarter varied by region, from 32.4% in Africa to 11.5% in Northern Europe. The two regions with the highest percentage of attacked ICS computers, Africa and Southeast Asia, experienced an increase in their percentages from the previous quarter. Historically, among the surveyed industries, building automation has proven to be the most effective in preventing malicious objects from accessing ICS computers. The percentage of ICS devices that blocked malicious objects decreased across all industries in the first quarter of 2024. According to an additional survey, the energy and gas sector is particularly appealing to attackers on a global scale. Over the past year, ransomware gangs have targeted significant organizations throughout Europe as an opportunistic response to the Russian-Ukraine conflict. This has led to a widespread disruption of energy supplies, which is the focus of this research [4].

Additionally, an outdated or obsolete system for controlling and monitoring industrial processes and critical infrastructure is known as a legacy industrial control system (ICS). Typically, the implementation of these systems preceded modern advancements in technology and cybersecurity practices. Legacy control systems and devices face numerous challenges. Koien et al. [5] noted that legacy systems and devices may have outdated software, firmware, and hardware, limited connectivity, no or inadequate means for updating the software and firmware, no or inadequate communications security, and no or inadequate means to conduct access control. Legacy devices (LDs) are potentially vulnerable to a whole range of security threats. Dealing with the aging hardware or software that forms the foundation of their OT presents a significant challenge for many organizations seeking cybersecurity for their operations. While most organizations continue to utilize legacy ICS due to their critical role in plant operations, their age presents potential vulnerabilities and opportunities for cyberattacks. SANS™ Institute survey 2021 presents that one of the greatest challenges facing OT security relates, as always, to technology (technical integration represents a challenge). Organizations need to ensure that technical implementations more effectively integrate legacy OT environments with modern security technologies. Solution providers can support innovation in this area [6].

During the last decade, legacy system upgrades in the industry were to conform with safety norms and regulations defined by standards. Traditional analysis methods that aim to assess the safety of critical infrastructure fail to encompass the complexity of emerging cyber-physical systems. The Threat Modeling Method (TMM) is increasingly being used in application development and system evaluation. A widely applicable threat modeling definition is a proactive security practice that is essential for pinpointing risks and limiting them. Furthermore, Uzunov and Fernandez asserted that threat modeling serves as a process for analyzing potential attacks or threats supported by threat libraries or attack taxonomies [7].

Threat modeling considers both safety and security aspects. For example, Suo et al. [8] applied a STRIDE-based threat modeling method to an automated driving system, analyzing both safety and cybersecurity aspects. Graham et al. [9] presented Root Causes of ICS Cybersecurity Vulnerabilities, in which they identified six primary technical and administrative factors that lead to cybersecurity vulnerabilities in ICS (poorly secured legacy systems). Many industrial control systems typically have a 10- to 30-year life cycle. Lack of trained cybersecurity specialists, delayed application of operating system and application software patches, and a lack of cyber-security situational awareness are among the factors contributing to cybersecurity vulnerabilities in industrial control systems.

Shevchenko et al. presented 12 popular threat modeling methodologies discussed from a variety of sources and targeted different parts of the process, as well as summarized some features of each threat modeling method. Additionally, Nataliya answered the question, What criteria should a good TMM satisfy for a specific domain cyber-physical system (CPS)? Nataliya’s response to the question was: “After evaluating existing TMMs, it became clear that no single method could adequately address all aspects”. We can conclude that a significant goal of this research [10] is to devise a framework that integrates various methods and techniques.

Furthermore, though MITRE [11] has released the ATT&CK framework that covers generic attacks on ICS, ENISA [12] has numerous OT systems publications, and NIST [13] has a specific OT security publication Special Publication 800-82r2. Still, there has been no systematic approach to catalog, map, and classify cybersecurity attacks on the oil and gas sector.

The contributions of this paper are as follows:

• This paper introduces a hybrid threat modeling methodology that blends system-centric (STRIDE [14]), attacker-centric (Attack Trees [15]), and risk-centric (PASTA [16]) viewpoints to better assess threats.
• The framework uses CVSS [17,18] for quantitative security evaluation to inform decision-making. To assess security and mitigation efficacy, a feedback loop is used.
• The methodology improves threat intelligence and actionable risk knowledge by using the MITRE ATT&CK architecture [11].
• The research gives a complete empirical evaluation of the hybrid framework and compares it to existing methodologies, demonstrating its synergistic technique combination.

The rest of the paper is organized as follows: Section 2 lays the foundational groundwork by discussing relevant concepts and existing threat modeling methodologies. The limitations of related approaches will be explored, and the need for a more comprehensive framework will be identified. Section 3 outlines the proposed ensemble framework and provides a step-by-step explanation of its functions. Section 4 employs the proposed framework in an ICS case study to showcase its efficacy in identifying and assessing potential threats. Finally, Section 5 summarizes the key findings of the paper and discusses the significance of the proposed framework. Furthermore, the paper highlights potential future directions for research and development.

2. Background and Related Work

This section presents a background to the industrial control system, the real case study, threat modeling techniques, and the related work. Section 2.1 presents ICS process and control. Section 2.2 elaborates on the four threat modeling methods that serve as the foundation for the proposed framework, and Section 2.3 presents the related works to the threat modeling.

2.1. Industrial Control System (ICS)

The oil and gas sector largely depends on Industrial Control Systems (ICS). Unfortunately, legacy ICS typically leaves systems exposed to attacks. Outdated protocols, limited documentation, and proprietary components make the security assessment of legacy ICS more difficult [5]. The ICS System as an abstract architecture consists of a minimum component, as shown in Figure 1:

There could be thousands of transmitters in a factory sending signals to ICS (4 to 20 mA, 1 to 5 volts direct volt (DC), or resistance), and for digital, they would be 0 or logic 1. The Fieldbus Control System (FCS) receives analog signals from various transmitters. It will convert it to digital via the input module and then pass it to the Central Processing Unit (CPU) for processing. The CPU will compare the process-measured value (PV) with the value set by the operator (SV). If the two values don’t match, ICS will send an output known as Manipulated Value (MV) to the field through output modules, allowing for the adjustment of the physical quantity, such as by operating a valve.

Figure 2 shows an example of a simple control mechanism. The water in the tank is required to be controlled; the level transmitter will measure the water level and send a PV signal (4–20 mA) to the ICS. The FCS input module will receive this signal and pass it to the CPU after converting it to a digital signal. The operator station screen displays the PV data in a small window known as a faceplate.

On the faceplate, the operator can see the three parameters reading SV, PV, and MV. At the top, the faceplate shows the status of this control process (normal or alarm). If the faceplate mode is auto, the ICS system will operate the pump by sending an MV signal via the output module to fill the tank, continuing as long as the PV signal from the transmitter is less than SV. However, in manual mode, the operator can directly control the MV, disabling the SV pointer. Additionally, the faceplate displays the control process’s status as either normal or alarm; if there is a problem that prevents PV from equalizing with SV, the alarm will sound.

Next, Figure 3 shows a real ICS system for the oil & gas refinery, which will be used as a case study in Section 4.

Unauthorized users or other malicious attacks could hack ICS, exposing important data and triggering a series of other major security issues. ICS should treat security issues with the same importance as safety issues. Nowadays, safety and security are analyzed separately when they should not be. This is because a security threat can lead to the same dangerous phenomenon as a safety incident. The differences and similarities between safety and security are studied. In general, safety is associated with accidental risks caused by component failures, human errors or any non-deliberate source of hazard, while security is related to deliberate risks originating from malicious attacks which can be accomplished physically or by cyber means. In addition, causes of accidents related to safety are internal and considered to be rare events with low frequency. Causes of security accidents can be internal or external (attacks via insider agents or outsiders) and are classified as common events [19].

The National Institute of Standards and Technology (NIST) is in the process of creating a cyber-security testbed for industrial control systems (ICS). This testbed aims to assess an ICS’s performance with cybersecurity protections in line with current standards and guidelines [20]. The standard ASTM F3286-17 (2017) also applies the NIST Cybersecurity Framework to maritime assets and critical infrastructure. The International Electrotechnical Commission (IEC) and the International Organization for Standardization (ISO) have globally developed and issued a number of cybersecurity-related standards. The American Petroleum Institute (API) has developed Recommended Practices (RP), which are applicable to the security assessment of offshore oil and gas assets, both domestically and internationally.

Table 1. List of standards related to cybersecurity.

Standards	Originator	Title
1	NIST (National Institute of Standards and Technology) [21]	NIST Special Publications 800-30, 800-37, 800-82
2	ASTM (American Society for Testing & Material) [22]	ASTM F3286-17, ASTM F3449-20
3	ISO/IEC (International Organization for Standerization/International Electrotechnical Commission) [23]	ISO/IEC 27001, IEC-62443-4-2, IEC 62443-3-3, ISO/IEC 21827, ISO/IEC 15408-1, ISO/IEC 18045, and ISO/IEC 27032
4	API (American Petroleum Institute) [24]	API RP 70, API RP 70I, API RP 780, API Standard 1164

illustrates a compilation of cyber security standards.

The focus of this paper is on assessing legacy ICS systems, and the established frameworks serve as a critical foundation for the proposed assessment methodology. Understanding and incorporating best practices from these frameworks ensures the comprehensiveness and alignment of the proposed hybrid threat modeling approach with industry standards.

The Open Web Application Security Project (OWASP) outlined the objectives of threat modeling. “Threat modeling is a family of activities for improving security by identifying threats and then defining countermeasures to prevent, or mitigate the effects of, threats to the system” [25]. A threat is a potential or actual undesirable event that may be malicious (such as a DoS attack) or incidental (failure of a storage device). Threat modeling is a planned activity that aims to identify and assess application threats and vulnerabilities.

Safety is a critical concern for process industries. Tantawy et al. [26] highlight that there is a need for an integrated approach to design the safety and security of CPS systems. Upon examining the physical behavior of the system, it became evident that not every attack could result in a system hazard; the development of a hazard could take some time, and it might be feasible to neutralize the attack. The authors presented attack scenarios on a testbed with real-world industrial controllers and communication protocols. An attack tree model is used to present the BPCS (basic process control system) runaway and data flow of the system.

This paper explores the application of hybrid threat modeling techniques for cybersecurity assessments of legacy Industrial Control Systems (ICS) in the Oil and Gas sector. Several established threat modeling methodologies exist, each with its strengths and focus areas [27]. The selection of the most suitable approach depends on the specific project requirements and unique security concerns.

The importance of threat modeling in this research is paramount.

• Comprehensive Threat Identification: Threat modeling makes it easier to find a lot of different types of threats, which is important when you think about how many different people have a stake in cyber-physical systems like ICS [27].
• Proactive Security Design: By integrating threat modeling early in the assessment process, you can make proactive architectural decisions. This approach leverages security requirements to mitigate potential threats from the beginning, avoiding costly mitigation efforts later [27].
• Tailored Approach for Legacy Systems: Legacy ICS often lack modern security features, making them more vulnerable. A hybrid threat modeling approach, combining different methodologies, can be particularly effective in uncovering these vulnerabilities within legacy systems.

The evaluation of threat modeling methods (TMMs) against selected criteria, including strengths, weaknesses, adoptability, tailorability, perspective, applicability to CPS, and automation, led to the conclusion that no single method can comprehensively address these aspects. Thus, hybrid threat modeling provides a complete framework for assessing these sophisticated systems by combining multiple threat modeling techniques [21,22,23,24]. Therefore, it is recommended to use a framework that employs a combination of methods and techniques [10].

This research aims to apply a hybrid threat modeling approach, providing a comprehensive and proactive cybersecurity assessment methodology for legacy ICS in the oil and gas sector. The approach has been employed: PASTA, STRIDE & Attack trees, and CVSS. The following list explains the rationale behind the application and advantages of each TMM in this study.

• PASTA’s structure [16], risk-centric approach is suitable for complicated systems like legacy ICS. It prioritizes threats based on their potential business impact, which aligns with the importance of oil and gas infrastructure. PASTA promotes collaboration between security specialists and operational stakeholders, resulting in a more thorough understanding of vulnerabilities to legacy ICS.
• STRIDE [14] is an acronym for a popular technique to categorize common attacks. This technique serves as a platform for discussing potential threats unique to legacy ICS functionality. Thus, STRIDE helps identify a wide range of risks across several categories, ensuring a full assessment of legacy ICS vulnerabilities.
• Attack trees [15] can help discover potential attack vectors and critical control points in legacy ICS. Attack trees provide a clear picture of how attackers can exploit vulnerabilities in legacy ICS, allowing for targeted mitigation approaches.
• CVSS [17,18] provides an established scoring technique for prioritizing vulnerabilities based on their severity and exploitability. This is vital for allocating resources and prioritizing the most critical vulnerabilities in legacy ICS. Thus, CVSS provides a uniform way to examine the security flaws discovered in legacy ICS, resulting in the most efficient use of resources for problem resolution.

Section 2.2 further elaborates on the four threat modeling methods that serve as the foundation for the proposed framework, ensuring the self-containment of the research paper.

2.2. Threat Modeling Techniques

2.2.1. PASTA Threat Modeling

Tony UcedaVélez introduced PASTA [16] in 2012 as a framework for risk-centric threat modeling that encompasses various abstraction layers and takes into account both high-level layers, such as the business logic, and lower layers, such as the concrete attack vectors.

Table 2. PASTA terms.

ID	Term	Meaning in PASTA
1	Asset	A resource that has an intrinsic value to the business. This could include, among others: – Information the business uses, trades, or needs – Hardware, software, frameworks, libraries the business relies on for a subject application – The reputation of the business
2	Threat	Anything that can unfavorably impact an asset.
3	Weakness/ vulnerability	What an attack (supporting a threat) leverages to make its way into the system, either a tangible issue (like a badly configured firewall, cloud component, third-party framework, or RBAC model) or a poor business logic or process (lack of financial oversight on expenses).
4	Use cases	Expected design behavior of the system.
5	Abuse cases	Manipulation of use cases in order to yield ulterior motives of the user (e.g., bypass, injection, information leakage, etc.).
5	Actor	Anything able to perform or use a use case or an abuse case.
7	Attack	Any action that supports a threat motive against a target asset by exploiting a vulnerability/weakness.
8	Attack vector	An interface through which an attack traverses.
9	Countermeasures	Countermeasures Mitigations of a weakness that reduce the probability an attack will be successful.
10	Attack surface	The set of all possible attack vectors, both logical and physical.
11	Attack trees	A representation of the relationship between threats, target assets, associated vulnerabilities, Correlating attack patterns, and countermeasures. Use cases can serve as metadata associated with assets, and abuse cases similarly can serve as metadata for attack patterns.
12	Impact	The direct or indirect financial value of the damage caused by an attack.

summarizes important PASTA terms.

PASTA, which stands for Process for Attack Simulation and Threat Analysis, describes a structured approach to threat modeling that includes seven major stages:

• Define Objectives and Scope: This stage identifies the specific legacy ICS system(s) under evaluation and outlines the assessment’s goals.
• Define Technical Scope: This stage maps out the technical components and data flows within the legacy ICS, resulting in a detailed image of the attack surface.
• Decompose the Application: At this stage, the legacy ICS is divided into smaller, more manageable components to enable a more thorough threat analysis.
• Identify Threats: This stage involves brainstorming potential threats and attack vectors that target the legacy ICS’s specified functionality. Regarding the data, since data is both in storage and transit, it is important to map these threats not just to the data storage, such as databases, but also to the data in transit across the different components of the application, which includes the different servers allocated in the different tiers of the application architecture. During the threat modeling phase, UcedaVélez suggests utilizing STRIDE [14]. This process involves enumerating threats from a list of STRIDE acronyms that impact specific components like users/browsers and authentication credentials, which the attackers consider high-value targets.
• Analyze Vulnerabilities: Based on the identified threats, specific weaknesses, and exploitable faults in the legacy ICS are identified.
• Attack Analysis: This stage entails creating attack trees to visualize how attackers could exploit vulnerabilities and achieve their objectives within the legacy ICS.
• Risk and Impact Analysis: at this stage, the potential repercussions of successful attacks are identified, focusing on corporate operations, safety, and regulatory compliance. This helps to prioritize detected vulnerabilities based on their severity.

2.2.2. STRIDE Threat Modeling

The STRIDE [14] Method is a threat modeling methodology that identifies and categories potential system threats. Each letter in STRIDE represents a specific attack category.

• Spoofing is the act of pretending to be a legitimate user or system in order to obtain unauthorized access to or alter data.
• Tampering is the act of changing code, data, or system configurations with the intention of compromising a system’s integrity or introducing vulnerabilities.
• Repudiation occurs when a system or program lacks the security measures necessary to accurately monitor and record user behavior, allowing for malicious manipulation or falsifying the detection of new actions.
• Information disclosure is the unauthorized access and exposure of private or sensitive data within a system.
• Denial-of-Service (DoS) attacks prevent authorized users from accessing system resources or functionality and bring down the system’s services.
• Elevation of privilege refers to gaining unapproved access or control over a system beyond the scope of authorized authorization.

Moreover, Microsoft [28] defines threat modeling as a process that contains five steps: “1. Defining security requirements; 2. Creating an application diagram; 3. Identifying threats; 4. Mitigating threats; and 5. Validating the mitigation of threats”.

The proposed framework divides step 2 into two stages: creating the architecture over views and decomposing the system using a DFD diagram. Applying STRIDE to a legacy ICS system helps security experts detect a greater variety of potential attacks and weaknesses. This makes it possible to assess the security status of the system in greater detail.

2.2.3. Attack Tree Threat Modeling

The attack trees “provide a methodical way of describing threats against and countermeasures protecting a system”. In an attack tree, the root node represents an attack or attacker goal; the children represent steps required to reach that goal; and the leaf nodes represent different ways an attacker can achieve that goal [15].

Attack trees are a formal and methodical way to identify threats in an abstract model of reality. These were introduced by Salter et al. [29]. Attack trees are organized, like the name says, in a tree structure. The root node of the tree is a possible attacker’s goal. The tree’s leaves indicate the attacker’s final step in achieving this goal. All the intermediate nodes describe cases that the attacker may use to reach the goal.

2.2.4. Common Vulnerability Scoring System (CVSS)

The CVSS [17,18] (Common Vulnerability Scoring System) Framework defines a standardized framework for quantitatively determining the severity of security vulnerabilities. This score helps to prioritize mitigation efforts by showing a vulnerability’s potential impact and exploitability.

CVSS scores vulnerabilities from 0.0 (least severe) to 10.0 (most severe) using three essential metrics:

• The base score indicates the underlying severity of the vulnerability, considering aspects such as exploitability, scope, and the possible impact on the system’s three core security services: confidentiality, integrity, and availability (CIA).
• Temporal Score: This score evaluates both the availability of exploits for vulnerability and the likelihood of successful exploitation. It is a dynamic component that may change over time as new exploits arise. It considers three factors: exploit code maturity, availability of remediating controls, such as a patch, and report confidence.
• Environmental Score: This metric considers the specific characteristics of the target system’s environment that may influence the vulnerability’s ultimate impact. It is adaptable to the asset’s value, the perpetrator’s privileges, and the existing security controls.

Combining these three metrics provides both a comprehensive and useful standardized approach for evaluating vulnerabilities in legacy ICS systems. This allows security professionals to prioritize and focus their mitigation controls and resources on addressing the most critical vulnerabilities that pose the greatest risk.

2.3. Related Work

Khalil et al. [30] present a detailed examination of threat modeling in the context of cyber-physical systems (CPS), with a specific focus on a microgrid system. The paper aims to explore and apply the STRIDE threat modeling technique to cyber-physical systems, using a microgrid system as a case study. The study identifies a range of potential threats to the microgrid by creating a system attack taxonomy and highlighting key vulnerabilities in the system, such as weaknesses in communication protocols, inadequate access controls, and potential points of failure in system integration. The paper suggests that existing threat modeling techniques need improvement to better address the complexities of cyber-physical systems, including developing robust security measures, improving system resilience, and integrating threat modeling with other security practices to safeguard against identified threats.

Khalil et al. [31] provide a comprehensive analysis of existing research on threat modeling methodologies specific to industrial control systems (ICS). The paper systematically reviews the literature on threat modeling techniques applied to ICS, aiming to identify trends, methodologies, and gaps in current research. The authors conducted a thorough review of academic papers, conference proceedings, and industry reports to gather and analyze information on threat modeling approaches used in the context of ICS and proposed an ICS threat modeling taxonomy to address specific vulnerabilities and threats inherent to ICS environments. The authors list a number of problems that come up when trying to model threats for ICS, such as the need for models that can change quickly to keep up with new threats and the need to include real-time threat intelligence. They also stress how important it is to keep improving threat modeling methods to make industrial control systems safer and more resistant to new threats.

Recent research [32] reviewed the growing threat of cyber-attacks on industrial CPS in the offshore oil and gas industry as a result of technological advancements, the digitalization and integration of oil field equipment with corporate networks, and the need for remote monitoring and control. The study also looked at a typical subsea control system architecture and showed how vulnerable it is to MiTM, DoS, and spoofing attacks by connecting these types of attacks to one or more layers of the architecture. Those were linked to documented cybersecurity incidents affecting the upstream oil and gas industry.

In line with one point of view in this paper about how important it is to protect critical manufacturing infrastructure (CPS) from high-level cyberattacks, Yazdandoost et al. [33] created the first taxonomy-driven graph-theoretic model and framework to formally show this specific cybersecurity threat landscape and find manufacturing assets that are vulnerable and need immediate control. The proposed framework offers a critical step toward aiding researchers and practitioners in identifying the most critical connections and assets in a discrete manufacturing system. The proposed framework utilizes an attack graph formalism to integrate various threat attributes into the risk model, thereby enabling the simultaneous modeling and analysis of diverse cybersecurity threats with varying attack attributes. Moreover, attack graphs are used to model the cascading attack impact through different cyber and physical entities in manufacturing systems, leading to specific consequences. In addition, a quantitative model to estimate the cybersecurity risk associated with the identified attack paths, risk mitigation strategies, and recovery plans during threat events will be investigated using graph-theoretic tools.

In FY 2016, the research team and N. R. Mead evaluated three threat models (security cards, STRIDE, and persona non grata (PnG)). This project aimed to determine which of these methods was the most effective in identifying threats. They employed two scenarios: an aircraft maintenance scenario and a drone swarm scenario, in addition to the project’s outcomes. No individual threat modeling method included all identified threats. The research team subsequently developed the Hybrid Threat Modeling Method (HTMM) [34].

Also, Dag Eng et al. [35] devised a new way to make an integrated TMM that combines asset-, attacker-, and software-centric methods. They then examined the integration of various techniques to create a unified output. The research answered the question of what the advantages and disadvantages are when using an integrated threat modeling approach. The technique consists of three questionnaires, one for each approach. They extract and combine each participant’s response to a single questionnaire to identify the threats present in all the different approaches. The method presented is generic and depends on the participant’s answers, which could vary greatly from participant to participant.

Additionally, Krishnan [36] developed a hybrid approach that combined multiple classic threat modeling techniques. Sriram studied the limitations of three threat models: STRIDE, Attack Tree, and Attack Library. Combining techniques allows us to overcome limitations such as a lack of countermeasures, varying levels of abstraction about scenarios, and ensuring completeness. The proposed procedure is linear. The process begins with a design analysis phase, then proceeds to the threat identification and categorization stages, utilizing STRIDE and attack trees, and concludes with a threat mitigation phase that utilizes attack libraries.

Furthermore, Potteiger et al. [37] present a quantitative, integrated threat modeling approach that merges software and attack-centric threat modeling techniques. They leverage the Common Vulnerability Scoring System (CVSS) to provide a standardized method of quantifying the low-level vulnerabilities in the attack trees. The paper concludes that providing a systemic, quantitative method of modeling system risk is one step toward providing a definitive, scientific approach to measuring the security of CPS systems.

However, despite the benefits, there is still a need for further development of hybrid threat modeling frameworks specifically suited for legacy ICS cybersecurity assessments in oil and gas. Potential areas for improvement include industry-specific focus, enhanced usability that balances comprehensiveness with ease of use, and consideration of the specific challenges of legacy ICS environments. This paper presents a threat modeling approach for ICS focused on specific industries that involve classifying ICPS assets and then analyzing the cybersecurity vulnerabilities, threats, risks, impacts, and countermeasures.

3. The Proposed Hybrid Threat Model

Almost every industry that uses automation to control processes has legacy systems, which are insecure by design. Applying cybersecurity to industrial control systems (ICS) with aging hardware and software, which are particularly vulnerable to cyberattacks due to their outdated technology and lack of support from original equipment manufacturers (OEMs), presents a significant challenge. The first method to modernize the legacy system involves replacing it, a process that incurs significant costs due to the replacement project fund and potential production loss. The second method involves the organization implementing a comprehensive security strategy specifically designed for the legacy system.

This paper proposes a framework to assist the organization in developing a security strategy for its legacy system, thereby mitigating cost-related challenges. We will combine three threat modeling methods (PASTA, STRIDE, and attack trees) as discussed in Section 2 and shown in Figure 4. This framework uses PASTA modeling as its foundation. The 7-stage PASTA threat model can be applied to existing projects or during the definition phase of a new project. The framework organizes the simultaneous application of multiple threat modeling approaches, resulting in a single set of outputs. Furthermore, the MITRE ATT&CK framework provides a comprehensive dataset of known adversary tactics, techniques, and common mitigations, facilitating the creation of a threat library that serves as a comprehensive input for vulnerability analysis, attack analysis, and mitigation planning. Moreover, we employ CVSS to ascertain the system’s risk score, both prior to and following the mitigation phase, thereby quantifying the system’s vulnerability score and evaluating the efficacy of the mitigations. Thus, the proposed model helps discover a wider range of threats.

PASTA/STRIDE Stages (I to VII)

Stage I: Defining Security Objectives. Determining the objectives, whether internal, external, or driven by your user base, is the first step in the PASTA methodology. You should clearly understand the purpose of the application. How does it generate revenue for your company? What regulations should the application incorporate? Unlike traditional, static threat modeling methods, PASTA stage one gives you the opportunity to incorporate governance into these discussions and bake it in from the very beginning.

Furthermore, the first STRIDE step is to identify and document the assets, data, functions, user interfaces, and infrastructure. Record these elements to gain a comprehensive understanding of the areas that require protection.

At this stage, the following inputs are required to attain the desired output: (1) The business requirement document is used to define the business goals and objectives for the system. This helps identify what needs to be protected and the prospective impact of a security breach on the system’s business goals. (2) The functional requirement document describes the system’s features and, for each feature, who uses it, how it operates, its workflow, data used or generated by the feature, and the external entities it deals with. This helps understand the system’s attack surface. (3) The Information Security Policy summarizes how the organization manages its data, handles data distribution, and its disposal. That is to ensure that the threat model aligns with existing security policies and identifies areas where the system might need additional security measures. (4) The Security Standards and Guidelines establish best practices for the development of secure systems. (5) The Data Classification Documents: classifies data based on its sensitivity. This is done to prioritize threats based on the potential impact on data and identify areas where additional security controls might be needed for more sensitive data. Inputs, activities, and outputs of stage I are summarized in Figure 5.

Stage II: Define the Technical Scope of App Components. Stage 2 of PASTA is to understand your attack surface by defining your technical scope: know what you are protecting. Under-scoping is a common theme among professionals in application security and product security, as they concentrate solely on the application domain. When defining an attack surface, you should understand what you are running with and what sorts of dependencies you might have with third-party services. This can include features created by a developer, systems maintained by an engineer, or components monitored in the infrastructure.

Furthermore, the second STRIDE step is to create the system overview (logical or structural components). Components can be internal processes or elements communicating internally within the system or external elements communicating with the system.

At this stage, the following inputs are required to attain the desired stage output: (1) High-Level Design Documents that provide an overall system view, including the system’s main components, database design, platforms, and the relationship between the system’s components. (2) Logical & Physical Architecture Diagrams: Logical Architecture Diagrams represent the system’s functional components and their relationships without focusing on physical implementation details. Physical Architecture Diagrams: represent the physical layout of the system, including its hardware, software, and network details. This aids in identifying security risks associated with physical components and how they might impact the systems’ security. (3) Software and Technical Specifications: These documents provide an in-depth explanation of the technical implementation of the system, including its functionalities, data storage, processing methods, and communication protocols. This information assists in the identification of software vulnerabilities that could potentially compromise data security at runtime. Inputs, activities, and outputs of stage II are summarized in Figure 6.

Stage III: Decompose the Application. In this stage, you should produce data flow diagrams. It is best to work with your architecture to understand the calls and integrations you discovered in stage 2. The DFD uses four standard symbols: (i) External Entity (EE), i.e., endpoints of the system; (ii) Process (P), i.e., units of functionality; (iii) Data Flow (DF), i.e., communication data; and (iv) Data Store (DS), i.e., database, logs, or file. Data flow diagrams alone are not a threat model. A data flow diagram illustrates the flow of data between callers across trust boundaries, but it fails to depict threats. It doesn’t tell a developer or engineer what they should be worried about; it provides a map for analysis.

Similarly, the third STRIDE step is to decompose the system and plot a data flow diagram (DFD) for each system component that visualizes its functionalities within or external to the system.

The following inputs are required to achieve the required outputs at this stage: (1) Design documents for architectural diagrams: In these documents, the design of the system—both logically and physically will be looked into. Such an integrated view makes it possible to define more precisely the components responsible for processing, keeping, and transmitting data at every step. (2) Physical—Network Diagram: This diagram shows how devices are connected in the network infrastructure, like servers, desktops, switches, routers, etc. Using this diagram, one can easily determine the possible threats to network configuration in terms of security or data loss during their transfer across different parts of the system. (3) Logical diagrams illustrate the components of the system and how they relate to each other rather than defining their exact implementation. It is important to study the logical sequence of signals travelling from one module to another to locate weaknesses in certain activities plus uncover probable malicious alterations that can take place when the information is being manipulated. (4) The Security Standards and Guidelines establish best practices for the development of secure systems. During the decomposition stage, it can be used to compare the application’s analysis and design against these standards to identify the areas where the data flow does not comply with secure design best practices. This helps pinpoint potential vulnerabilities that could be exploited by attackers. (5) Data Classification Documents: classify data based on its sensitivity. This is done to prioritize threats based on the potential impact on data and identify areas where additional security controls might be needed for more sensitive data. This helps you focus your efforts on the most critical data flows within the application. Inputs, activities, and outputs of stage III are summarized in Figure 7.

Stage IV: Analyze the Threats. In PASTA, the main output of its fourth stage is to understand what types of threats are affecting your defined attack surface. Simultaneously, the fourth STRIDE step is analyzing the threats in the DFD of each system component based on each system component and its functionality.

The following inputs are required to achieve the required outputs at this stage. (1) Security Incidents Report: This report indicates an organization’s or similar system’s past security incidents. Analysis of these incidents helps reveal attack patterns as well as weaknesses that may be used for attacking your application. Anticipation and prevention of similar threats and acting against them in advance are possible through learning from previous occurrences. (2) Secure Incident Event Monitoring Reports (SIEM): reports from SIEM aggregate security event data from many different sources. An analyst could use this information to see some rogue behaviors within an application that may be pointers to actual or possible intrusion attempts. This will help catch and take care of malevolent actions quickly enough. (3) Application and Server Logs: application and server logs record system errors and access attempts. Suspicious user behavior or unauthorized access attempts may be discovered from application logs analysis. Server logs might provide insights into system vulnerabilities that attackers could exploit. (4) Threat Intelligence Reports: Reports on threat intelligence give details on vulnerabilities, attack paths, and current threats. This kind of external information will enable you to identify prospective attack scenarios relevant to your application as well as help you grasp current attacks aimed at similar systems. This way, security is approached proactively. Inputs, activities, and outputs of stage IV are summarized in Figure 8.

Stage V: Vulnerability Analysis. This stage’s aim is to identify the root cause of the issue. What are the application’s issues, not only in terms of potential vulnerabilities found in the code base through static analysis but also in terms of the design itself? What issues with the trust model did the third stage identify? Several factors contribute to vulnerability, such as flaws or weaknesses found during manual security testing, architecture flaws or weaknesses derived from the data flow diagram, and various types of vulnerability scanners, among others.

The following inputs are required to achieve the required outputs at this stage: (1) Library of Threat Trees: A pre-built library of threat trees helps with identifying various potential threats by using structured methods according to diverse attack categories. They help to guide the analysis work and ensure that there is a wide range of threats to think about for the cutting-edge nature of applications’ functionality as well as how they handle information. (2) Attack Scenarios (from Stage IV): Stage 4 was all about identifying potential threats. Stage 5 is like putting into action all the attack scenarios that resulted from the previous stage. It is believed that, when done thoroughly for each scenario, the exact location of a potential hole in the application that an attacker could exploit when planning an attack can be determined. More importantly, through this process, high-risk vulnerabilities are given priority according to how likely they are to be exploited. (3) Standards for Vulnerability Enumeration (MITRE, CWE, CVS) are standardized vulnerability databases that classify and provide descriptions for known software and system vulnerabilities. Using such databases enables one to rapidly look for any possible vulnerabilities in the components and libraries they utilize, hence saving time and avoiding missing any obvious flaws. (4) Standards for vulnerability scoring (CVSS) Framework defines a standardized framework for quantitatively determining the severity of security vulnerabilities.

Inputs, activities, and outputs of stage V are summarized in Figure 9.

Stage VI: Attack Analysis. The key objective for stage 6 of PASTA is to demonstrate that the things found vulnerable in stage 5 are actually feasible. To build a powerful attack model, you want to use attack trees. Using attack trees allows you to map known vulnerabilities to a node on the attack tree to determine its likelihood.

The following inputs are required to achieve the required outputs at this stage: (1) Application Technical Scope (Stage II): The boundaries of the application are defined by the information obtained in Stage 2. Knowing this scope of technicality for any attack surface definition means the possible entry point that could be used by attackers, hence allowing them to carry out their mission successfully because they are familiar with it. This helps focus the analysis on vulnerabilities within the defined scope and identify the most likely attack vectors. (2) Application Decomposition (Stage III): Having such a detailed breakdown enables analysts to link a specific weakness they have found to certain modules or segments of that program. This will enable you to comprehend how one component’s weaknesses could be used by hackers to gain access to other segments within your software or important information therein. (3) Attack Libraries-Patterns: Attackers using common attack patterns often use these libraries. So, by referring to these patterns and applying them to the identified vulnerabilities, it is possible to imitate potential attacks. They help see things from the attacker’s point of view as well as anticipate what their next move might be, enabling engineers to design better mitigation measures. (4) List of Threats, Attacks, and Vulnerabilities to Application Assets (Stage V): The application vulnerabilities corresponding with the threats that could potentially harm it were identified in stage 5, while in the same stage, attacks were classified into various categories. In stage 6, this list forms the basis for generating vulnerability-related attack scenarios: These attacks’ feasibility is evaluated, and common attack paths are identified. By doing this, an organization can assign resources for risk reduction by attempting to address the most likely threats. Inputs, activities, and outputs of stage VI are summarized in Figure 10.

Stage VII: Risk and Impact Analysis. At the end of the day, PASTA threat modeling is about reducing risks. The ultimate objective of stage 7 is to construct countermeasures that effectively mitigate significant threats. To finalize the threat modeling exercise, we want to utilize and tie back the information from stages one through six. At this stage, we integrate the Common Vulnerability Scoring System (CVSS). It provides a security score based on a set of metrics. This helps to optimize mitigation efforts by ranking potential vulnerabilities based on their CVSS scores. The proposed model not only utilizes CVSS for assessing the identified vulnerabilities but also assesses the suggested mitigations’ effectiveness.

The following inputs are required to achieve the required outputs at this stage: (1) The technical scope defines the boundaries and components of the application/system under investigation, focusing thereby the risk and impact analysis on the specific parts of the application that are relevant and ensuring that all critical components and interactions are addressed in the risk assessment. (2) Attack scenarios (from stage IV): Attack scenarios are descriptions of possible ways to attack vulnerabilities found within the system. These are important for stage 7, which provides concrete examples of risks manifesting in the application. The analysis of these attack scenarios allows teams to evaluate the chances or possibility as well as the damage that each scenario presents, thus prioritizing risks as well as mitigations. (3) Application decomposition (stage III): The application/system is broken down into smaller components/modules to simplify the processes. It is at this point that the system’s dependence on one another is studied. For you to assess the way in which risks may spread in an entire system via an application, there is a need for you to understand these aspects at stage 7. (4) Threat analysis (stage IV): At the stage of threat analysis, it is important to identify and characterize threats that could affect the system. Understanding the nature and capability of such threats will enable the concerned team to assess how likely they are to occur as well as what their effects would be on the security and operation of the system. (5) Vulnerability analysis (stage V): vulnerability analysis shows the precise security vulnerabilities that would enable a malicious user to take advantage of them in a system or an application. This review stage is crucial for phase 7 because it helps to quantify the effect of weaknesses on the security posture of a system as well as the general risk profile. Thus, it directs the attention towards very important vulnerabilities, causing serious threats to the system’s safety. Additionally, it is useful in terms of prioritizing vulnerabilities according to their severity and impact on the application. Inputs, activities, and outputs of stage VII are summarized in Figure 11.

4. Case Study & Performance Evaluation

The Oil and Gas (O&G) sector is one of the most important Critical Infrastructure (CI) sectors for the economy. Oil and gas infrastructures are divided into three broad categories: upstream, midstream, and downstream infrastructures. Upstream organizations generally include Exploration and Production (E&P) of oil and gas, which comprises offshore and onshore operations. Midstream generally refers to the transportation, processing, and storage of oil and gas treatment, while downstream refers to the manufacturing, refining, petrochemical, and retail of petroleum.

The oil and gas industry uses different types of industrial automation, such as programmable logic controllers (PLC), distributed control systems (DCS), and supervisory control and data acquisition (SCADA). This research’s case study pertains to downstream infrastructure (onshore refinery), which encompasses the facilities and systems involved in refining, processing natural gas, and distributing it as final products. This sector focuses on converting raw materials into usable products like liquefied natural gas (LNG).

The oil and gas industry utilizes the Industrial Control System (ICS) as a type of control system for large-scale and complex processes. ICS helps monitor and control various process variables and equipment spread across a plant or facility. ICS components are:

• Field Devices, Control Modules, Human-Machine Interface (HMI), Communication Network, Data Historian, and Engineering Workstation.
• Configuration and Engineering Software that belongs to ICS vendors.
• Real-Time Data: Process variables (temperature, pressure, flow rates), Equipment status (running, stopped, faulted) Control signals (setpoints, feedback).
• Historical Data: Time-series data on process variables, historical trends, and event logs. Performance metrics and analysis results.
• Alarms and Events: System alerts, operational events, operator interventions, and fault and error logs.
• Communication Protocols: Modbus, Profibus, HART, OPC, Ethernet/IP.

Section 4.1 shows the step-by-step application (PASTA, STRIDE, Attack Tree & CVSS) of the framework.

4.1. Applying the Proposed Framework

In this section, we will verify the proposed framework using an actual onshore gas production system (ICS). A refinery is made up of continuous processes, and a failure in one process can have an impact on the next process and, consequently, the entire production process. Its ICS is essential for its continuous operation. The basic components of ICSs in refineries are similar, regardless of the production process.

The ICS is important for the principles of the CIA triad in the following order: availability, integrity, and confidentiality. By guaranteeing availability to transfer commands or responses within a set time period, ICS achieves its security objective of operating safely without an unplanned shutdown. Integrity must be ensured to transmit accurate values to field devices without any tampering. Finally, confidentiality must be ensured to prevent unauthorized individuals from accessing the process operation and product recipe know-how.

Table 3. STRIDE—Threat Analysis & Categorization vs. CIA3.

Threat	Security Property	Threat Definitions	Explanation/Example
Spoofing	Confidentiality, Integrity	Impersonate vendor/app actor/domain/network actor/employee/trusted relationship	A malicious user (or agent) pretends to be someone else, (s)he uses other user’s credentials to access the system.
Tampering	Integrity	Alter records/product/device/integrity of software	The content within the targeted system is altered by the malicious external party.
Repudiation	Nonrepudiation	Anonymized remote activity/Erase log information	Content or system has been misused or tampered with, but we cannot prove it due to the absence of proof, such as an audit trail.
Information disclosure	Confidentiality	system configuration and credential information can be used	The information is exposed to parties that do not/should not have access to it. Information leaks and data breaches are common examples of information disclosure.
Denial of service	Availability	DoS/Distrusted DoS	System/information is not available to a legitimate user.
Elevation of privilege	Authorization	Elevate to actor privileges on app level/Elevate to actor privileges on system level/Change data in the database.	Malicious or rightful users get more privileges on the content than they are entitled to.

shows the six threats in STRIDE and explains the acronyms and the security attributes associated with each, thereby mapping the threat classes with the actual risks [38].

• Stage I: Defining Security Objectives

Goals of this stage: The first stage’s goal is to define the objectives for analyzing and managing the various types of cybersecurity risks affecting the ICS.

• Output 1—Description of the Application Functionality and Business Objectives:

The ICS System consists of a minimum of the following components, as shown in the abstract architecture in Figure 1.

• Field Control Station (FCS): It consists of input/output modules, a CPU, and a communication bus.
• The operator station is essentially a human interface machine equipped with a monitor, allowing the operator to view the plant’s processes, check for any alarms, change settings, and print reports, among other tasks.
• The engineering station configures all input and output, creates drawings, and monitors anything necessary for the operator station.

The most noticeable benefit of systems architecture is its contribution to the design of an integrated plant-wide information and control system through the distribution of various functions throughout the plant. This allows operators and unit supervisors to identify conditions beyond their purview, such as upstream or downstream bottlenecks or plant utility constraints, and initiate corrective measures before these factors negatively impact their operations.

Distributed architecture can provide functionally dedicated stations to various disciplines, e.g., maintenance and engineering, so that system and process information can disperse throughout the plant without interfering with operations. For example, without leaving the maintenance shop, the operator can check pressure drops across heat exchangers to determine the degree of fouling. Basically, a distributed control system (DCS) Figure 2 receives input signals from other devices; the DCS-CPU processes and analyzes these signals and then acts based on the results. Numerous sensors and transducers inside the plant transform physical quantities such as pressure and temperature into electrical signals, known as transmitters, which are then transmitted to the DCS system.

• Output 2—Definition of the Application Security and Compliance Requirement

NIST Special Publication 800-82r2 (Guide to Industrial Control Systems (ICS) Security) [13] states that an ICS implementation should include the following major security objectives:

• Restricting logical access to the ICS network and network activity.
• Restricting physical access to the ICS network and devices.
• Protecting individual ICS components from exploitation.
• Restricting unauthorized modification of data.
• Detecting security events and incidents.
• Maintaining functionality during adverse conditions.
• Restoring the system after an incident.

• Stage II: Define the Technical Scope of App Components.

Goals of this stage: The goal of this stage is to enumerate the details of technical components, including architectural and software components, that are scoped for conducting the threat modeling exercise in Figure 3. Once this stage is complete, we will generate a detailed description of the technical stack, encompassing the layers of components and services used by the application, including the network infrastructure layer and the third-party infrastructure layer.

• Output 1—High-Level View of Application Architecture.

Table 4. Real ICS system Architecture components.

Asset Categry	Asset Types	Title
Edge Devices	Sensors & Actuators	Pressure/Temperature/level/Flow Control valves
Network Device	Switches & I/O module Hard wire	Hardware
Control Devices Servers	DCS & PLC controllers Historian & Data Servers	Inteligent control center
Communication Protocols	2 wire, HART, Field Buss, & Ethernet	Bus/Ring/Line/Star topology
Human-Machine Interface (HMI)	Engineering/Operator Station	Application Software

elaborates on the asset category, asset types, and titles of the actual ICS system architecture components. The essential components of ICSs have the following roles and significant functions: (i) An operator uses OWS to monitor and adjust set-point values. (ii) An engineer uses EWS to manage controller setting information. (iii) A controller is a device that receives measurements from sensors and sends control signals to actuators to maintain a desired process variable. The ICS server provides screen values and user profile information to the operator workstation (OWS).

• Output 2—List of All Application Servers, Hosts & Network devices.

• Capture the boundaries of the technical environment.

  ○

  Application components

  ○

  Network topology

  ○

  Figure 3 illustrates the protocols and services that the user uses and exposes to the backend.

• Capture infrastructure (applications/software).

  ○

  Operating systems: Windows

  ○

  Underlying database: Available

  ○

  Cloud hosting: NA

• Stage III—Decompose the Application.

Goals of this stage: Figure 3 analyzes the security controls and interactions between the basic components of the ICS. Users, roles, data storages, data flows, functions, security controls, and trust boundaries are examples of components that can describe the security of the application architecture.

• Output 1—Data flow diagram.

The third step is to decompose the target system into its logical components using a DFD (Figure 12), which helps to visualize the functionalities and communication between components within or outside the ICS.

Table 5. Case Study DFD Elements List.

DFD Element Type	DFD Item Number	DFD Element Function
External Entities	System Operator (user)-EE1	Monitors and controls the operation of the system
	Maintenance Engineer (user)-EE2	Repair and maintain the process control systems
Processess	Field Devices Process (P14,15&16)	Collect various kinds of data from different sensors/actuators. Send and receive data from the controller.
	DCS Controller (P10,11,12&13)	Provides management feedback/target set point for the process control system. Uses a control algorithm to generate required output variables and transmits them to the actuators.
	Historian (P17,18&19)	A centralized database storing all process information within an ICS environment.
	DCS Server (P7,8&9)	Enable communication between most elements of a control system.
	Human-machine Interface (OWS-EWS)	Monitors entire plant parameters graphically, enabling operators to visualize/control process data. Enables maintenance engineer to connect to the system & perform control/update of the algorithm. Data entry and exit points from sensors and actors via manual data entry screens to interfaces.
Data Flow	DF1 & DF2	Data input/output between local devices/Analog module/digital module and controller.
	DF 7,8,9,&10	Login, read, write, and configure
	DF 3,4,5,6,11 &12	Connecting all system components and facilitating data transfer and manipulated data between them.

shows the DFD element list.

• Output 2—List of Assets, Interface, and Trust Levels.

The business relies on ICS assets for a subject application, which includes hardware, software, frameworks, and libraries. There are multi-interface points between the four levels of the system (field, control, supervision, and management); each of these has a trust boundary.

• Application: Industrial control system for onshore oil and gas plants.
• Actors: Humans (operators and maintenance engineers).
• Assets: Hardware (field devices, input/output modules, controllers, servers, and workstations) and software (installed S/W, packages, embedded systems for interaction with the application ecosystem).
• Data Repositories: Includes file systems, file data repositories, and cached memory, all of which can store data.
• Trust Boundaries: Although not tangible objects, they become more clearly defined as part of the process of dividing up application components.
• Interfaces: The single-loop controller connects sensors and actuators through point-to-point wiring and integrates with the corporate network to provide business operations with a production view. Additionally, a programming interface on an engineering workstation provides access to the controller, while a data historian stores data, all connected over a LAN.

• Stage IV—Analyze the Threats

Goals of this stage: The goal of PASTA’s Threat Analysis (TA) stage is to conduct the threat analysis within the scope of the application or product. The purpose of this threat analysis is to identify the types of cyber threat agents. Similarly, by using the details from the previous steps in the STRIDE phases, threats relevant to the application scenario and context can be generated.

• Output 1—List of Threat Agents & Attack Vector.

Figure 13 shows the ICS source of threats. These threat agents may deliberately or opportunistically target the application’s scope. Initially, it is important to capture the threat environment, which depends on the business and technical environment in which the application operates. This initial analysis is necessary to characterize the threat landscape.

Formal methods for threat analysis can facilitate and standardize the execution of this stage. To conduct a comprehensive threat analysis using DFDs, an attack library is needed. An attack library collects a variety of attacks to identify potential threats within applications. Information that can serve as an attack library includes MITRE’s common attack pattern enumeration and classification, common vulnerabilities and exposures (CVE), ICS-CERT reports, NIST SP 800-30, and widely documented cybersecurity incidents for ICS. To complete the threat library, gather threat information from external threat sources. We will use the following two sources.

• The main focus of ATT&CK (Figure 14) for ICS, a list of all 12 tactics in ATT&CK for ICS, and a list of all 78 techniques [39] is on the systems and functions that are part of functional levels 0–2 of Purdue Architecture [40] (level 0 as a sensor, level 1 as a controller, level 2 as an operator, and engineering work station. Adversaries are typically required to control these systems and functions for ICS to have an impact.
• Table 6. Real-world ICS breach.

  ID	Year	Entity Breached	Tactic	Attack Name
  1	2010	Iranian nuclear plant	The Stuxnet worm initially infiltrated the plant via a USB stick, which then targeted control software used to program the operation of the uranium centrifuges.	USB
  2	2011	Energy sector operations in the U.S., Switzerland, and Turkey	The group DragonFly was established in 2011 but became increasingly active in 2017, using remote access tool (RAT) malware by way of spear phishing, trojanized software, and watering hole attacks.	RAT
  3	2013	Multiple ICS targets in energy and pharmaceuticals	The group Energetic Bear used watering holes and phishing attacks for espionage and reconnaissance.	phishing attacks
  4	2015	Ukraine’s electrical grid	Industroyer is a type of malware that was used to control electricity substations and circuit breakers.	malware
  5	2017	Saudi-Arabian petrochemical plant	Adversaries used TRITON malware to bypass physical safety systems. They moved laterally through the network for over a year, renaming files and mimicking regular processes until they accessed the ICS’ safety instrumented system (SIS).	malware
  6	2018	Over 200,000 entities in energy, manufacturing, oil & gas, petrochemical, and others in over 150 nations	Attackers used WannaCry in a ransomware attack to exploit a Windows vulnerability and encrypt data.	WannaCry in a ransomware
  7	2021	Colonial Pipeline Attack	hackers obtained access to Colonial Pipeline Co.’s networks using a virtual private network account.	ransomware

  shows a real-world ICS breach summarized from [41,42].

By referring to STRIDE stages I, II, and III and Table 3 and Table 6, threat analysis results are summarized in

Table 7. Threat modeling using STRIDE-per-element methodology.

ID	Term	DFD Element
1	Spoofing/Impersonation EE-1, EE-2	P-1, P-2, P-3, P-4, P-5, P-6, P-10, P-12, P-16, P-17, P-18, P-19
2	Tampering of Data	P-2, P-3, P-4, P-5, P-7, P-8, P-9, P-10, P-11, P-12, P-13, P-14, P-15, P-16, P-17, P-18 DF-1, DF-2, DF-3, DF-4, DF-5, DF-6, DF-7, DF-8, DF-9, DF-10, DF-11, DF-12
3	Repudiation EE-1, EE-2	P-1, P-2, P-3, P-4, P-5, P-6, P-8, P-12, P-13, P-14, P-16
4	Information disclosure	P-1, P-3, P-6, P-7, P-12, P-14, P-16, P-19, P-18, P-19, DF-1, DF-2, DF-3, DF-4, DF-5, DF-6, DF-7, DF-8, DF-9, DF-10, DF-11, DF-12
5	Denial of service	P-1, P-2, P-3, P-4, P-5, P-6, P-9, P-12, P-14, P-15, P-16, P-17, P-18, P-19 DF-1, DF-2, DF-8, DF-4, DF-11
6	Elevation of privilege	P-1, P-2, P-3, P-4, P-5, P-6, P-7, P-12, P-14

.

The system diagram analysis is based on the STRIDE-per-Element Model, which provides a prescriptive approach to threat modeling (see

Table 8. Mapping STRIDE Threats to the Proposed Attack Taxonomy.

STRIDE Element	Precondition	Possible Attack Vector(s)	DFD Element
Spoofing	Device Compromise or Network Compromise	Spoofing Attacks	Entity& Process
Tampering		Integrity Attacks	Data Flow, Data Store & Process
Repudiation		Delete/Corrupt Data	Entity, Data Store & Process
Information Disclosure		Data leakage	Data Flow, Data Store & Process
Denial of Service		Availability Attacks	Data Flow, Data Store & Process
Elevation of Privilege		Escalation of Privilege	Process

).

• Stage V—Vulnerability Analysis

Goals of This Stage: Weaknesses and vulnerabilities will be analyzed, and their correlation with the previously analyzed threats will be established. Any existing vulnerabilities and weaknesses of ICS will be reassessed, including its various components, software, servers, and network, during this stage. Figure 15 elaborates a mapping of threats to vulnerabilities and control weaknesses (design flaws) of the application, software, and systems in scope at the end of this stage.

• Output 1—Map of Existing Vulnerability to the Nodes of Threat Tree as per Figure 15.

Output 2 and 3 (Enumeration of vulnerabilities using CVE & Scoring of vulnerabilities using CVSS) will be presented later.

• Stage VI—Attack Analysis

Goal of This Stage: The goal of this stage is to analyze and model the attacks against the application. Attack trees determine the most likely attack paths that lead to exploits and identify potential vulnerabilities and security controls for circumvention. An attack tree models each step of the attack as an opportunity for the attacker to take the next step until they reach the desired goal. We can analyze the realization of an attack by assigning conditions to each node of the attack tree. An attacker can choose either “OR” (one attack or another) or “AND” (both attack paths) at each node of the attack tree (Figure 16). The expansion of the hardware as one of the attack methods leads to the consideration of the hardware attack as one of the attack methods, alongside the expansion of other methods.

• Outputs of Stage VI

Figure 16 presents one branch of attack trees with attack scenarios for targeted assets and an attack tree mapping to vulnerabilities for impacted assets. Additional attack scenarios mapping to vulnerabilities, such as software and networks, can be conducted.

• Stage VII—Risk & Impact Analysis.

Goal of This Stage: The goal of this last stage is to analyze the risk of each threat and attack scenario and recommend countermeasures or security measures to detect and protect from the various attack scenarios.

• Output 1—Threat, attack, vulnerabilities, and business impact.

In Figure 17, the hardware attack is expanded to three different attacks and is started with the successful USB attack to demonstrate the impact and countermeasure. Similarly, others can be expanded.

• Output 2—Residual risk to business.

A generic formulation for calculating risk is based on the definition of risk as “the likelihood that a threat will exploit a vulnerability to cause an impact to the system” [16].

$$Risk=Threat\times Vulnerability\times Impact$$

(1)

Multiple coefficient values reflect the likelihood of the following events:

• The probability of successfully exploiting a vulnerability or a group of vulnerabilities increases.
• There’s a chance that the attacker can access the attack vector and has the time and resources to carry out the exploit.
• The threat affects the CVSS, which uses updated information from the analysis of threats, vulnerabilities, and attacks to determine the severity of each security control’s vulnerabilities.

The risk associated with threat can be quantified using the following equation:

$${Risk}_t={Threat}_{Pt}\times Vulnerability\times {Impact}_{It}$$

(2)

$$Total Risk={\sum }_{i=1}^n{Risk}_{ti}$$

(3)

where

• ${Risk}_t$: is the value of threat t.
• ${Threat}_{Pt}$: is the probability of threat t to exploit the vulnerability.
• ${Impact}_{It}$: is the impact of threat t if it is successfully exploiting the vulnerability
• n is the number of identified threats

• The first step is to assess the likelihood that threat events will be initiated (likelihood or probability of occurrence) see

  Table 9. Likelihood or probability of occurrence of threat.

  Likelihood	Description	Threat Level
  Highly Likely	Occurrence several times per year Every one to 3 years in this facility Target attractiveness: primary and desirable target	High 4
  Possible	Occurs every 5 to ten years in this facility Target Attractiveness: May be a desirable target or potential target of attack	Medium 3
  Unlikely	Heard of in specific sectors but not in the operation facility Target Attractiveness: may be a desirable target or potential target for Attack. May not be worth the effort to achieve due to fully managed control implementation.	Low 2
  Very Unlikely	Never heard of this in this industry Target attractiveness: Not a potential target, Limited scope	Very Low 1

  .
• The second step is to assess the vulnerability once it is initiated or occurs (Threat capabilities); see

  Table 10. Threat capability rating.

  Threat Capability Criteria	Threat Capability Rating
  Extensive Knowledge skill/Extensive resources	Low 1
  Limited Knowledge skill/extensive resources Extensive Knowledge/limited resources Moderate Knowledge skill/moderate resources	Medium 2
  Limited Knowledge skill/limited resources	High 3

  .
• Finally, organizations assess the overall likelihood as a combination of the likelihood of initiation/occurrence and the likelihood of resulting in adverse impact see

  Table 11. Threat Score Level.

  Threat Score		Threat Capability
  		Low 1	Medium 2	High 3
  Likelihood	Very Unlikely: 1	1 Very Low	2 Low	3 Medium
  	Unlikely: 2	2 Low	4 Medium	6 Medium
  	Possible: 3	3 Medium	6 Medium	9 High
  	Highly Likely: 4	4 Medium	8 High	12 Very High

  Light Green: Very Low Threats [No threats]; Green: Low Threats; Yellow: Medium Threats; Purple: High Threats; Red: Very High [Critical] Threats.

  .
• Threat capability rating is the likelihood that an attack will be successfully realized based on the capability of the attacker to target a specific vulnerability.
• Finally, the threat Score is calculated as shown in Equation (4).

$$Threat Score={Threat}_{Pt}\times Vulnerability$$

(4)

$$Risk=Threat Score\times {Impact}_{It}$$

(5)

For example, the severity of one of the vulnerabilities will be calculated by assigning values to each of the base metrics and creating the base vector as follows:

Hardware (Network) vulnerability severity or impact score is

Vector String = AV: [N]/AC: [L]/PR: [H]/UI: [N]/S: [C]/C: [H]/I: [H]/A: [H] Base Score = 9.1 (Critical)

The Base Score breakdown includes:

• Less than 0.1 = No threat to the system
• 0.1–3.9      = Low
• 4.0–6.8      = Medium
• 7.0–8.9      = High
• 9.0–10.0    = Critical

Reviewing the threat score shows that the history of using hardware or network compromise is highly likely and capability is medium, i.e., the threat score is High (=8).

By using Equation (4). It means the total risk of hardware (network) vulnerability is equal:

$$Risk=Threat Score \left(High=8\right)\times Impact \left(Critical=10\right)$$

(6)

$$\therefore Risk=80 \left(Very High\right)$$

Accordingly, risk reduction is required by recommended and implemented mitigation for this vulnerability. After mitigation, the risk will be re-calculated in an iterative cycle until it reaches the acceptance risk factor.

The re-calculation of the hardware or network compromise after implementing the system countermeasure (recommended mitigation), the vector string will be

Vector String = AV: [N]/AC: [H]/PR: [H]/UI: [R]/S: [U]/C: [L]/I: [L]/A: [L] Base Score = 3.9 (LOW)

Consequently, by reviewing the threat score after implementing the countermeasure, it shows that the history of using hardware or network compromise is highly likely and capability is low, i.e., the threat score is medium (=4). By using

Table 12. Risk Score Level.

RISK		SEVERITY
		Low >4.0	Medium 4.0–7.0	High 7.0–9.0	Critical 9.0–10
Threat Score	Very Low: 1	>4.0	4–7	7–9	9–10
	Low: 2	>8.0	8–14	14–18	18–20
	Medium: 3–6	12–24	12–42	21–54	27–60
	High: 8–9	32–36	32–63	56–81	72–90
	Very High: 12	48	48–84	84–108	108–120

Light Green: Very Low Risk; Green: Low Risk; Yellow: Medium Risk; Blue: High Risk; Purple: Critical Risk; Red: Catastrophic Risk.

, it means the total risk of hardware (network) vulnerability is equal:

$$Risk=Threat Score \left(Medium=4\right)\times Impact \left(Low=3.9\right)$$

(7)

$$\therefore Risk=16 \left(Low\right)$$

This result shows that after implementing the countermeasure, the system risk will be reduced (risk reduction) from a high-risk system to a low-risk system.

• Output 3 Risk Mitigation Strategy.

• Rapid Vulnerability Discovery and Conducting a Comprehensive Risk Assessment ICS/OT
• Apply available security updates, patches, and firmware.
• Implement zero trust, network segmentation, boundary defenses, and demilitarized zones (DMZs).
• Apply the principle of least privilege (Strengthen access controls and remove inactive accounts).
• Develop and regularly test an incident response plan [43].
• Involve all stakeholders in determining how best to modernize the legacy systems by evaluating the feasibility of modernizing or replacing them.
• Provide specialized training and awareness programs for personnel.
• Engage with industry forums, government agencies, and peer organizations to share information, best practices, and lessons learned regarding securing legacy systems in ICS/OT environments.
• Intrusion Detection Systems (IDS), Security Information and Event Management (SIEM), and Putting Managed Detection and Response (MDR) into Place are some of the new solutions that vendors are using.
• Secure remote access.
• Secure policies, procedures, and operating procedures.
• Within the organization, implement physical security and systems.

4.2. Comparison versus Another Hybrid Model

In their hybrid threat modeling, Krishnan [36] used the STRIDE technique for threat identification and categorization, the attack library for threat mitigation, and the attack tree to provide an abstract view of attacks against a specific feature or component of an application. We will apply this hybrid model to our case study in the following way:

Use the STRIDE technique for identifying and categorizing threats. Section 4.1 provides a detailed explanation of STRIDE stage 1, which includes defining security requirements, creating an application diagram, and identifying threats.

Using the proposed DFD for our case study in Figure 12, a cross indicates that the element is subject to the relevant threat represented by STRIDE, as shown in

Table 13. DFD elements to stride (S T R I D E) threats.

DFD Element Type	S	T	R	I	D	E
External Entity	X		X
Data Flow		X		X	X
Data Store		X	X	X	X
Process	X	X	X	X	X	X

. For example, external entities (such as vendors) are subject to spoofing identity and repudiation attacks.

Table 14. Mapping of the STRIDE Framework to the OWASP.

OWASP Vulnerability/ Risk Category	STRIDE Threat Category
1. Broken Authentication	Spoofing
2. Sensitive Data Exposure	Information disclosure
3. External entities	Has no direct counterpart; injection can lead most probably to the Elevation of privilege, Information disclosure, or Tampering, perhaps even to Denial of Service.
4. Broken Access Control	Elevation of privilege
5. Security Misconfiguration	Elevation of privilege; may lead to Information dissemination, Tampering, and Denial of Service
6. Using Components with Known Vulnerabilities	All STRIDE threats apply.
7. Insufficient Logging and Monitoring	Repudiation

presents a mapping of the STRIDE framework to the (OWASP) Open Web Application Security to perform the vulnerability analysis, as recommended by Krishnan.

Comparing the vulnerability analyses of the hybrid framework proposed in this paper (Figure 15) to Krishnan’s [36] hybrid model, it is evident that the proposed framework uncovers more system vulnerabilities.

To achieve this, we have mapped threat categories to actual ICS components using an attack tree. We set the goal of an attack tree to be the shutdown of an industrial control system, specifically a refinery operation (Figure 18). Comparing the attached scenarios for the STRIDE model shown in Figure 18 with those presented in this paper, it is clear that employing the hybrid model (PASTA, STRIDE, and Attack Tree) allows for more system threats and vulnerability detection. Additionally, in cases where this model does not specify it, we will use a CVSS to calculate the threat risk, providing a quantitative value that can be compared to other framework risk values.

We analyze the technical impact of previously analyzed attacks, factor the probability, and determine the risk of each threat materializing in an attack. We do this by referring to previous tables related to (event likelihood or probability of occurrence) (see Table 9), (threat capabilities) (see Table 10), and (likelihood of initiation/occurrence) (see Table 11).

By using Equations (4) and (5), the severity of one of the vulnerabilities will be calculated by assigning values to each of the base metrics and creating the base vector as follows:

Vector String = AV: [N]/AC: [L]/PR: [L]/UI: [R]/S: [C]/C: [L]/I: [L]/A: [L] Base Score = 6.5 (Medium)

Reviewing the threat score reveals that there has been a history of hardware or network compromise, indicating a medium capability and a threat score of 6. It means the total risk of hardware (network) vulnerability is equal:

$$Risk=Threat Score \left(Medium=6\right)\times Impact \left(Medium=6.5\right)$$

(8)

$$\therefore Risk=39 \left(Medium\right)$$

The result indicates a medium risk level, in contrast to the hybrid framework proposed in this paper, which provided a critical pre-mitigation score. Because multiple threat modeling techniques were applied, the proposed framework revealed more risks. Upon evaluation of the aforementioned hybrid model, the following elements are absent:

• Threat scenarios and attack trees are limited only to the STRIDE technique.
• Limited vulnerability analysis.
• Enumeration of vulnerabilities using CVE and scoring of vulnerabilities using CVSS.
• Robust risk analysis, allowing for threat prioritization based on their potential impact and likelihood with quantitative risk, impact analysis, and residual risk.

4.3. Comparison versus Applying a Single Threat Modeling Technique (PASTA)

Furthermore, to determine if the proposed hybrid framework is more successful than the single model, we conduct PASTA threat modeling exclusively alone. All PASTA stages have been applied in Section 4.1 as part of applying the proposed hybrid framework. However, in this section, we perform the risk analysis stage again. The task entails examining the technical effects of previously analyzed attacks and calculating the likelihood that each threat will materialize in an assault. Referring to event likelihood or probability of occurrence, see Table 9; for threat capabilities, see Table 10; and for the likelihood of initiation/occurrence and the likelihood of resulting in adverse impact, see Table 11.

By using Equations (4) and (5), the severity of one of the vulnerabilities will be calculated by assigning values to each of the base metrics and creating the base vector as follows:

Vector String = AV: [N]/AC: [L]/PR: [L]/UI: [R]/S: [C]/C: [L]/I: [L]/A: [H] Base Score = 8.2 (High)

By reviewing the threat score it shows that the history of using hardware or network compromise is highly likely and capability is medium, i.e., the threat score is High (=8).

It means the total risk of hardware (network) vulnerability is equal:

$$Risk=Threat Score \left(High=8\right)\times Impact (High=8.2)$$

(9)

$$Risk=66 \left(High\right)$$

The result shows that using the PASTA framework alone results in a lower risk value than using the suggested hybrid model this paper presents.

Table 15. Comparison of PASTA and Our Proposed Framework: A Performance Analysis.

ID	Attack Vector		Threat/Vulnerability Detection
	Focus	Attack Vector Analysis	Focus	Threat Identification
Hybrid model	A hybrid technique combines more precise threat categorization (Stride & tree-based analysis) with the risk-focused simulation of PASTA.	A more comprehensive and organized picture of attack vectors is provided by the hybrid approach, which makes use of PASTA simulation, integrates STRIDE (which classifies threats into S, T, R, I, D, and E), and uses Attack Trees to evaluate particular assault pathways.	The hybrid approach combines the broad risk simulation of PASTA with the detailed threat identification of STRIDE and the structured analysis of Attack Trees.	Risks are categorized into several classes through the use of STRIDE and PASTA simulation, which aids in methodically discovering a greater number of possible risks. Attack Trees can produce a more comprehensive list of threats by further breaking down threats into sub-threats and particular attack paths.
PASTA framework	PASTA is a risk-centric methodology that emphasizes understanding the attack vectors by simulating potential attacks and analyzing the paths an attacker might take.	In PASTA, attack vectors are derived from a detailed simulation of how threats could exploit vulnerabilities.	PASTA is primarily concerned with identifying dangers through scenarios and simulations. The variety of attack scenarios that are modeled and the risk analysis that is done frequently limit the number of threats that are found.	The degree to which situations are simulated can affect how many risks are present in PASTA. While it offers a wide perspective, it might not be able to identify every potential specific hazard as clearly as other approaches.
Detailed Explanation	Attack Trees provide a more thorough understanding of potential attack vectors by outlining specific attack scenarios and paths. PASTA & STRIDE aid in the systematic identification of threat types, while the hybrid method enables a deep breakdown of attack vectors.		Because Attack Trees’ thorough route analysis and PASTA, STRIDE’s classification helps identify more threats by dissecting them into finer components and taking a larger variety of attack alternatives into consideration. The hybrid technique frequently yields a higher number of threats found.
Summary	With an emphasis on simulated scenarios and comprehensive risk analysis, PASTA offers a comprehensive and risk-centric perspective of attack vectors and threats. • The Hybrid Approach (PASTA + STRIDE + Attack Trees) combines the risk simulation of PASTA with the threat classification of STRIDE and the path analysis of Attack Trees to provide a more thorough and organized study that may uncover additional threats. The hybrid approach generally results in a more detailed understanding of attack vectors and a potentially larger number of identified threats due to its in-depth structured analysis.

presents a detailed comparison between PASTA and the proposed Hybrid framework.

5. Discussion

The primary objective of this research is to present a comprehensive and detailed novel framework utilizing a combination of threat modeling methodologies such as PASTA, STRIDE, and attack trees. This study focuses on assisting organizations with legacy industrial control systems (ICS) to initiate a re-evolution and assessment of their systems. The study examines a gas production (onshore facilities) industrial control system (ICS). The Common Vulnerability Scoring System (CVSS), a vulnerability scoring system designed to provide a standardized method for system rating vulnerabilities, is used as the basis for metric definition and calculations. The model proposes calculating the CVSS once before applying the threat mitigation and then recomputing the security metric to verify the effectiveness of the applied mitigations.

Before threat mitigation, the total risk of hardware (network) vulnerability was equal to 80; after mitigation, it dropped to 16. Consequently, the decrease indicates that the mitigations were effective. Furthermore, we experimentally compared the proposed framework with two other approaches: the first, which exclusively applies the PASTA framework, and the second, which incorporates hybrid threat modeling as presented by Krishnan [36].

Table 16. Comparison of PASTA, Hybrid Framework [36] and the Proposed Framework: Advances and Drawbacks.

Threat Modeling Technique	Criteria
	Methods Utilized	Advantages	Drawbacks
PASTA Alone	PASTA	(1) Systematic approach to threat modeling (2) Focus on identifying potential threats	(1) May not capture all potential threats (Shows high risk value comparing with our proposed framework, which shows critical risk value, as threats associated with STRIDE not considered) (2) Limited ability to prioritize threats
Hybrid Framework proposed by [36]	STRIDE, Attack Trees	(1) Comprehensive threat modeling by combining STRIDE and Attack Trees (2) Improved threat identification and prioritization (3) Better visualization of potential attack paths	(1) May not capture all potential threats (2) Limited ability to prioritize threats (3) May not provide quantitative risk assessment (4) The STRIDE technique does not aid in developing countermeasures
Proposed Framework	PASTA, STRIDE, Attack Trees, CVSS	(1) Comprehensive threat modeling by combining multiple methods Offering three distinct perspectives: system-centric, attacker-centric, and risk-centric, highlighting the advantages of each perspective. (2) Enhanced risk assessment and mitigation planning by incorporating a component (CVSS) for a quantitative assessment of the security level (3) Improved threat identification by integrating MITRE to provide descriptions for known software and system vulnerabilities that enable one to quickly look for any possible vulnerabilities in the components and libraries they use, saving time and avoiding missing any obvious flaws. (4) Outperforms other models in terms of the number of vulnerabilities and risk score (5) Produces Comprehensive documentation output.	(1) Increased complexity and time-consuming due to combining multiple methods. (2) Requires expertise in multiple threat modeling methodologies

presents a detailed comparison of the three approaches. All the results show that, in terms of threat and vulnerability identification, risk value, and risk reduction as well as documentation, the suggested hybrid framework identifies more risks.

6. Conclusions and Future Work

This paper presents a hybrid framework that combines system-centric, attacker-centric, and risk-centric threat modeling techniques: STRIDE, attack tree, & PASTA. Alongside those comprehensive threat modeling techniques, we combine CVSS for quantitative Risk Assessment. We proposed a novel threat modeling framework by combining all the above-mentioned approaches. A case study involving oil and gas to further demonstrate the usefulness of the suggested framework was employed. This paper offers the following contributions:

• Threat Modeling from a Multi-faceted Approach: The proposed hybrid model allows for a multi-dimensional view of threat modeling, integrating system-centric, attacker-centric, and risk-centric approaches. This allows for a more complete understanding of threats and vulnerabilities.
• Quantitative Security Assessment: In terms of its design, the model has a section that determines the quantitative security level of systems found within it. This quantification helps to make informed decisions about risk mitigation plans.
• Feedback Loop for Iterative Risk Assessment and Mitigation: We propose a mechanism that continuously evaluates security levels using CVSS scores. With this stepwise process, it becomes possible to measure how successful any given mitigation has been, thereby providing a deeper view of the overall level of safety associated with a given system.
• Enhanced Threat Intelligence by MITRE Integration: To enhance threat intelligence and increase accuracy of threat identification using MITRE ATT&CK framework, the hybrid model is employed. Thus, it provides a better-informed, actionable understanding of potential risks since it maps the identified threats to known attack tactics, techniques, and common knowledge (TTPs).
• Better Performance: An empirical evaluation of the hybrid model shows that it performs significantly better than stand-alone models like PASTA and other hybrid models cited in the literature. We attribute this performance to the synergies that arise from combining techniques in the proposed hybrid framework.

The identification of threats in the context of remote operational technology (OT) applications, such as unmanned offshore oil field facilities managed remotely from an onshore base or another offshore platform, is one aspect that this research (in the oil and gas domain) may consider for future development. Unfortunately, remote control applications that utilize wireless digital communications systems introduce new security risks. Additionally, the integration of IT and OT will significantly increase the potential for new vulnerabilities in systems that this study did not identify.