# Legacy ICS Cybersecurity Assessment Using Hybrid Threat Modeling--An Oil and Gas Sector Case Study
## 3 The Proposed Hybrid Threat Model
** 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. Figure 4: Proposed Hybrid Threat Modeling Framework. 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. Figure 5: Inputs, Process, and Outputs of Stage I.  
Figure 6: Inputs, Process, and Outputs of Stage II. 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.