Open AccessArticle

Threat Modeling of Smart Grid Control Architectures

Lars Halvdan Flå

Jonatan Ralf Axel Klemets

and

Martin Gilje Jaatun

^1,*

SINTEF Digital, 7465 Trondheim, Norway

SINTEF Energy Research, 7465 Trondheim, Norway

Author to whom correspondence should be addressed.

Electronics 2025, 14(6), 1068; https://doi.org/10.3390/electronics14061068

Submission received: 21 December 2024 / Revised: 22 February 2025 / Accepted: 5 March 2025 / Published: 7 March 2025

(This article belongs to the Special Issue Stability Analysis and Control of Smart Grids)

Download

Browse Figures

Versions Notes

Abstract

In this paper, we perform a threat modeling of architectures for controlling the medium voltage (MV) part of the power grid, arguing the importance of this topic with a brief summary of serious cyber security attacks from the last decade. As more Distributed Energy Resources (DERs) are introduced into this part of the grid, the need to control these resources arises. A threat modeling of two alternative control architectures is performed to study two different aspects. Firstly, we study and compare the cyber security of the two architectures to determine whether one of them is inherently more secure than the other. While both architectures rely on 5G, one of the architectures uses a centralized design, while the other uses a distributed design. Our results indicate that at the current level of detail, contrary to common belief, it is difficult to draw definitive conclusions as to which architecture is more secure. The second aspect we study is the applied threat modeling method itself. We evaluate and test the method and suggest improvements.

Keywords:

threat modeling; smart grid; cybersecurity; operational technology; OT; 5G

1. Introduction

The power grid traditionally consisted of large production plants from which the electric power was dispersed to the end users. However, the integration of variable renewable energy sources (VRES) is shifting the power grid towards more distributed energy production. The intermittent nature of VRES will often not coincide with the power and energy demand, which causes problems for the power system. Smart control and communication systems are needed to fully utilize VRES and other flexible loads from the end users. As a result, there will be a need to coordinate different systems and devices, many of which are not owned by the utility, and thus, have their own objectives, controllable variables, and data security concerns. These systems require more complex control and communication architectures, which may be more vulnerable to cyberattacks. Based on the communication structure, the two main types of control system architectures can, according to [1], be categorized as centralized control and distributed control. Both architectures are able to provide comparable control performances [2,3], but their vulnerability to different cyber threats remains largely unexplored. Control structures within the smart grid increasingly rely on wireless communication, which, in most cases, means using 5G mobile networks. We touch briefly on this in the sections below.

The recent decade has revealed a desire from threat actors to attack the electricity grid [4,5,6], most notably illustrated by the cyberattacks against Ukrainian power grids. The first attack, in 2015, caused a blackout affecting 225,000 people [7]. A second attack in 2016 caused a blackout affecting a single substation, but later revealed a failed attempt to disable protective relays installed in the grid [8]. In 2022, it was discovered that a new variant of the malware used in the 2016 attack had been used to target high-voltage substations in Ukraine [9,10]. In a recent report from the OT cybersecurity company Dragos [11], they identify 18 active threat groups that have been or are currently targeting the electric power industry, and state that Distributed Energy Resources are an “increasingly viable […] attack vector”. Although they do not identify any recent successful attacks, they maintain that ransomware attacks against the sector are on the rise, and as was seen in the case of Maersk [12], malware that appears to be ransomware can cause damage as devastating as an active, online attacker.

Adding to these attacks against the power grid are numerous attacks against industrial control systems more broadly [13,14], clearly showing a need to include cybersecurity in the design phase of an industrial control system (ICS), both in the smart grid and in other domains. This paper investigates how threat modeling can be used to assess and compare the cybersecurity of different designs at an early phase of the development, and how threat modeling can aid in the future steps of the development of control architectures in the smart grid. Specifically, in this paper, we make the following contributions:

Perform a threat modeling of two alternative architectures (centralized and distributed) for control of the smart grid, with the goal of determining which of the two architectures is more secure with regard to cyber threats.
Evaluate the performance of the applied threat modeling method described in our earlier work [15] and suggest improvements.

The remainder of this paper is structured as follows: Section 2 provides a background of threat modeling and 5G. Section 3 describes the selected threat modeling method. Section 4 describes the selected smart grid control use case, and Section 5 presents the results of the threat modeling. Section 6 discusses the results, and Section 7 concludes the paper and outlines further work.

2. Background

In this section, we provide background information on smart grid and ICS threat modeling and 5G.

2.1. Smart Grid and ICS Threat Modeling

The shift towards a smarter power grid, commonly known as a smart grid, requires advanced monitoring and control by distribution system operators (DSOs), along with more complex coordination between producers and consumers [16,17]. Enhanced monitoring involves the better utilization of existing smart meters [18,19] and the installation of new devices that can provide more accurate information about voltage and power flows in the grid [20]. Measurements can also serve multiple purposes; for example, temperature, wind speed, and solar radiation can be used for both dynamic line rating [21], and predicting load demand and energy production [22]. Optimal sensor selection and placement will be important to improve robustness and reduce the investment cost of new sensors [20,23].

State estimation algorithms can be used to combine measurements with grid models to further improve grid-monitoring capabilities [19,24].

Accurate estimates of the grid condition will enable DSOs to optimize grid performance by controlling tap changers, inverters, and switches in the grid [3], and by coordinating with end users [25]. However, current communication technologies for smart grid monitoring and control are often limited or sometimes non-existent [26]. Therefore, designing effective communication strategies and architectures is vital to ensure satisfactory control performance, scalability, and robustness to cyber-attacks [1]. A survey of methods for detecting and locating cyber-attacks was conducted in [27]. However, methodologies to analyze, identify, and mitigate potential cybersecurity threats are still needed.

This work builds on the method for the threat modeling of industrial control systems proposed by Flå and Jaatun [15]. In this paper, we apply the method to two potential future medium-voltage (MV) control architectures and evaluate the results. Whereas threat modeling as a term has a long history within software security [28,29] it has also been adapted to the ICS domain, as shown by the systematic literature review (SLR) performed by Khalil et al. [30]. They identify a total of 36 threat modeling papers, published between 2012 and 2023, which they proceed to classify into several categories. With regard to what activities the different methods include, all of them perform system mapping and threat enumeration, and most of them perform impact analyses and risk mitigation, while only very few include the identification of security objectives and validation. We furthermore note that, for system mapping and threat enumeration, many of the papers (14 of the 36 papers) utilize STRIDE and Data Flow Diagrams (DFDs), likely influenced by the fact that this is also a popular approach in software security. However, while the authors claim that STRIDE is the most mature method, they also note that there is no unified method for documenting the threats. Furthermore, they also note that most of the threat modeling methods included in the SLR need further validation and testing, and that “[…] this study shows a need for creating mature and easy-to-adapt ICSs TM methods […]”. The method that we apply in this current paper is a contribution towards this.

Works that use alternatives to STRIDE include those of Ling and Ekstedt [31,32], Hawrylak et al. [33], Suleiman et al. [34] and Omerovic et al. [35]. These are discussed further by Holik et al. [36].

As the last round of literature searches were completed in 2023, more recent contributions are not included in the review by Khalil et al [30]. Furthermore, as the search strings included such strings as “smart grid”, “power grid” and and similar phrases, some papers may have evaded review. The same may be the case for papers that identify threats but do not describe the threat modeling method, as the latter was one of the exclusion criteria for the SLR. In the following, we present a few papers which are not covered in the review by Khalil et al. [30]. Holik et al. [36] leverage a threat modeling template in the Microsoft Threat Modeling tool to identify threats to a smart grid secondary substation, and proceed to analyze a subset of the threats through emulation. Regarding the threat modeling approach, the authors argue the need to create two DFD models, one which focuses on the network and one which focuses on the flow of data between processes.

Rahim et al. [37] perform a threat modeling of a Photovoltaic use case, which is an example of a DER. Somewhat similar to the approach in our paper, threats are identified (using the Microsoft Threat Modelling Tool) and evaluated (using the DREAD approach), and finally countermeasures are proposed. A total of 220 threats were identified, but only 21 of them were considered for evaluation and mitigation. This relatively high number of threats is in line with previous works applying the Microsoft Threat Modelling tool to smart grid use cases (see for instance [36,38,39,40]) and we regard the effort required to analyze these amounts of threats as a challenge of the STRIDE approach.

As shown by the overview in this section, STRIDE (and the associated DFDs) is a prevalent method for performing a threat modeling of ICSs [41]. However, we also claim that there are challenges in using STRIDE and DFDs [42,43], including the high number of threats which are typically generated, the need to simultaneously represent both networks and devices, and the application-level flow of the data. In this paper, we seek to investigate whether our suggested threat modeling method can address some of these challenges.

2.2. 5G

5G is envisioned as a suitable technology for smart grid use cases as it allows for high IoT connectivity, and low latency. For DSOs it also represents a potential cost saving, as the technology allows for logically separated slices [44], establishing the possibility for the smart grid to share its underlying communication infrastructure with other industries and domains.

A 5G network consists of the Radio Access Network (RAN) and the core network (CN). The RAN connects end devices (for instance IoT devices in the case of smart grid) to the 5G CN. The CN in 5G utilizes a highly software- and virtualization-oriented architecture, and implements the functionality needed for the operation of the 5G network, including routing, authentication, and interconnections with other networks (such as other mobile network operator networks and the Internet).

The use of network slices [44] represents improved security, since only authorized units are allowed to communicate within the slice, and the network bandwidth allocated to the slice will be reserved and cannot be influenced by other 5G units. Compared to 3G and 4G, “pure” 5G is more resistant to the fake base station attack [45], and when properly configured [46], 5G can prevent masquerade, eavesdropping and integrity violations using TLS; ensure authorization and access rights with OAuth; and ensure accountability and attributability using the Network Data Analytics Function (NWDAF).

While 5G has improved security compared to earlier generations, some security issues remain. In their paper on 5G and smart grid security, Borgaonkar et al. [47] group potential 5G threats into local attacks (requiring physical access), wireless attacks (requiring access to the base station coverage area), and remote attacks. The paper focuses on the two first categories of attacks, and lists potential threats, including fake base station attacks causing privacy violations and denial of service and downgrading attacks causing information disclosure.

3. Method Used for the Threat Modeling

In this section, we describe the method chosen to perform the threat modeling (see Figure 1). The details of how each step of the method were adapted to our use case, as well as the overall threat modeling process, is presented in Section 5.

3.1. Limitations of STRIDE for Threat Modeling of ICS

As discussed in our previous publications [15,36,38], we believe that there a number of drawbacks to using STRIDE in the threat modeling of ICS. Sion et al. [43] claim that Data Flow Diagrams cannot model security controls or provide information on where systems are deployed. STRIDE may appear confusing as it mixes categories that directly violate security properties with categories which represent preparation. Spoofing does not, e.g., inherently violate confidentiality, integrity and availability (CIA), but if an attacker successfully spoofs a legitimate user, it can then proceed to violate CIA [15]. STRIDE can also cause the number of identified threats to become high and thus unmanageable, as demonstrated by Holik et al. [36].

According to a recent paper by Granata and Rak [48], the Microsoft Threat Modelling Tool (MS TMT) remains the most commonly used tool for automatic threat modeling. STRIDE was originally designed for threat modeling web software, and some aspects of cyber-physical systems are more difficult to contain in the traditional paradigm [38]. For instance, there is no concept of a router or firewall in the standard Microsoft STRIDE approach [49], so an attack on a firewall is difficult to model. If there is a VPN connection between routers, this is simply added as a property to the data flow, which might be easily missed. For this reason, we had to create two models in MS TMT for each instance when using STRIDE in a specific case [36]; one network-oriented model and one process-oriented model. This proved inelegant and difficult to maintain in the long run.

3.2. The Selected Threat Modeling Method

For convenience, we provide a summary of the chosen method based on the original description [15]. The method consists of three main steps: creating a threat model, identifying threats, and evaluating and mitigating threats.

3.2.1. Creating a Threat Model

In this step, a model of the system to be threat-modeled is created using the elements in Figure 2. The four elements “Host Device”, “Network Device”, “Embedded Device” and “Zone”, are inspired by how these terms are defined in the IEC 62443 standard [50].

The “External Entity” element is inspired by Data Flow Diagrams (DFDs), which are typically used in STRIDE based threat modeling. This element is used to model components or systems outside of the DSO’s control, for instance, 5G infrastructure.

The “ICS function” element is used to model the software implementation of a function or service in the ICS. The element is inspired partly by the IEC 62443 definition of an application and partly by the “process” and “data flow” elements of DFDs. In our chosen threat modeling method, a process is modeled as a yellow circle and typically corresponds to one (or a set of related) processes running in the context of an operating system. An example of a process may be the software on an intelligent electronic device (IED) implementing the functionality needed to receive and execute commands from the control center. If the ICS function is realized through multiple and distributed processes, these can be connected through data flows (which we, for simplicity and contrary to DFDs, model as undirected lines).

Standalone security controls are used to model security controls that are implemented independently of ICS functions. Examples include firewalls and antivirus software.

3.2.2. Identifying Threats

In this step, threats are identified with the help of the guide questions. The guide questions are listed in Section 3.2.3, Section 3.2.4 and Section 3.2.5. For each ICS function in our model, we go through the guide questions, and note down different threats. These threats are effectively answers to the guide questions.

Using guide questions to facilitate the analysis is party inspired by the safety oriented HAZOP method, where specific questions are asked to identify potentially unsafe conditions. The guide questions used in the method focus on the properties of availability, integrity, and confidentiality. These categories were chosen as they are easy to relate to and understand, including for those who are new to threat modeling. Furthermore, by limiting the method to three categories (for instance as opposed to six as is the case for STRIDE), the method intends to also limit the number of threats and hence the amount of effort required.

3.2.3. Availability

The availability questions target the different aspects where an attacker can cause an ICS function to become unavailable or not perform its intended function. As is reflected in the three guide questions, this can either occur due to one of the involved ICS function processes not working, failure to transmit information between the ICS function processes, or underlying hardware not being able to run ICS function processes.

A1:: How can an attacker deny the arrival of data sent between the processes that are part of the ICS function?
A2:: How can an attacker deny the service of the processes that are part of the ICS function?
A3:: How can an attacker deny the service of the devices involved in realizing the ICS function?

3.2.4. Integrity

The integrity questions target points where an attacker can send malicious data to an ICS process or tamper with information already part of an ICS function process.

I1:: How can an attacker send false data to any of the processes that are part of the ICS function, or tamper with legitimate data being sent from any of the processes that are part of the ICS function?
I2:: How can an attacker program/change logic (e.g., trip values, setpoints) in any of the processes that are part of the ICS function?

3.2.5. Confidentiality

The confidentiality question targets how an attacker can extract information from an ICS function. As confidentiality is generally considered less critical than availability and integrity in ICS security, and in the interest of limiting the amount of effort required, the confidentiality property is covered by only one question.

C1:: How can an attacker obtain sensitive information from the ICS function?

3.2.6. Evaluating and Mitigating Threats

In this step, threats are prioritized and then mitigations are proposed based on which threats can be accepted. The method leaves it to the team performing the threat modeling to determine the details regarding how threats should be prioritized and which threats are acceptable.

4. Use Case Description

The use case is centred around a segment of a distribution grid characterized as medium voltage, which is typically a voltage of 22 kV in Norway. The MV grid can be directly connected to several Distributed Energy Resources (DERs) such as wind-based generation [51], photovoltaic (PV) power systems, large battery parks, and high-power charging stations that can be used as local energy hubs. In the low-voltage (LV) grid, flexible end-users with local energy production, battery storage, and load flexibility can also be aggregated and act as a DER for the MV grid through a substation connecting the LV part of the grid to the MV part of the grid. This use case assumes that the different DERs can be generalized and that the power (active and/or reactive) produced or consumed by each DER can be adjusted by providing an updated setpoint to their internal control systems.

The Distribution System Operator (DSO) is responsible for monitoring and operating the distribution grid, which has traditionally mainly consisted of the manual adjustment of switches and changes in tap settings for transformers. However, the integration of more VRES requires the DSO to play a more active role with more advanced systems to control or influence the DERs. As a result, there has been a lot of research on developing optimal control algorithms for distribution grids [52,53]. The most prominent of these algorithms can either be categorized as utilizing a centralized, distributed control architecture. Most of the reviewed literature suggests that the best results will likely be achieved by implementing some combination of the two [52,54]. However, we will focus on analysing the fundamental differences between the centralized and the distributed control architectures instead of different hybrid architectures.

A centralized control architecture is illustrated in Figure 3, and is characterized by a single central controller (CC Server), which would typically be in the DSO’s control center. The CC Server receives measurements and information from each node (illustrated as blue dashed arrows) and uses these together with a model of the distribution grid to solve an optimization problem and determine the optimal setpoint. The black dotted lines illustrate how the individual nodes are connected to the various DER resources. The black unbroken lines represent the power network itself.

Distributed control is characterized by the lack of a centralized node, instead allowing for the optimization problem to be solved iteratively through communication between the neighbouring nodes (DC nodes). Each node has its own distributed controller that could be in, e.g., the substations to the LV grid or at a DER that is directly connected to the MV grid. A high-level view of this architecture can be seen in Figure 4. The blue dashed arrows represent the communication between the distributed nodes, and the black dotted lines illustrate how the individual nodes are connected to the various DER resources. The black unbroken lines represent the power network itself.

Table 1 provides an overview of the different properties that are inherent to the centralized and distributed control architectures. Based on previous work [3], it was demonstrated that different control architectures can achieve a similar and near-optimal performance if the underlying control algorithms are designed appropriately. Thus, we suggest that scalability, ICT infrastructure, and vulnerability towards cyberattacks should be emphasized more when choosing the control architecture for the distribution grid. To the authors’ knowledge, the susceptibility to different types of cybersecurity threats has not been compared between these two control architectures.

5. Threat Modeling Process

In this section, we present the threat modeling process, based on the method described in Section 3, performed on the use case described in Section 4. The threat modeling activity was mainly performed through online and in-person meetings with all the participating authors, but also through asynchronous contributions to the paper. For the meetings, one of the authors acted as secretary, preparing the material needed and processing the outputs from the meetings. We used a shared Miro (miro.com) board to facilitate the discussion. Before starting the threat modeling process, we created a detailed description of the use case, similar to the ones shown in Figure 5 and Figure 6.

5.1. Scope

As stated in the introduction, our goal is to compare the cybersecurity of centralized and distributed control architectures and evaluate the threat modeling method. To ensure that we detect all aspects of the difference in architectures, we adopt a wide scope for the threat identification step. This scope includes insider threats, supply chain threats, and cyberattacks requiring physical access.

5.2. Creating a Model

In this section, we create models for the centralized and distributed control architectures and state the assumptions we make.

5.2.1. Centralized Architecture

First, we create a model of the centralized architecture using the elements from the threat modeling method introduced in Section 3.2. This model is shown in Figure 5, which details the components and the communication aspects to a greater degree compared to Figure 3. DERs are modeled as en external entity (symbolized by a square) as these are assumed to be outside of the grid company’s control and operation. Examples of DER nodes from Figure 3 may include solar farms, battery storages, or windmills. In the centralized control architecture, the optimization problem is solved by a server in the control room. While the server is likely still subjected to some real time constraints, we model this as a host device (symbolized by a square with rounded corners). This is because we assume this device to be more of a classical server with more computational power than what is typically found in embedded devices. This server, called the Centralized Control Server (CC Server), is placed inside a DSO control center. Communication between the CC nodes connected to the DERs and the CC Server is modeled as ICS function 1, consisting of different software processes running on the centralized server and on the different control nodes located in the DERs. The communication between the software processes is modeled as an application-level data flow, symbolized by the yellow line connected to the software processes. ICS function 1 is responsible for collecting measurements, calculating set points, and distributing setpoints.

The underlying communication infrastructure is assumed to be the 5G network, with a core network and RAN nodes. Since the 5G network is not operated by the DSO, these elements are modeled as external entities (symbolized by squares).

There are two additional ICS functions in the model, numbered 2 and 3, as shown in Figure 5. These ICS functions are related to the local control of DER nodes, including collecting measurements of properties such as voltage, and acting on the setpoints provided by ICS function 1. As these functions are assumed to be largely the same in the two architectures, we do not include them in the threat modeling.

5.2.2. Distributed Architecture

The model of the distributed control architecture (Figure 6) shares similarities with the centralized control architecture, but the main difference is the absence of a central control node placed in a DSO control center. Instead, the optimization problem is fully distributed through the iterative sharing of data between distributed controllers (DCs). These distributed controllers are assumed to run real-time operating systems (causing us to model them as embedded devices), but still possess more computing power than, for instance, a Remote Terminal Unit (RTU).

Attributes for ICS function 1:

In the centralized architecture, this function collects measurement data and sends them to the centralized node, who solves the optimization and returns the setpoint.
In the distributed architecture, this function solves the optimization problem by iteratively exchanging data with the nearest neighbors 1000–10,000 times.
In addition to underlying security controls, the traffic is encrypted and authenticated at the application level.
Data are sent through a dedicated 5G slice managed by the mobile network operator.
In the centralized architecture, data sent between the DSO control center and the 5G core are sent through a VPN implemented on top of a network provided by a third party. This network is not accessible from the internet.
In the centralized architecture, a human operator has insight into the received measurements and resulting setpoint, but the operator does not have to be involved in the transmission of setpoints to the respective CC nodes. However, if need be, we assume that the operator can manually interfere and determine setpoints. In the distributed architecture, a human operator does not have insight into the received measurements and resulting setpoint. However, we assume that an operator, through a functionality which we do not model here, still has insight into the general state of the grid.
Authentication to the 5G network and authorization to access the slice are handled by the mobile network operator.
Application-level authentication is handled by the DSO using the infrastructure placed in the DSO control center.
Updates to the software implementing the ICS function (including the optimization algorithm configuration) are performed by a third party but pass through a server placed in the DSO control center (not included in Figure 5 and Figure 6).

Attributes of the grid control center:

Hosts a number of other devices and services that are not explicitly modelled in our use case.

Attributes for 5G core network:

Operated by an MNO and handles both smart grid traffic and traffic from general customers.
Implements and configures the slice which the traffic from the ICS function is sent.
The slice is implemented using standard CN functions. It is shared between the slice and the commercial 5G network, but behaves as a logically separate network. Functionality in the core network authorizes which subscribers/devices can access the slice.

Attributes for 5G RAN:

Connected to the CN through fiber cables.
Each base station only serves one DER node.
Operated by the same Mobile Network Operator as the core network.

Attributes for CC/DC node:

Specifically built device running a real-time operating system, designed for relaying data between the DER and the centralized control node.
In the distributed architecture the DC node hosts a fully distributed service for keeping track of the DER nodes in the grid, letting each node know which other nodes to exchange data with.
Designed for communication across multiple interfaces for increased interoperability.
Updates, patching, and general configuration are handled by a third-party service provider.

Attributes for DER:

Owned and operated by a third-party company.
Can vary with regard to type (e.g., battery, wind, or photovoltaic) and with regard to production capacity.

5.3. Identifying Threats

We list all identified threats according to the guide questions and include additional information regarding the threat.

Firstly, we indicate whether the threat requires that another threat to materialize for the currently considered threat to be relevant. As an example, in order to embed malware in a DC/CC node software update, the attacker would first have to successfully compromise the PS or SP. We observed that many of the threats we originally identified were in fact a chain of two threats, and that many of the threats we identified (listed in Appendix A) relied on the same prerequisite threat having materialized. We therefore denoted these prerequisite threats as basic threats. These basic threats are listed in Table 2.

Secondly, we indicate where the attacker performing a threat is located. Here, we make the distinction between an attacker being physically close to DSO assets, an attacker within wireless range of DSO assets, or a remote attacker.

Thirdly, we indicate whether the threat is relevant to the centralized control architecture, the distributed architecture, or both. Threats are numbered according to the associated question in Section 3, i.e., threats related to question I1 are numbered as I1.x, and so on. For brevity, we only include a few examples of threats in Table 3. The full list of identified threats is listed in Appendix A, and a mapping to applicable security measures is provided in Appendix B.

5.4. Evaluating and Mitigating Threats

In the third and final step of the method, we first evaluate which threats can either be accepted or considered already mitigated, and then continue to propose mitigations for the remaining threats.

In Table 4, we list the threats that we either accept or consider to be mitigated, along with a justification. For prioritization, we simply make the distinction between whether a threat can be accepted, whether it already is mitigated, whether it is out of scope, or whether it needs mitigation. This is, in turn, based on whether a threat has the potential for blackout or electricity market manipulation. For our use case, we assume that the ability to achieve this is tightly tied to the number of DERs an attacker can impact. If an attacker can compromise the integrity, availability or confidentiality of more than one DER, we assume that the risk of blackout or market manipulation is present.

However, if only one DER is affected, we assume that the grid can “absorb” the effects of any malicious actions with regards to grid stability. We also assume that the amount of data obtained from compromising one DER is insufficient for achieving any significant gain from attempted electricity market manipulation.

The remaining threats are mapped to one or more proposed security controls. Specifically, the list of security controls is derived as follows. For the first threat, we propose security controls intended to help mitigate it. We repeat this process for all the threats, the only difference being that as the number of security controls increases, the threat being considered may be covered by existing security controls. In this case, the threat is mapped to the already listed controls. Once we have gone through the list of threats, we review the mapping to ensure that the mapping between threats and security control reflects all the threats a particular security control can help mitigate. Mapping textual descriptions of threats to textual descriptions of security measures inevitably leaves room for interpretation, and another team performing the threat modeling could very well have arrived at another result in terms of both the proposed security measures andthe mapping between threats and security measures.

We show a subset of the mapping of threats to security controls in Table 5. The full mapping is show in Appendix B.

6. Discussion

In this section, we compare the cybersecurity of the centralized and the distributed architecture and discuss the threat modeling method and the process of doing threat modeling.

6.1. Cybersecurity of the Centralized and the Distributed Control Architectures

As shown in Appendix A, we identified a total of 38 threats for the centralized and distributed architectures (in addition to the five basic threats). Of the 38 threats, 23 were applicable to both architectures, 9 were only applicable to the centralized architecture, and the remaining 6 threats were only applicable to the distributed architecture. We focus mostly on the threats that are unique to one of the two architectures.

The centralized architecture does, in some sense, have a larger attack surface, as an attacker may target both CC nodes and the CC server in the DSO control center, with the latter effectively constituting a single point of failure for this architecture. Another single point of failure is the connection between the 5G CN and the control center network, or firewalls and routers in the control center. The centralized architecture also includes a human operator, which comes with the threat of a malicious insider.

Consequently, one can argue that the distributed architecture has a smaller attack surface, since it does not rely on a control center or the connection between the control center and the 5G CN. However, because of this the control nodes are also more complex, performing optimal setpoint calculations and iteratively exchanging data with their neighbor nodes. It may also be more vulnerable to jamming attacks, since each DC node transmits data to its neighbors 1000–10,000 times. Even if a jamming attack only succeeds in introducing a small latency in each transmission, this can accumulate to a significant delay.

The majority of threats, however, affect both architectures, and at a high level, the security of both the architectures relies on the security of the supply chain, the security of the 5G network, and on such practices as device hardening and the secure distribution and revocation of cryptographic keys and eSIMs. Based on the results in this paper, it is difficult to conclude which of the two control architectures are more secure. The security of an implemented control architecture will depend on a variety of things, many of which a model of our abstraction level cannot adequately represent. Previous works have suggested that the distributed architecture can have advantages in terms of cybersecurity [52], due to the limited sharing of information with other agents/nodes, and with regards to privacy [55].

We are, however, unsure of whether the fact that an architecture is distributed in itself is sufficient to conclude that it is more secure. Based on the high-level description of both architectures drawn up in this paper, we believe that one cannot conclude that one of the architectures is inherently more secure than the other. One can argue that it would be easier to conclude this if the models of the centralized and distributed architectures were more detailed. However, in our use case, the exact details are not known at this stage in the design process. Furthermore, a complete and detailed design will rely on many factors unrelated to cyber security, and creating detailed models is therefore challenging.

6.2. Threat Modeling Method

During the threat modeling process, we made several observations which we proceed to discuss in this section.

Level of abstraction: A question that often came up during the threat modeling process was how things were implemented. At an early stage of the design process, as is the case with our use case, many design choices are still undecided. Both in the identification and evaluation of threat phases, the discussion tends to become detailed and technical. Care must therefore be taken to ensure that threats are formulated in such a way that they are detailed enough to provide value, but general enough to avoid making premature assumptions about the design.
Use of guide questions: Overall, the guide questions seemed to work well, although at times we had to remind ourselves of what was included in or intended for each of the questions. This was possibly most relevant when dealing with the guide questions related to availability, A1, A2, and A3, relating to the availability of the transmitted data, the availability of ICS function software processes, and the availability of the underlying infrastructure supporting the software processes, respectively.
Duplicate threats: The third observation relates to duplicate threats, i.e., similar threats being identified for several of the guide questions. To illustrate this, consider the following guide questions, I1, A1, and C1:
- I1: How can an attacker send false data to any of the processes that are part of the ICS function, or tamper with legitimate data being sent from any of the processes that are part of the ICS function?
- A1: How can an attacker deny the arrival of data sent between the processes that are part of the ICS function?
- C1: How can an attacker obtain sensitive information from the ICS function?
For all these questions, some variation of the threat “an attacker may attempt to compromise the supply chain to embed a malware in the ICS function” is a valid answer. One can image a malware with the ability to tamper with data in the software process, deny the functioning of the software process, or exfiltrate data from the process. Because of this, in some cases, we observed similar threats reoccurring, although with different consequences.
Process driven by threats or consequences: In its current form, the threat modeling method starts by identifying threats, attempting to answer such questions as “How can an attacker obtain sensitive information”. Then, the method proceeds to evaluate whether the threat is acceptable or not. A danger of this is that we might identify threats which turn out to be less relevant, either because they are acceptable or because they affect systems which are less critical. We therefore wonder if it is better to start out by first asking “What are the consequences if sensitive information is leaked?”. If the consequences turn out to be unacceptable, we can then move on to identify how an attacker can perform this, i.e., the threat. An added benefit is that it might be more motivating for asset owners to identify threats when this step follows directly from the conclusion that a consequence is unacceptable.
Effort and reproducibility: One of the principles behind the chosen threat modeling method is that it should be lightweight and easy to use. While we would argue that the barriers to understanding and applying the method are low, performing the threat modeling is still a time-consuming process. The outcome of the threat modeling is also dependent on the team performing the threat modeling. This may hold even more true for the method chosen in this paper, as the process is driven by rather generic threat guide questions. While this makes the method lightweight and flexible, it likely also makes the outcome more dependent on the team performing the threat modeling.
Description of threats: While the threat modeling method does not stipulate how identified threats should be structured and documented, we believe it is useful to augment threat descriptions to explicitly include attacker location (fully remote, within wireless range, physical access) and prerequisites (which threats must already have materialized for the current threat to be possible), along with a description of the threat itself.
Threat categories: One can argue that threat modeling of ICSs should also include threats directly related to controllability and observability. However, as these properties are reliant on integrity and availability, we do not include them explicitly. This is to reduce the complexity and the effort required for performing the threat modeling.

7. Conclusions and Further Work

This paper studies both the cybersecurity of two alternative architectures for controlling the MV part of the power grid using threat modeling, and the performance and usability of the applied threat modeling method.

A threat modeling of the two control architectures reveals that most of the threats are relevant to both architectures. While there are differences, we found it hard to conclude which of the two architectures modeled and described at the conceptual level is the most secure. This largely contradicts the common assumption that the distributed architecture is inherently more secure than the centralized system [1,52,56]. We do, however, identify a significant number of threats and associated security controls, which could prove useful when developing these architectures further.

The selected threat modeling method facilitates a comparison of the cybersecurity of two architectures described at the conceptual level. It also allows us to identify challenges and potential areas of improvement. The method should however be further validated in an industry context.

A step towards concluding with more confidence which of the two control architectures is the most secure could be to investigate the threats that affect the two architectures differently in a more detailed manner. As examples, one could investigate the consequences of introducing a delay in the communication between the control nodes in the distributed architecture. Additionally, the effectiveness of different threat detection and mitigation techniques, and the extent to which they can be implemented in the two different architectures, is something that needs to be explored further.

As our work does not focus on validation, a key part of our future work will be to validate the results through interaction with industry representatives. Specifically, we believe it would be important to investigate whether the threat modeling achieves a suitable trade-off between the level of detail and efficiency, whether the identified threats appear relevant, and whether the guide questions are helpful and complete with regard to the aspects they cover. Furthermore, we would like to investigate whether one should approach threat modeling by first identifying threats or by first considering consequences.

Author Contributions

Conceptualization, L.H.F.; methodology, L.H.F. and J.R.A.K.; investigation, L.H.F., J.R.A.K. and M.G.J.; resources, M.G.J.; writing—original draft preparation, L.H.F.; writing—review and editing, L.H.F., J.R.A.K. and M.G.J.; project administration, M.G.J.; funding acquisition, M.G.J. All authors have read and agreed to the published version of the manuscript.

Funding

This research was funded by the Norwegian Research Council through FME CINELDI, grant number 257626. The APC was funded by MDPI.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

The original contributions presented in this study are included in the article. Further inquiries can be directed to the corresponding author.

Conflicts of Interest

Author Lars Halvdan Flå and Martin Gilje Jaatun were employed by SINTEF Digital. Author Jonatan Ralf Axel Klemets was employed by SINTEF Energy Research. The funders had no role in the design of the study; in the collection, analyses, or interpretation of data; in the writing of the manuscript; or in the decision to publish the results.

Abbreviations

The following abbreviations are used in this manuscript:

CC	Centralized Control
CN	(5G) Core Network
DC	Distributed Control
DER	Distributed Energy Resource
DSO	Distribution System Operator
FME	Forskningssenter for Miljøvennlig Energi
ICS	Industrial Control System
MDPI	Multidisciplinary Digital Publishing Institute
MV	Medium Voltage
PV	PhotoVoltaic
STRIDE	Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service,
	Elevation of privilege
VRES	Variable Renewable Energy Sources

Appendix A. Identified Threats

The identified threats are documented in Table A1, Table A2, Table A3, Table A4 and Table A5.

Table A1. Threats to the integrity of transmitted data, I1.

Number	Threat Description
I1.1	Basic Threat: B1. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An attacker may leverage access to the 5G slice and attempt to compromise the infrastructure responsible for distributing ICS process keys, generate a new key, and use the key to inject false data into the calculation of new DER setpoints.
I1.2	Basic Threat: B1. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An attacker may attempt to target a DC/CC node to extract application key material, (for instance exploiting Heartbleed -like vulnerabilities [18]) and use this to inject false data into the calculation of new DER setpoints.
I1.3	Basic Threat: None. Attacker location: Physical. Relevant Architecture: Centralized. Threat Description: An inside operator may attempt to tamper with legitimate data or inject false data into the calculation of new DER setpoints.
I1.4	Basic Threat: B4. Attacker location: Physical or in wireless range. Relevant Architecture: Both. Threat Description: An attacker may leverage a compromised CC/DC node and attempt to install malware which can tamper with legitimate data or inject false data into the calculation of new DER setpoints.
I1.5	Basic Threat: B3. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An attacker may attempt to leverage a compromised PS or SP to install malware on the DC/CC node, which can tamper with legitimate data or inject false data into the calculation of new DER setpoints.
I1.6	Basic Threat: B3. Attacker location: Remote. Relevant Architecture: Centralized. Threat Description: An attacker may attempt to leverage a compromised PD or SP to install malware in the control center through the supply chain, which can tamper with legitimate data or inject false data into the calculation of new DER setpoints.
I1.7	Basic Threat: B4. Attacker location: Physical. Relevant Architecture: Both. Threat Description: An attacker may attempt to steal a CC/DC node and physically manipulate the sensor readings directly (for instance by applying heat to it), potentially while also moving it to another location.
I1.8	Basic Threat: B1. Attacker location: Remote. Relevant Architecture: Centralized. Threat Description: An attacker may attempt to target the CC server to extract application key material, (for instance exploiting Heartbleed-like vulnerabilities [57]) and use this to inject false data into the calculation of new DER setpoints.
I1.9	Basic Threat: B4. Attacker location: Physical, wireless range. Relevant Architecture: Both. Threat Description: An attacker may leverage a compromised CC/DC node, attempt to extract 5G and application key material, and use this to inject false data into the calculation of new DER setpoints.

Table A2. Threats to integrity of processes, I2.

Number	Threat Description
I2.1	Basic Threat: B1. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An attacker may leverage access to the 5G slice and attempt to compromise application-level authentication to program or change control logic in the processes which are part of the ICS function.
I2.2	Basic Threat: B3. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An attacker may leverage a compromised PS to embed a malware which can program or change control logic in the processes which are part of the ICS function.
I2.3	Basic Threat: B3. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An attacker may leverage a compromised SP to reprogram or reconfigure the processes in the CC/DC nodes which are part of the ICS function.
I2.4	Basic Threat: None. Attacker location: Physical. Relevant Architecture: Centralized. Threat Description: An inside operator may attempt to change the logic/setpoints in the processes in the different CC nodes from the control center.
I2.5	Basic Threat: B4. Attacker location: Physical, wireless range. Relevant Architecture: Both. Threat Description: An attacker may leverage a compromised DC/ CC node and use this to attempt to change program logic.
I2.6	Basic Threat: B2. Attacker location: Remote. Relevant Architecture: Centralized. Threat Description: An attacker may attempt to compromise and gain privileges on the CC server in the control center which in turn can be used for changing ICS function logic.
I2.7	Basic Threat: B1 or B2. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An attacker may leverage access to the 5G slice, or the DSO control center attempt to exploit the remote update/configuration functionality of the CC/DC nodes, administered through a server in the DSO control center.
I2.8	Basic Threat: B4. Attacker location: Physical, wireless range. Relevant Architecture: Distributed. Threat Description: An attacker may leverage a compromised DC node and attempt to spread malware in the form of a worm, which may be used to tamper with legitimate data or inject false data into the calculation of new setpoints.

Table A3. Threats to availability of transmitted data, A1.

Number	Threat Description
A1.1	Basic Threat: None. Attacker location: Wireless range. Relevant Architecture: Both. Threat Description: An attacker may attempt to jam the 5G signal between the CC/DC and the RAN.
A1.2	Basic Threat: B1 or B2. Attacker location: Remote. Relevant Architecture: Distributed. Threat Description: An attacker may attempt to deny the functioning of the service keeping track of DC nodes in the network, for instance by obtaining privileges on the server implementing the service, or by flooding the server with traffic.
A1.3	Basic Threat: B5. Attacker location: Remote. Relevant Architecture: Centralized. Threat Description: An attacker may leverage access to the private network between the 5G CN and the DSO control center and launch a traffic-based DoS attack on the 5G CN and DSO control center interfaces.
A1.4	Basic Threat: B1 or B2. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An attacker may leverage access to the 5G slice or the DSO control center to target the authentication infrastructure deployed there, to attempt to revoke the long-term cryptographic key/certificate used by ICS function processes running in the CC/DC nodes, to make the receiver discard communication encrypted with the key. This can for instance be done by exploiting an insecure implementation or compromising an admin account.
A1.5	Basic Threat: None. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An attacker may attempt to revoke the eSIMs used by CC/DC nodes, to deny the node access to the 5G network. This can for instance be attempted by pretending to be the DSO towards the MNO.
A1.6	Basic Threat: None. Attacker location: Physical. Relevant Architecture: Both. Threat Description: An attacker may attempt to cut cables connecting the 5G base stations, or otherwise destroy base stations.
A1.7	Basic Threat: B3. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An attacker may leverage a compromised MNO supplier and attempt to deny the service of the 5G CN functions needed for the correct functioning of the 5G slice.
A1.8	Basic Threat: None. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An employee at the MNO may attempt to take down or alter 5G services needed for the correct functioning of the 5G slice.
A1.9	Basic Threat: None. Attacker location: Physical. Relevant Architecture: Centralized. Threat Description: An employee at the DSO may attempt to take down or alter services in the control center (e.g, crashing the algorithm solver, blocking all traffic to the firewall) needed for the correct functioning of the ICS function.

Table A4. Threats to availability of ICS function processes, A2.

Number	Threat Description
A2.1	Basic Threat: B3. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An attacker may leverage a compromised PS or SP delivering any of the software used by the processes in the ICS function, and embed malware which can compromise the availability.
A2.2	Basic Threat: B4. Attacker location: Remote. Relevant Architecture: Centralized. Threat Description: An attacker may leverage a compromised CC node and use it to attempt to launch a denial-of-service attack on the CC server.
A2.3	Basic Threat: B4. Attacker location: Remote. Relevant Architecture: Distributed. Threat Description: An attacker may leverage a compromised DC node and use it to attempt to launch a denial-of-service attack on neighboring DC nodes.
A2.4	Basic Threat: B3. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An attacker may leverage a compromised PS to embed malware in the software running in the processes that are part of the ICS function. This malware can proceed to cause denial of service.
A2.5	Basic Threat: B3. Attacker location: Remote. Relevant Architecture: Distributed. Threat Description: An attacker may leverage a compromised SP to exploit the remote update functionality and install malware on the processes running in the CC/DC nodes or CC server. This malware can proceed to cause denial of service.
A2.6	Basic Threat: B4. Attacker location: Remote. Relevant Architecture: Distributed. Threat Description: An attacker may leverage a compromised DC node to attempt to spread malware to other DC nodes in the form of a worm. This malware can proceed to cause denial of service.

Table A5. Threats to availability of underlying infrastructure, A3.

Number	Threat Description
A3.1	Basic Threat: B3. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An attacker may leverage a compromised PS or SP developing software that the ICS function relies on, e.g., developers or maintainers of the relevant operating system, monitoring software or asset inventory software. By embedding denial of service malware in this software, an attacker can compromise the availability of the ICS function.
C1.1	Basic Threat: None. Attacker location: Physical. Relevant Architecture: Centralized. Threat Description: An employee at the DSO might attempt to sell market sensitive data.
C1.2	Basic Threat: None. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An insider at the SP might attempt to steal market sensitive data, for instance by transferring data to an online server or by transferring it to a hard drive.
C1.3	Basic Threat: B3. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An attacker might leverage a compromised PS or SP to embed malware in their products, to later extract market sensitive data.
C1.4	Basic Threat: B3. Attacker location: Remote. Relevant Architecture: Both. Threat Description: An attacker might leverage a compromised SP to use their access to steal market sensitive data.
C1.5	Basic Threat: B4. Attacker location: Remote. Relevant Architecture: Distributed. Threat Description: An attacker may leverage a compromised DC node and use the access to attempt to spread malware in the form of a worm, which can be used to extract data.

Appendix B. Mapping of Threats to Security Measures

The mapping of threats to security measures is shown in Table A6.

Table A6. Mapping threats to security measures.

Number	Security Controls	Threats
SC 1	Harden the implementation and configuration of software and check it periodically.	B4, I1.1, I1.2, I1.8, I1.9, A1.4
SC 2	Only accept the latest cryptographic algorithms and cipher suites.	I2.1, A1.4
SC 3	Put in place procedures and systems for regularly patching vulnerabilities.	B2, B4, I1.1, I1.2, I1.4, I1.8, I1.9, I2.1, A1.2, A1.4,
SC 4	Perform hardware and device hardening (e.g., encrypted flash, removing unused services)	B2, B4, B4, I1.1, I1.2, I1.4, I1.9, I2.5, I2.6, I2.7, I2.8, A1.2, A1.4, A2.6, I1.9, I2.5, I2.6, I2.8, A2.2, A2.3, C1.5
SC 5	Perform/require employee background check (both DSO and suppliers)	B3, I1.3, I2.4, A1.8, A1.9, C1.1, C1.2
SC 6	Require that more than one person is involved in performing an action	I1.3, I2.4, A1.8, A1.9, C1.1
SC 7	Verify signatures of software updates	I1.5, I1.6, I2.2, A2.1, A2.4, A2.5, C1.3
SC 8	Require cyber security certification of suppliers, self-assessments, information security management systems.	B1, B3, B4, B5, I1.5, I1.6, I2.2, I2.3, A2.1, A2.4, A2.5, A3.1, C1.3, C1.4
SC 9	Require suppliers and in-house developers to follow secure development processes.	B1, B4, B4, I1.1, I1.2, I1.5, I1.6, I1.8, I1.9, I2.1, I2.2, I2.5, I2.6, I2.7, A2.1, A2.4, A3.1, C1.3, C1.4
SC 10	Implement processes and solution allowing DSO employees to monitor action performed by SPs.	B4, I1.5, I1.6, I2.3, A2.5, C1.2, C1.4
SC 11	Deny attempts to establish connection from outside of the control center to devices inside the control center, implement a demilitarized zone, and segment the network.	B2, I1.8, I2.6, I2.7, A1.2, A1.4, A2.5
SC 12	Monitor the traffic in the network (5G slice and 5G CN – DSO network)	B1, I1.1, I1.2, A1.1, A1.2, A2.2, A2.3, A2.6, C1.5
SC 13	Configure the 5G slice/base station to be jamming resistant.	A1.1
SC 14	Design the distributed algorithm to handle the loss of the service providing DC nodes with its neighbors in a graceful way (e.g., fallback to the last know list of nearest neighbors).	A1.2
SC 15	Engineer the control center interface to the 5G so that it can handle any reasonable amount of flood-based DoS attacks.	A1.3
SC 16	Implement secure processes for adding and revoking eSIM.	A1.5
SC 17	Require that the mobile network operator forwards the DSO supplier requirements to their suppliers.	A1.8
SC 18	Remove all non-essential software components	A3.1
SC 19	Harden all devices and applications inside the control center, to prevent an attacker from gaining a foothold.	B2, I2.6, I2.7
SC 20	Require the MNO and the provider of the connection between the 5G CN to DSO control center to periodically test and patch their infrastructure.	B1, B5
SC 21	Run anti-virus or whitelisting.	I1.4, I1.5, I1.6, I2.1, I2.2, I2.5, I2.6, I2.7, I2.8, A2.1, A2.4, A2.5, C1.3, C1.5

References

Antoniadou-Plytaria, K.E.; Kouveliotis-Lysikatos, I.N.; Georgilakis, P.S.; Hatziargyriou, N.D. Distributed and Decentralized Voltage Control of Smart Distribution Networks: Models, Methods, and Future Research. IEEE Trans. Smart Grid 2017, 8, 2999–3008. [Google Scholar] [CrossRef]
Šulc, P.; Backhaus, S.; Chertkov, M. Optimal Distributed Control of Reactive Power Via the Alternating Direction Method of Multipliers. IEEE Trans. Energy Convers. 2014, 29, 968–977. [Google Scholar] [CrossRef]
Klemets, J.R.A.; Degefa, M.Z. A distributed algorithm for controlling continuous and discrete variables in a radial distribution grid. IEEE Access 2023, 11, 2488–2499. [Google Scholar] [CrossRef]
Goel, S.; Hong, Y.; Papakonstantinou, V.; Kloza, D.; Goel, S.; Hong, Y. Security challenges in smart grid implementation. In Smart Grid Security; Springer: Berlin/Heidelberg, Germany, 2015; pp. 1–39. [Google Scholar]
Dabrowski, A.; Ullrich, J.; Weippl, E.R. Grid shock: Coordinated load-changing attacks on power grids: The non-smart power grid is vulnerable to cyber attacks as well. In Proceedings of the 33rd Annual Computer Security Applications Conference, Orlando, FL, USA, 4–8 December 2017; pp. 303–314. [Google Scholar]
Gunduz, M.Z.; Das, R. Cyber-security on smart grid: Threats and potential solutions. Comput. Netw. 2020, 169, 107094. [Google Scholar] [CrossRef]
ICS-CERT. Cyber-Attack Against Ukrainian Critical Infrastructure; Tech. Rep. ICS Alert (IR-ALERT-H-16-056-01); Cybersecurity and Infrastructure Security Agency: Washington, DC, USA, 2016. [Google Scholar]
Slowik, J. Crashoverride: Reassessing the 2016 Ukraine Electric Power Event As a Protection-Focused Attack. 2019. Available online: https://hub.dragos.com/hubfs/Reports/Dragos_Global_Electric_Threat_Perspective_Word_Document_0424_r3.pdf?hsLang=enaccessed05/03/2025 (accessed on 4 March 2025).
ESET Research. Industroyer2: Industroyer Reloaded. 2022. Available online: https://www.welivesecurity.com/2022/04/12/industroyer2-industroyer-reloaded/ (accessed on 4 March 2025).
Salazar, L.; Castro, S.R.; Lozano, J.; Koneru, K.; Zambon, E.; Huang, B.; Baldick, R.; Krotofil, M.; Rojas, A.; Cardenas, A.A. A Tale of Two Industroyers: It was the Season of Darkness. In Proceedings of the 2024 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 19–23 May 2024; pp. 312–330. [Google Scholar] [CrossRef]
OT Cyber Threat Intelligence: Electric Threat Perspective; Dragos Report; Dragos: Hanover, MD, USA, 2024.
Abbatemarco, N.; Salviotti, G.; D’Ignazio, C.; De Rossi, L.M. Understanding Leadership Competencies in Cyber Crisis Management: Insights from the Maersk Global Supply Chain Meltdown. In Proceedings of the 57th Hawaii International Conference on System Sciences, Maui, HI, USA, 3–6 January 2024. [Google Scholar]
Langner, R. Stuxnet: Dissecting a cyberwarfare weapon. IEEE Secur. Priv. 2011, 9, 49–51. [Google Scholar] [CrossRef]
Slowik, J. Zeroing in on Xenotime: Analysis of the entities responsible for the TRITON event. In Proceedings of the 2022 Virus Bulletin Conference, Orlando, FL, USA, 28–30 September 2022. [Google Scholar]
Flå, L.H.; Jaatun, M.G. A method for threat modelling of industrial control systems. In Proceedings of the Cyber Science 2023, London, UK, 13–14 June 2023; Springer: Berlin/Heidelberg, Germany, 2023. [Google Scholar]
Ohanu, C.P.; Rufai, S.A.; Oluchi, U.C. A comprehensive review of recent developments in smart grid through renewable energy resources integration. Heliyon 2024, 10, e25705. [Google Scholar] [CrossRef] [PubMed]
Tuballa, M.L.; Abundo, M.L. A review of the development of Smart Grid technologies. Renew. Sustain. Energy Rev. 2016, 59, 710–725. [Google Scholar] [CrossRef]
Peretto, L. The role of measurements in the smart grid era. IEEE Instrum. Meas. Mag. 2010, 13, 22–25. [Google Scholar] [CrossRef]
Matthiss, B.; Erb, J.; Binder, J. Using Smart Meters for Distribution Grid State Estimation. In Proceedings of the 2019 International Conference on Smart Energy Systems and Technologies (SEST), Porto, Portugal, 9–11 September 2019; pp. 1–5. [Google Scholar]
Ding, W.; Xu, M.; Huang, Y.; Zhao, P.; Song, F. Cyber attacks on PMU placement in a smart grid: Characterization and optimization. Reliab. Eng. Syst. Saf. 2021, 212, 107586. [Google Scholar] [CrossRef]
Douglass, D.A.; Gentle, J.; Nguyen, H.M.; Chisholm, W.; Xu, C.; Goodwin, T.; Chen, H.; Nuthalapati, S.; Hurst, N.; Grant, I.; et al. A Review of Dynamic Thermal Line Rating Methods With Forecasting. IEEE Trans. Power Deliv. 2019, 34, 2100–2109. [Google Scholar] [CrossRef]
Zarghami, M.; Niknam, T.; Aghaei, J.; Nezhad, A.H. Concurrent PV production and consumption load forecasting using CT-Transformer deep learning to estimate energy system flexibility. IET Renew. Power Gener. 2024, 18, 2139–2161. [Google Scholar] [CrossRef]
Liu, J.; Ponci, F.; Monti, A.; Muscas, C.; Pegoraro, P.A.; Sulis, S. Optimal Meter Placement for Robust Measurement Systems in Active Distribution Grids. IEEE Trans. Instrum. Meas. 2014, 63, 1096–1105. [Google Scholar] [CrossRef]
Ruuth, K.; Mutanen, A. Demonstrating State Estimation for Future Smart Grid. In Proceedings of the 2023 IEEE PES Innovative Smart Grid Technologies Europe (ISGT EUROPE), Grenoble, France, 23–26 October 2023; pp. 1–6. [Google Scholar]
Bjarghov, S.; Stefanussen Foslie, S.; Askeland, M.; Rana, R.; Taxt, H. Enhancing grid hosting capacity with coordinated non-firm connections in industrial energy communities. Smart Energy 2024, 15, 100154. [Google Scholar] [CrossRef]
Yee Chong, A.T.; Mahmoud, M.A.; Lim, F.C.; Kasim, H. A review of Smart Grid Technology, Components, and Implementation. In Proceedings of the 2020 8th International Conference on Information Technology and Multimedia (ICIMU), Selangor, Malaysia, 24–26 August 2020; pp. 166–169. [Google Scholar]
Irfan, M.; Sadighian, A.; Tanveer, A.; Al-Naimi, S.; Oligeri, G. A survey on detection and localisation of false data injection attacks in smart grids. Iet-Cyber-Phys. Syst. Theory Appl. 2024, 9, 313–333. [Google Scholar] [CrossRef]
Swiderski, F.; Snyder, W. Threat Modeling; Microsoft Press: Redmond, WA, USA, 2004. [Google Scholar]
Shostack, A. Threat Modeling: Designing for Security; Wiley: Hoboken, NJ, USA, 2014. [Google Scholar]
Khalil, S.M.; Bahsi, H.; Korõtko, T. Threat modeling of industrial control systems: A systematic literature review. Comput. Secur. 2024, 136, 103543. [Google Scholar] [CrossRef]
Ling, E.R.; Ekstedt, M. Generating threat models and attack graphs based on the IEC 61850 system configuration description language. In Proceedings of the 2021 ACM Workshop on Secure and Trustworthy Cyber-Physical Systems, Virtual Conference, 26 April 2021; pp. 98–103. [Google Scholar]
Ling, E.R.; Ekstedt, M. A threat modeling language for generating attack graphs of substation automation systems. Int. J. Crit. Infrastruct. Prot. 2023, 41, 100601. [Google Scholar] [CrossRef]
Hawrylak, P.J.; Haney, M.; Papa, M.; Hale, J. Using hybrid attack graphs to model cyber-physical attacks in the smart grid. In Proceedings of the 2012 5th International Symposium on Resilient Control Systems, Salt Lake City, UT, USA, 14–16 August 2012; pp. 161–164. [Google Scholar]
Suleiman, H.; Alqassem, I.; Diabat, A.; Arnautovic, E.; Svetinovic, D. Integrated smart grid systems security threat model. Inf. Syst. 2015, 53, 147–160. [Google Scholar] [CrossRef]
Omerovic, A.; Vefsnmo, H.; Gjerde, O.; Ravndal, S.T.; Kvinnesland, A. An industrial trial of an approach to identification and modelling of cybersecurity risks in the context of digital secondary substations. In Proceedings of the Risks and Security of Internet and Systems: 14th International Conference, CRiSIS 2019, Hammamet, Tunisia, 29–31 October 2019; Springer: Berlin/Heidelberg, Germany, 2020; pp. 17–33. [Google Scholar]
Holik, F.; Flå, L.H.; Jaatun, M.G.; Yayilgan, S.Y.; Foros, J. Threat Modeling of a Smart Grid Secondary Substation. Electronics 2022, 11, 850. [Google Scholar] [CrossRef]
Rahim, F.A.; Ahmad, N.A.; Magalingam, P.; Jamil, N.; Cob, Z.C.; Salahudin, L. Cybersecurity vulnerabilities in smart grids with solar photovoltaic: A threat modelling and risk assessment approach. Int. J. Sustain. Constr. Eng. Technol. 2023, 14, 210–220. [Google Scholar]
Flå, L.H.; Borgaonkar, R.; Tøndel, I.A.; Jaatun, M.G. Tool-assisted threat modeling for smart grid cyber security. In Proceedings of the 2021 International Conference on Cyber Situational Awareness, Data Analytics and Assessment (CyberSA), Virtual Conference, 14–18 June 2021; pp. 1–8. [Google Scholar]
Vallant, H.; Stojanović, B.; Božić, J.; Hofer-Schmitz, K. Threat modelling and beyond-novel approaches to cyber secure the smart energy system. Appl. Sci. 2021, 11, 5149. [Google Scholar] [CrossRef]
Marksteiner, S.; Vallant, H.; Nahrgang, K. Cyber security requirements engineering for low-voltage distribution smart grid architectures using threat modeling. J. Inf. Secur. Appl. 2019, 49, 102389. [Google Scholar] [CrossRef]
Khan, R.; McLaughlin, K.; Laverty, D.; Sezer, S. STRIDE-based threat modeling for cyber-physical systems. In Proceedings of the 2017 IEEE PES Innovative Smart Grid Technologies Conference Europe (ISGT-Europe), Torino, Italy, 26–29 September 2017; pp. 1–6. [Google Scholar]
Sion, L.; Yskout, K.; Van Landuyt, D.; Joosen, W. Solution-aware data flow diagrams for security threat modeling. In Proceedings of the 33rd Annual ACM Symposium on Applied Computing, Pau, France, 9–13 April 2018; pp. 1425–1432. [Google Scholar]
Sion, L.; Yskout, K.; Van Landuyt, D.; van den Berghe, A.; Joosen, W. Security threat modeling: Are data flow diagrams enough? In Proceedings of the IEEE/ACM 42nd International Conference on Software Engineering Workshops, Seoul, Republic of Korea, 27 June–19 July 2020. [Google Scholar]
Lourenço, M.B.; Marinos, L.; Patseas, L. ENISA Threat Landscape for 5G Networks: Updated Threat Assessment for the Fifth Generation of Mobile Telecommunications Networks (5G); European Union Agency for Cybersecurity (ENISA): Attiki, Greece, 2020.
Sheng, Y.; Guanjie, Q.; Guozu, J.; Hao, D.; Liang, F.; Lingqi, L. Research on 5G-based Disaster-Resistant Security for Smart Power Grids. In Proceedings of the 2024 IEEE 7th International Conference on Automation, Electronics and Electrical Engineering (AUTEEE), Shenyang, China, 8–10 November 2024; pp. 125–130. [Google Scholar]
Køien, G.M. On threats to the 5G service based architecture. Wirel. Pers. Commun. 2021, 119, 97–116. [Google Scholar] [CrossRef]
Borgaonkar, R.; Anne Tøndel, I.; Zenebe Degefa, M.; Gilje Jaatun, M. Improving smart grid security through 5G enabled IoT and edge computing. Concurr. Comput. Pract. Exp. 2021, 33, e6466. [Google Scholar] [CrossRef]
Granata, D.; Rak, M. Systematic analysis of automated threat modelling techniques: Comparison of open-source tools. Softw. Qual. J. 2024, 32, 125–161. [Google Scholar] [CrossRef]
Shostack, A. Experiences Threat Modeling at Microsoft. In Proceedings of the Workshop on Modeling Security (MODSEC08). CEUR Workshop Proceedings, Toulouse, France, 28–29 February 2008. [Google Scholar]
IEC 62443-4-2:2019; Security for Industrial Automation and Control Systems—Part 4-2: Technical Security Requirements for IACS Components. International Electrotechnical Commission: Geneva, Switzerland, 2019.
Staggs, J.; Ferlemann, D.; Shenoi, S. Wind farm security: Attack surface, targets, scenarios and mitigation. Int. J. Crit. Infrastruct. Prot. 2017, 17, 3–14. [Google Scholar] [CrossRef]
Molzahn, D.K.; Dörfler, F.; Sandberg, H.; Low, S.H.; Chakrabarti, S.; Baldick, R.; Lavaei, J. A survey of distributed optimization and control algorithms for electric power systems. IEEE Trans. Smart Grid 2017, 8, 2941–2962. [Google Scholar] [CrossRef]
Rodriguez-Gil, J.A.; Mojica-Nava, E.; Vargas-Medina, D.; Arevalo-Castiblanco, M.F.; Cortes, C.A.; Rivera, S.; Cortes-Romero, J. Energy management system in networked microgrids: An overview. Energy Syst. 2024, 15, 1–32. [Google Scholar] [CrossRef]
Messmer, D.; Malmedal, K. Optimizing Distributed Energy Resource Control System Architecture. In Proceedings of the 2021 IEEE Rural Electric Power Conference (REPC), Virtual Conference, 26–29 April 2021; pp. 67–72. [Google Scholar] [CrossRef]
Nguyen, J.; Dupuis, M. Closing the Feedback Loop Between UX Design, Software Development, Security Engineering, and Operations. In Proceedings of the 20th Annual SIG Conference on Information Technology Education, Tacoma, WA, USA, 3–5 October 2019; pp. 93–98. [Google Scholar] [CrossRef]
Hua, H.; Wei, Z.; Qin, Y.; Wang, T.; Li, L.; Cao, J. Review of distributed control and optimization in energy internet: From traditional methods to artificial intelligence-based methods. IET Cyber-Phys. Syst. Theory Appl. 2021, 6, 63–79. [Google Scholar] [CrossRef]
Carvalho, M.; DeMott, J.; Ford, R.; Wheeler, D.A. Heartbleed 101. IEEE Secur. Priv. 2014, 12, 63–67. [Google Scholar] [CrossRef]

Figure 1. Overview of the phases of the threat modeling method (see below for details on each phase).

Figure 2. Model elements for the threat modeling method.

Figure 3. Centralized architecture.

Figure 4. Distributed control.

Figure 5. Model of the centralized control architecture.

Figure 6. Model of the distributed control architecture.

Table 1. Overview of the centralized and distributed control architectures.

Centralized Control (CC)	Distributed Control (DC)
Single central controller that collects and processes all information.	Multiple distributed controllers that collect information locally and communicate with their neighbours.
Single large point of failure. Requires communication links between all nodes and the CC. Optimal actions taken in the CC by solving a large-scale optimization problem. Incorporating new nodes requires updating the connection and software of the CC. The CC requires high computational power to solve the large-scale optimization problem.	Multiple smaller points of failure. Requires communication links between the neighbouring nodes. Optimal actions taken through communication between neighbours until a consensus is reached. Incorporating new nodes only requires connection to neighbouring nodes (“plug and play”). The DC requires a high bandwidth to reach consensus through sharing of information between nodes.

Table 2. Basic threats.

Number	Threat Description
B1	An attacker may attempt to access the 5G slice, thus obtaining access to the devices communicating using this slice. This includes the CC node, the DC node, and the CC server.
B2	An attacker may attempt to obtain a foothold on the DSO control center network, allowing the attacker to interact with devices and services deployed in the control center.
B3	An attacker may attempt to compromise an actor in the supply chain (e.g., Product Supplier (PS), Service Provider (SP), the MNO, the company providing the network access between the DSO control center and the 5G CN).
B4	An attacker may attempt to obtain privileges on, or extract data from, a CC or DC node, for instance through hardware hacking or exploiting a wireless interface. Nodes compromised through supply chain attacks are covered by B3. Attacks which require access to the slice are covered by B1.
B5	An attacker may attempt to obtain a presence on the private network connecting the 5G CN and the DSO control center, thus enabling the attacker to reach the 5G CN and DSO control center interfaces.

Table 3. Example of identified threats.

Number	Threat Description
I1.1	Basic Threat: B1. Attacker Location: Remote. Relevant Architecture: Both. Threat Description: An attacker may leverage access to the 5G slice and attempt to compromise the infrastructure responsible for distributing ICS process keys, generate a new key, and use the key to inject false data into the calculation of new DER setpoints.
I2.1	Basic Threat: B1. Attacker Location: Remote. Relevant Architecture: Both. Threat Description: An attacker may leverage access to the 5G slice and attempt to compromise application-level authentication to program or change control logic in the processes which are part of the ICS function.
A1.1	Basic Threat: None. Attacker Location: Wireless range. Relevant Architecture: Both. Threat Description: An attacker may attempt to jam the 5G signal between the CC/DC and the RAN.
A2.1	Basic Threat: B3. Attacker Location: Remote. Relevant Architecture: Both. Threat Description: An attacker may leverage a compromised PS or SP delivering any of the software used by the processes in the ICS function, and embed malware that can compromise the availability.
A3.1	Basic Threat: B3. Attacker Location: Remote. Relevant Architecture: Both. Threat Description: An attacker may leverage a compromised PS or SP developing software that the ICS function relies on, e.g., developers or maintainers of the relevant operating system, monitoring software or asset inventory software. By embedding denial of service malware in this software, an attacker can compromise the availability of the ICS function.
C1.1	Basic Threat: None. Attacker Location: Physical. Relevant Architecture: Centralized. Threat Description: An employee at the DSO might attempt to sell market-sensitive data.

Table 4. Threats evaluated to be acceptable.

Number	Justification
I1.7	This threat of stealing CC/DC nodes and physically manipulating sensors falls more in the category of physical sabotage than cyber threats, and we therefore consider it out of scope. Adding to this is the fact that this threat is noisy and likely to be detected.
A1.6	For much of the same reason as for the threat above, we consider this out of scope.

Table 5. A subset of the mapping of threats to security controls.

Number	Security Controls	Threats
SC 1	Harden the implementation and configuration of software and check it periodically.	B4, I1.1, I1.2, I1.8, I1.9, A1.4
SC 3	Put in place procedures and systems for regularly patching vulnerabilities.	B2, B4, I1.1, I1.2, I1.4, I1.8, I1.9, I2.1, A1.2, A1.4
SC 4	Perform hardware and device hardening (e.g., encrypted flash, removing unused services).	B2, B4, B4, I1.1, I1.2, I1.4, I1.9, I2.5, I2.6, I2.7, I2.8, A1.2, A1.4, A2.6, I1.9, I2.5, I2.6, I2.8, A2.2, A2.3, C1.5
SC 13	Configure the 5G slice/base station to be jamming-resistant.	A1.1

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

© 2025 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).

Share and Cite

MDPI and ACS Style

Flå, L.H.; Klemets, J.R.A.; Jaatun, M.G. Threat Modeling of Smart Grid Control Architectures. Electronics 2025, 14, 1068. https://doi.org/10.3390/electronics14061068

AMA Style

Flå LH, Klemets JRA, Jaatun MG. Threat Modeling of Smart Grid Control Architectures. Electronics. 2025; 14(6):1068. https://doi.org/10.3390/electronics14061068

Chicago/Turabian Style

Flå, Lars Halvdan, Jonatan Ralf Axel Klemets, and Martin Gilje Jaatun. 2025. "Threat Modeling of Smart Grid Control Architectures" Electronics 14, no. 6: 1068. https://doi.org/10.3390/electronics14061068

APA Style

Flå, L. H., Klemets, J. R. A., & Jaatun, M. G. (2025). Threat Modeling of Smart Grid Control Architectures. Electronics, 14(6), 1068. https://doi.org/10.3390/electronics14061068

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Menu