Threat Modeling Methods for Manufacturing Companies (Part 1) - Do you know your assets?

Threat modeling is a practice in information security that involves identifying and evaluating threats and possible attack vectors during the design phase. This makes it possible to address the identified threats appropriately and at an early stage. This is particularly relevant for risk management, as decisions regarding risk acceptance or mitigation can be made on the basis of the risk assessment from the threat model.

In addition, the European Cyber Resilience Act and the IEC 62443 series of standards stipulate that a cybersecurity risk assessment or threat modeling must be carried out for products, software and hardware. In the course of threat modeling, the components of a product, the data flows between these components and external influences are evaluated with regard to potential risks. By carrying out this project step early on in the product development life cycle, it is possible to make design decisions based on the results and to mitigate the identified threats as far as possible with the help of a secure design.

In addition, due to the increased networking of products, it is becoming increasingly important to incorporate the customer’s operating environment into the threat modeling so that an integrated risk assessment is possible. An isolated consideration of the risks of the product is therefore now too little. Among other things, this is the case because just one insecure component in the operating environment can be enough to compromise the customer’s network.

Threat modeling is usually based on a model of the system to be analyzed. This model includes interfaces, components and the data flows between these elements, as well as trust boundaries, which represent a zone change and an associated change in the level of trust (e.g. from the Internet (untrusted) to the intranet (more trusted). In information technology, data flow diagrams have established themselves as the basis for threat modeling.

But what about the environment of secure product development?

The complexity of these systems, which are a mixture of IT and operational technology (OT), requires the consideration and modeling of both worlds in order to enable a correct assessment of the risk.

In this first blog post of our series on OT threat modeling, we will discuss the modeling of complex systems. In the second blog post, we will present the implementation of threat modeling and risk assessment based on these models.

Here we would like to present details of the CERTAINITY modeling technique and the underlying metamodel. A metamodel describes the model elements used in a modeling technique and explains their interrelationships. It therefore forms the basis of the modeling.

Modeling the systems

The modeling approach presented is based on a methodology with three levels of abstraction, which supports the comprehensive modeling and assessment of threats and risks. This has the advantage that the modeling approach at the highest level of abstraction produces models suitable for management, which form a suitable basis for the decisions required to deal with cyber risks.

The modeling approach is based on the metamodel (Figure 1) and becomes more and more detailed over the levels of abstraction.

The metamodel contains 10 model elements that are required to perform detailed threat modeling of a manufactured product or system. The production process is used to produce the products and their components. Software, such as firmware, is also required for components, products or systems. The production process therefore also requires a development process, which is carried out to produce the software. As can be seen in Figure 1, a component can consist of several components, such as chips from third-party suppliers. A component can also be dependent on other components in the product.

A product consists of several components and a system consists of several products. In addition, the software, the product, the component, the system and the technology assets have an input/output connection to an interface that enables the flow of data between the individual elements. The interface itself uses data objects that are stored in a technology asset, such as a database. Finally, the technology assets, the system or the product are part of the customer’s operating environment. The technology asset, as in the example above, a database, can also be located in the cloud.

The various levels of abstraction, which are based on the metamodel in Figure 1, are described in the following paragraphs. The modeling will be illustrated in the next blog post using an example. This blog post describes the metamodel used as the basis for the modeling.

The first and highest level of abstraction is the system level, which shows high-level dependencies. Here it is important that the modeling of dependencies takes place up to the respective process. This enables a better assessment of the production or development process in which the identified threats can be mitigated and allows the specific processes to be hardened. In addition, lessons learned identified during product development can be used to optimize these processes. The threats identified at the most detailed level of abstraction can be assigned at this level to the model elements marked in green in Figure 2, creating a high-level overview of the threats. By including the operating environment, the intended use of the product by the customer is clearly defined.

The second level is the component level, which represents the dependencies between the individual components of the system. This level provides a detailed insight into the structure of the product or system. This representation is one level below the system level and provides a detailed overview of the integrated components. Due to the increased level of technical detail, this level is intended for technical personnel who need a deeper insight into the dependencies in order to better identify and assess potential threats. Trust boundaries are also considered here, which represent a zone change and an associated change in the level of trust between the individual components. This level contains all information about the product or system, except for the data flows and interfaces between the components or products, which are modeled at the highest level of detail.

The last level is the information level, which also maps the data flows between the individual components or products, as well as the technical details, such as the communication protocols used. This level represents the core of threat modeling. This is where the most detailed modeling takes place and all relevant technical details are mapped. Once this modeling has been completed, all product-relevant details should be modeled, enabling comprehensive threat modeling.

The next section briefly discusses threat modeling, which is the content for the next blog post.

Threat modeling

Based on the models that have been modeled using the methodology described above, the actual threat modeling and risk assessment can then begin. Since all interfaces, trust boundaries, communication protocols, etc. are known, the next step is to evaluate where exactly threats could exist in the design. This can be done using the STRIDE method and the MITRE ATT&CK Matrix for ICS, for example. STRIDE is an acronym for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Access and Elevation of Privilege. These threat categories can be used to evaluate for each model element whether the specific element is affected. The MITRE ATT&CK Matrix for ICS can help to incorporate specific attack patterns of larger attacker groups into the threat modeling. The potential threats identified are then evaluated in terms of 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 created that implements the defined requirements. The secure design can mitigate the identified potential threats as early as the design phase and therefore forms the basis for a secure product development lifecycle. You can read a detailed description of threat modeling in the next blog post, which takes a closer look at the methodology of threat modeling, risk assessment and possible tool support.

CERTAINITY will be happy to help you model your Industry 4.0 or OT and IT landscape. Contact us