Architecture-based attack propagation and variation analysis for identifying confidentiality issues in Industry 4.0

1 Introduction

Industry 4.0 is the digitalization of the production process. It promises, for instance, more efficient usage of resources and more customization for products. These benefits are achieved by connecting different systems and enabling data-exchange for them. The used technologies are Cyber-Physical-Systems (CPS) and Internet of Things (IoT) devices. However, with the connected systems also the questions regarding the security and confidentiality arise. It is vital that systems only share selected data and keep the other data secure and confidential. Additionally, these systems are also often critical and cannot be offline or blocked. For instance, a stopped assembly line is costly. Still, there could be incidents happening like accidents or system break-downs. Some of these incidents can be foreseen. Thus, they are already considered during the system’s design. However, some situations are not foreseeable or just forgotten through mistakes and therefore unknown to the system. These unknown situations lead the system to an unknown state, and there is uncertainty regarding the access decision. To support the system’s decision-making in this state, it can be important that the runtime system gets information about the impact of its decision.

We now introduce our Industry 4.0 running example. We could have a system like in Figure 1. It is based on a scenario from our former Industry 4.0 security research project with industrial partners [1]. We extended it in [2] for attacker information. The scenarios consist of two companies with one manufacturer (M) and one service contractor (S). S maintains the machine of M. For maintaining the machine, S needs access to the log data of the machine. However, access should only be granted when the machine has a failure since the log data might contain sensitive data. The system architecture contains three devices (Storage Server, Terminal Server, Machine Controller) that are connected by a Local Network. Additionally, it contains four components (a) the Production Data Storage which stores production data such as the log data of the machine, (b) the Product Storage which contains confidential blueprints, (c) the Terminal with the interface for the technician, (d) the Machine generates the log data and provides a state.

Figure 1:

Graphical and architectural representation of the maintenance scenario from Walter, Heinrich, and Reussner [2].

Analyzing this system during the design-time is beneficial, since there are often security problems already in the design of the software [3] or it has already known vulnerabilities [4]. Design-time analyses such as our attack propagation [2] can find potential attack paths based on the proposed software architecture by using these known vulnerabilities or can identify critical data elements such as our dataflow analysis [5, 6]. However, the results of these analyses are rarely used during the runtime. Additionally, because of their nature as design-time analyses, there is uncertainty regarding the actual runtime properties. For instance, we do not know the initial breaching points or the concrete attack capabilities for our attack propagation. These uncertain properties directly affect the results and reduce the usefulness of the design-time analysis results during runtime.

To increase the usefulness and bridge the gap between design-time and runtime analyses, we looked primarily at runtime access control systems and developed an approach to provide design-time properties such as attack paths or classifications based on static design-time analysis. Our contributions are:

(i) We use a newly developed uncertainty model to calculate attack paths for different initial breach locations and attacker capabilities. These attack paths are used to identify potentially affected data. Additionally, we use our dataflow analysis [5, 6] to categorize this found data based on their criticality. (ii) These properties can then support the access decision during runtime by providing the impact for access decisions.

We evaluated our modified design-time analyses, including the transformation and our uncertainty metamodel for functional correctness. We used four case studies based on real-world system breaches, research case studies, and industrial example scenarios. The results suggest that our analyses produce correct results. Additionally, we investigated the applicability of our design-time properties. For this, we gave access control experts our design-time properties, and they developed access control rules which can consider these design-time properties.

Our paper is structured as follows. We give in Section 2 an overview of our approach. In Section 3 we present our variation metamodel in more detail. We describe in Section 4 our evaluation. Afterwards, we present in Section 5 the related work and Section 6 concludes the paper.

2 Approach overview

Our main idea is to use static design-time analyses results to enhance the decision-making process for runtime access control approaches. This allows considering the impact of enabling potential attack paths to critical data during uncertain access control decisions. In this paper, we focus on the creation of the design-time properties and illustrate how these properties can be used during runtime.

Figure 2 gives an overview of our approach. It consists of the design-time part and the runtime part. The syntax is based on activity diagrams to describe the process. Rectangles with rounded corners describe activities, and regular rectangles describe input or output objects. Our design-time analyses are based on the Palladio Component Model (PCM) [7]. We use an extended version, which supports dataflow definitions [6] and vulnerability specifications [2]. The first part of our approach is the modeling of the software architecture. Here, architects can specify the criticality of the data and define vulnerable system elements such as components or hardware resources. Afterward, our dataflow analysis [6] calculates for each data element the criticality and saves it with a unique ID for later references. During the design-time, it is not clear which components can be attacked or what capabilities attackers have. Therefore, we generate multiple architectural variations for different attack start points and with different attacker capabilities. Architects can define variation points by using our newly developed uncertainty variation metamodel (see Section 3). These variation points are then automatically transformed into different architectural variations. Each architectural variation is then analyzed by our attacker propagation analysis [2], which is based on [8]. We extended the analysis, so it can output the attack complexity of an attack path. For each variation, we store the attack complexity, the starting point, and the affected data for the runtime part. Additionally, architects can define runtime access control policies.

Figure 2:

Process overview as an activity diagram with different actions and artifacts during design-time and runtime.

These properties alone can already help architects to increase security. The data classification determines the critical data. Based on our data model, architects can use this information to determine components with critical data. This can then be used to harden these components against attacks. Using our variation model, we can calculate an attack path from every component. Architects and security experts can determine which component is critical and can easily be attacked with the attack paths. Based on these results, they can decide which components need special protection mechanisms or mitigation approaches. This can help already during the design-time to increase the security and confidentiality of the system.

Additionally, our design-time properties, namely data criticality and attack paths with affected data, can then be considered during runtime. However, this consideration is only possible if there is no architectural erosion between the modeled architecture and the runtime system. For this, we differ between architecture evolution and change in runtime properties. If structural information of the architecture is changed, such as the selection of components or hardware resources, we consider these as an evolution step. For this kind of step, the architect needs to adapt the architectural model and rerun our analysis. In other cases, for instance, that the access request is changed to another component, the architect does not need to update the architectural model. Our uncertainty variation model could also consider some structural changes in the software architecture, such as the known reconfiguration step. However, the runtime access control system would then need to know the complete system state and need to choose the appropriate attack path.

At the runtime, the evaluation of the access control policies could, for instance, consider the access request, the system state, and especially the results of the design-time analysis. This would lead then to an access decision. Notably, the stored list of the criticality and the information about the attack paths are considered to decide whether access can be granted or whether granting access would enable an attacker to access critical data.

3 Enabling security analysis at design-time

Our existing analyses do not consider uncertainty, yet. However, at design-time, much is yet unknown about the system. This includes the system usage and misuse, i.e., information about the attacker and the attacker’s behavior. The lack of knowledge introduces uncertainty, e.g., about the starting point of the attack, possible attack paths, and also the system’s environment. Although this uncertainty impedes deterministic statements about the overall confidentiality of a system, it is not unmanageable at all. By modeling them as variations of the software architecture, we can make more precise statements about the impact on confidentiality [9].

The concept of analyzing different versions of an architectural model and measuring the impact on quality attributes including for confidentiality has already been introduced by a PerOpteryx extension [10]. However, PerOpteryx so far does not consider attacker propagation and the data classification. Thus, we present an uncertainty variation metamodel to analyze software architecture variations due to uncertainty for attack propagation analyses.

Figure 3 shows the UML class diagram of the Uncertainty Variation Metamodel. It represents Scenario Uncertainty as Uncertainty Variations, i.e., variations in architectural models due to uncertainty as set of zero or more Variation Points. Each Variation Point has a name and provides its type by the State Handler that can be used to calculate architecture variants. The Variation Points also references all elements of the architectural model that are affected by the modeled variation, i.e., varying subjects. To describe all alternatives to choose from as part of the variation, the model defines the Variation Description. This description holds one or multiple alternative values or collections of values that a Variation Point can represent. Examples are different resources to deploy to or different sets of characteristics describing the sensitivity of data. All values, value collections as well as varying subjects are identifiers that reference elements of the model.

Figure 3:

Uncertainty variation metamodel class diagram.

To generate the variations, we first compute the state space of all possible combinations. Given n Variation Points v ₀ … v _n that have all a Variation Description, let |v _i | the number of values of the Variation Description i. Then, the size of the state space s can be calculated as s = ∏ i = 0 n | v i | , i.e., by multiplying the count of all Variation Description’s values. We iterate over this state space and apply the variation to the software architecture. In each iteration, we call the state handlers to modify the referenced varying subjects of the software architecture. Depending on the type of the Variation Point, this means changing references and model elements. Because of our limited scope on our attack propagation, where we only vary the starting point, the creation of all variants should not be problematic. For other scenarios, we plan to further investigate it. Each variation represents one possible runtime scenario and can be analyzed using the attacker analysis.

For our running example, we want to create for each component as a starting point an attack path. We created a new Variation Point and added as the Variation Description the attacker. Afterward, the analysis would create for each component an attacker model. Therefore, we could analyze potential attack paths from each component.

4 Evaluation

We structure the evaluation based on the Goal Question Metric approach. Our first goal (G1) is to evaluate the functional correctness for the properties derived from the design-time. Our evaluation questions are: Q1.1: Can we correctly classify the criticality of the data? Q1.2. Can we correctly determine the affected data of the attack paths? Q1.3 Can we correctly identify the complexity of the attack paths? Q1.4 Can we correctly generate all variations? In contrast to our previous publication [6], we focus in Q1.1 not on access violations but on the classification of data elements. Determining the data criticality is essential since a wrong classification might later result in a wrong access decision during runtime. For Q1.2, we focus only on the data elements within an attack path since the attack path itself is already evaluated in [2]. Q1.3 focuses on the new attack complexity element. Therefore, evaluating whether it is calculated correctly is essential. The same applies to Q1.4. This describes our newly developed variation model. Our metric for answering Q1.1–Q1.4 is the Jaccard Coefficient (JC) [11]: J C ( A , B ) = A ∩ B A ∪ B . It is used to compare the similarity between two sets, and its values range from 0.0 for no intersection in the sets and 1.0 if both sets are identical. We can apply this metrics, since the order of the sets are irrelevant. A detailed description of the sets can be found in the Evaluation Design. Our second goal (G2) concentrates on the applicability for the runtime. The evaluation question is Q2.1: Can access control policies be formulated that consider our design-time properties (data criticality and attack paths with affected data)? This question is important, since so far we only evaluated what scenario we can model and how correct the results of the analyses are. However, if our design-time properties cannot be considered during the runtime, we would only have the design-time benefits for the analyses. Therefore, it is important to investigate, whether an access control framework can theoretically consider our properties. Our metric for answering Q2.1 is the ratio (a) between the scenario (s ₁), which can consider our properties and all scenarios s _all : a = s 1 s all .

5 Related work

We split the discussion about related work along our different analyses. In [6], we discuss already related approaches for the dataflow analysis. Other related model-driven approaches can be found in [18]. Overall, these related approaches often do not analyze the dataflow at the architectural level. We discuss related approaches regarding our attack propagation in [2]. Kordy et al. [19] also lists different approaches. Most of the related approaches do not consider fine-grained access control and vulnerabilities. They focus only one aspect, or a very specialized for one application domain. Regarding the variation modeling, there exists the Peropteryx extension for confidentiality [10], which generates architectural variations and analyzes them. Also in the domain of product lines, they use the concepts of variants [20]. In contrast, our model is more specialized, since it only should cover uncertainty for confidentiality analyses.

6 Conclusions

In the paper, we presented an approach that analyzes what data is affected by system breaches based on the software architecture in Industry 4.0. This is achieved by assigning data a category for criticality based on our dataflow analysis and metamodel. The approach considers the uncertainty regarding the attack capabilities and initial breach point during the design-time with our uncertainty variation model. This information can be used during the runtime to enhance the decision-making of access control approaches. We evaluated our approach on four case studies, and the evaluation indicates correct results. Additionally, we illustrated that our design-time properties can be used in access control rules.

Using our approach is beneficial to identify potential problematic breach locations during the design-time. This can help architects and system designers to harden their systems and fix security/confidentiality problems in the design. Additionally, our approach can be used to document known security problems in the system, and this eases the communication between different stakeholders. During the runtime, our generated properties can provide the access control system with information regarding the impact of access decisions.

In the future, we want to investigate more case studies and evaluate the benefit of integrating the design properties in the access control system. For this, we will look at different case studies and example models. Regarding the design-time analyses, we want to integrate approaches, which can automatically update the vulnerabilities and the system architecture. This would increase the accuracy of our impact descriptions for the runtime access control system.