Threat modeling is an information security practice aimed at identifying and assessing threats and potential attack vectors during the design phase of a system. This makes it possible to address identified threats at an early stage and in an appropriate manner. It is particularly relevant for risk management, as the risk assessment derived from the threat model provides a solid basis for making informed decisions regarding risk acceptance or mitigation.
In addition, both the European Cyber Resilience Act (CRA) and the IEC 62443 series of standards require manufacturers to perform a cybersecurity risk assessment or threat modeling for products, whether software or hardware. During threat modeling, the components of a product, the data flows between those components, and external influences are assessed with regard to potential risks. Performing this step early in the product development lifecycle enables design decisions to be based on the findings and allows identified threats to be mitigated—wherever possible—through secure-by-design principles.
Furthermore, as products become increasingly interconnected, it is becoming more important to include the customer’s operational environment in the threat modeling process to enable an integrated risk assessment. Evaluating only the risks of the product in isolation is no longer sufficient. After all, a single insecure component within the operational environment may be enough to compromise the customer’s entire network.
Threat modeling is typically based on a model of the system under analysis. This model includes interfaces, components, and the data flows between these elements, as well as trust boundaries, which represent transitions between zones with different trust levels (for example, from the Internet (untrusted) to the intranet (more trusted)). In information technology, data flow diagrams have become one of the most widely established foundations for threat modeling.
But what does this look like in the context of secure product development?
The complexity of these systems—which combine Information Technology (IT) and Operational Technology (OT)—requires both domains to be modeled and analyzed together in order to accurately assess cyber risks.
In this first article of our OT threat modeling series, we focus on modeling these complex systems. The second article will cover how to perform threat modeling and risk assessment based on these models.
Here, we would like to introduce the CERTAINITY modeling approach and the underlying metamodel. A metamodel defines the modeling elements used within a modeling methodology and describes the relationships between them. It therefore forms the foundation of the entire modeling approach.
System Modeling
The presented modeling approach is based on a methodology with three levels of abstraction, enabling comprehensive threat modeling and risk assessment. One key advantage is that the highest level of abstraction produces management-oriented models that provide an appropriate basis for making strategic decisions regarding cyber risk treatment.
The modeling approach is built upon the metamodel (Figure 1) and becomes increasingly detailed across the different abstraction levels.
Figure 1: Metamodel for Threat Modeling
The metamodel consists of ten modeling elements required to perform a comprehensive threat modeling assessment of a product or system. The manufacturing process produces both products and their individual components. Components—as well as complete products and systems—also require software, such as firmware. Consequently, the manufacturing process depends on a development process responsible for producing that software.
As illustrated in Figure 1, a component may itself consist of multiple subcomponents, such as third-party chips. In addition, a component may depend on other components within the product.
A product consists of multiple components, while a system consists of multiple products.
In addition, software, products, components, systems, and technology assets are connected to interfaces via input/output relationships that enable data flows between the individual elements. These interfaces, in turn, use data objects that are stored within technology assets such as databases. Finally, technology assets, systems, and products form part of the customer’s operational environment. As in the example above, a technology asset such as a database may also be hosted in the cloud.
The different levels of abstraction based on the metamodel shown in Figure 1 are described in the following sections. The actual modeling process will be illustrated using a practical example in the next article of this series. This article focuses on describing the metamodel that serves as the foundation for the modeling approach.
The first and highest level of abstraction is the system level, which illustrates high-level dependencies. At this stage, it is important to model dependencies all the way down to the relevant processes. This makes it easier to determine in which manufacturing or development process identified threats can best be mitigated and enables the hardening of those specific processes. Furthermore, lessons learned during product development can be used to improve these processes over time. The threats identified at the most detailed abstraction level can be mapped to the model elements highlighted in green in Figure 2, providing a high-level overview of the overall threat landscape. By including the operational environment, the intended use of the product within the customer’s environment is clearly defined from the outset.
Figure 2: Relevant Model Elements for the System Level
The second level is the component level, which represents the dependencies between the individual components of a system. This level provides a more detailed view of the product or system architecture. Positioned one level below the system level, it offers a comprehensive overview of the integrated components. Due to its increased technical detail, this level is intended primarily for technical personnel who require a deeper understanding of component dependencies in order to better identify and assess potential threats. This level also includes trust boundaries, which represent transitions between security zones and the corresponding changes in trust levels between components. It contains all relevant information about the product or system, except for the data flows and interfaces between components or products, which are modeled at the most detailed abstraction level.
Figure 3: Relevant Model Elements for the Component Level
The final level is the information level, which models the data flows between individual components or products as well as technical details such as the communication protocols being used. This level forms the core of the threat modeling process. It provides the highest level of detail, capturing all relevant technical aspects of the system. Once this modeling phase has been completed, all product-relevant details should be documented, enabling a comprehensive threat modeling assessment.
Figure 4: Relevant Model Elements for the Information Level
Figure 4: Relevant Model Elements for the Information Level
The next section briefly introduces the threat modeling process itself, which will be the main focus of the next article in this blog series.
Threat Modeling
Once the models have been created using the methodology described above, the actual threat modeling and risk assessment can begin. Since all interfaces, trust boundaries, communication protocols, and other relevant elements are already known, the next step is to evaluate where threats may exist within the design. This can be accomplished using the STRIDE methodology in combination with the MITRE ATT&CK Matrix for ICS.
STRIDE is an acronym for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. These threat categories are used to assess whether each individual model element is susceptible to a particular type of threat. The MITRE ATT&CK Matrix for ICS complements this approach by incorporating attack techniques and patterns observed in sophisticated threat actor groups, allowing them to be considered during the threat modeling process.
The identified potential threats are then evaluated according to their criticality and classified using a scoring system such as the Common Vulnerability Scoring System (CVSS). Based on the results, security requirements are defined, and a secure design is developed to implement those requirements.
By addressing potential threats already during the design phase, a secure-by-design approach can mitigate many risks before implementation even begins. This forms the foundation of a secure product development lifecycle.
A more detailed explanation of the threat modeling methodology—including risk assessment and potential tool support—will be covered in the next article of this blog series.
CERTAINITY is happy to support you in modeling your Industry 4.0, OT, and IT environments. Get in touch with us.