Security Challenges in Energy Flexibility Markets: A Threat Modelling-Based Cyber-Security Analysis

Abstract

Flexibility markets are crucial for balancing the decentralised and renewable-driven energy landscape. This paper presents a security evaluation of a flexibility market system using a threat modelling approach. A reference architecture for a typical flexibility market system is proposed, and attack graph-driven simulations are performed to analyse potential attack pathways where malicious actors might infiltrate the system and the vulnerabilities they might exploit. Key findings include the identification of high-risk areas, such as the Internet links between market actors. To mitigate these risks, the paper proposes and evaluates multiple protection scenarios in reducing the identified attack vectors. The findings underline the importance of multi-layered security strategies to safeguard flexibility markets from increasingly sophisticated cyber threats.

1. Introduction

Electricity generation and consumption must go hand in hand. This balance is becoming increasingly complex to maintain with the increase in renewable energy sources (RESs) such as distributed energy resources (DERs) and ever-increasing consumption. The main challenge in utilising RESs is managing the inherent unpredictability, which results from their weather dependency and causes fluctuations in electricity generation. At the European level [1], flexibility has been identified as a key solution for addressing many of these challenges. By leveraging demand response [2], flexibility enables the balancing of the fluctuating generation of green electricity with the high demand for energy. Thus, in exchange for financial compensation, consumers agree to adapt their use of the electricity to the demands of the grid. By reducing equipment loading during peak hours, distribution system operator (DSOs) can utilise local flexibility to delay or avoid investments for reinforcements [3].

One widely discussed approach to undertake this integration of local flexibility is through flexibility markets (FMs) [4,5,6]. A typical FM consists of a DSO, a market operator, a balance responsible party (BRP), and several aggregators [2]. Aggregators manage and gather multiple small residential flexibility assets, thus enabling end users to participate in the FM. In a FM, aggregators or private persons are typically flexibility sellers, while DSOs and BRPs buy flexibility. DSOs buy flexibility for operational purposes, such as congestion management or voltage control. BRPs often buy flexibility for portfolio optimisation. By adjusting the power demand of the aggregated residential flexibility assets, the aggregators earn financial profits according to a flexibility agreement. The owners of the flexibility assets also earn profits by providing a DER (e.g., an EV) as a flexibility asset to the aggregator. This design of a FM consists of strong integration of cyber, physical, and market domains. Such an integration allows for efficient deployment of flexibility assets, but also introduces new vulnerabilities to all stakeholders and their systems [2]. By applying end user flexibility in a FM, the DSO grid operation process becomes dependent on third-parties. Moreover, the required implementation of information and communication technology (ICT) and the strong integration with the physical and market domain opens new doors for cyber criminals. Therefore, it is crucial to thoroughly analyse and assess the cybersecurity posture of FMs in order to take steps to ensure their robustness and promote their adoption.

1.1. Related Work

The security of a smart grid is considered crucial [7] and is well studied in general [8], as cyber attacks can impact not only the operational stability of the grid but have catastrophic consequences. Tatipatri et al. [9] provide a comprehensive review of cyber attacks in power systems, detailing the operational impacts of such attacks on energy markets and emphasising the importance of advanced detection and mitigation strategies. Other studies delve into the cyber threats posed by the implementation of new smart grid technologies, such as smart meters and advanced metering infrastructure [10,11,12].

However, most existing studies in the literature on FMs focus on their functionality and positive impacts [13]. The research conducted in [14] shows that it is more crucial to consider security with the integration of flexibility and underlines the need for more extensive and comprehensive security assessments. Several studies explore specific physical threats, such as uncertain customer behaviour [15,16] or financial threats [17]. The study in [13] discusses possible positive and negative impacts of flexibility from a physical and a cyber perspective. The work also mentions a number of threat scenarios in the context of flexibility, but the considered infrastructure is that of a more generic smart grid. In [18], the authors perform a security analysis of a grid using automated simulations and threat modelling. However, the focus is again on a generic smart grid and its load balancing architecture.

Research in [2] discusses the integration of cyber-physical systems in flexibility markets and systematically identifies a number of relevant physical and cyber threat scenarios for FMs together with possible security and monitoring requirements. Andrade et al. [19] explore data integrity attacks that can negatively impact the local energy markets and propose forecasting and trust models as preventive measures. The work in [20] focuses on FMs and points out that the interconnections and interrelations between power markets and local market participants are sophisticated, and emphasises the need for new solutions to reduce complexity and address novel threats to security and privacy. The paper uses blockchain technology to propose a joint privacy and cyber-physical security framework to improve resilience in local energy markets. In [21], the authors assess the severity of cyber risks specific to local electricity markets and show that denial-of-service attacks have the most significant impact on the market and the grid. The work also makes recommendations to mitigate the identified risks.

1.2. Contributions

This paper takes a step towards understanding and enhancing the security posture of FM systems. The first contribution of this paper is a reference architecture for a FM which differs from a generic smart grid. The proposed architecture is then instantiated in the next step to contribute with a threat modelling-based cyber-security assessment of the FM. To the best of our knowledge, no prior study makes similar contributions.

1.3. Structure

The rest of the paper is organised as follows: Section 2 introduces a reference FM architecture model. Section 3 describes the background on the method used in this paper. Section 4 provides details on the cyber-security analysis process. Next, in Section 5, a number of attack scenarios are explored, and potential attack vectors are revealed as part of the analysis. Finally, Section 6 provides a discussion on the results. Section 7 concludes the paper.

2. Reference Architecture Model for a Flexibility Market

For our task of cyber-security modelling, a detailed overview of data streams and sub-systems within a FM system is a prerequisite. A reference model captures what is typically found in different implementations of a particular architecture and saves modelling time [18]. In this work, we propose a reference model for a FM that covers the key elements that are consistently present across various implementations and variations we have studied in the literature. The model is validated through consultation with experts within the ERA-Net funded HONOR project [22]. The reference model provides the basis for the cyber-security modelling and assessment and is carefully designed to make it suitable for attack simulations. Figure 1 shows an overview of the reference architecture model (also available at [23]). The architecture consists of a number of data streams and zones, each occupied by actors playing an active role in the operation of a FM. A description of the model components can be found in Figure 2. In the following, a brief overview of a subset of zones and actors of the reference model is provided. For a detailed description of all remaining actors and zones, the interested reader is referred to the project report [24].

2.1. Small Flexibility Asset Owner (FAO)

The FAO consists of a Home LAN which facilitates communication among devices and systems within a home. Smart meters are connected to Home LAN and energy consumption recordings are transferred to the meter data company on a regular basis. Smart devices such as network printers and mobile computers are also connected to the Home LAN. Flexibility assets such as electric vehicles and heating pumps are connected to the Home LAN via the Home Energy Management System (HEMS). The HEMS is responsible for controlling the smart devices of the household and thus for following a flexibility schedule to provide flexibility according to a contractual agreement. The communication between the small FAO and the aggregator is conducted via an agent called FlexCom.

2.2. DSO SCADA Core Zone

The SCADA Core Zone is the central part of the architecture of the DSO. From the SCADA Core Zone operator, commands are distributed to the process equipment, such as the substations. The interaction of human operators with the SCADA system is conducted via the Human Machine Interface (HMI). Measurements, statuses, issued commands and other data are collected and stored in the Historian.

2.3. DSO Engineering Zone

Via the Element Manager of the Engineering Zone, the parameters of the remote terminal units (RTUs) and intelligent electronic devices (IEDs) are changed. Examples are the allocation of signals to input board channels. The Vendor File Transfer Server collects software and firmware updates. From the Engineering Zones, these updates are transferred to the SCADA Core Zone.

2.4. DSO Public DMZ and Office Zone

The public DMZ zone in the DSO is responsible for regular communication of the office with the public internet, e.g., via a mail server. In the office zone, tasks that are not directly related to power system operation are located, such as statistics and status information (e.g., outages). Staff (users) located in the office zone can access data from the replicated Historian and replicated SCADA server.

2.5. DSO Process Zone

The Process Zone is responsible for the communication between the SCADA Core Zone and the substations. By transferring data streams bidirectionally via the SCADA Front End, the Process Zone allows communication between the SCADA Core Zone and the Substations without a direct connection.

2.6. DSO SCADA DMZ Zone

The SCADA DMZ Zone is a network between the networks. It separates the Operational Technology (OT) or SCADA from less-trusted Information Technology (IT) networks, such as the Office Zone. Data from the SCADA Server and Historian are transferred to the replicated SCADA Server and replicated Historian, respectively, to allow the Office Zone access to the process data.

2.7. Aggregator Core Zone

The Aggregator Core Zone can be compared to the SCADA Core Zone of the DSO. Via the Core Zone the operator can enter commands and monitor the flexibility service activation via the HMI. The Aggregator Internal Database collects and stores process and contractual data such as flexibility asset measurements, control set points and market clearing results. The zone hosts service applications for the real-time operation and management of the flexibility portfolio.

Figure 1. Reference architecture model for a flexibility market.

Figure 1. Reference architecture model for a flexibility market.

Figure 2. Component description of the technical architecture.

Figure 2. Component description of the technical architecture.

3. Method

While there exist many approaches (e.g., consult penetration testers, conduct security auditing, etc.) to assess or estimate the cyber-security of large ICT infrastructures, they have certain limitations [18]. Threat modelling and attack simulations appear as promising approaches to undertake this task based on previous research [25]. Attack trees and graphs are key formalisms in the field of threat modelling. They were first elaborated in [26] over two decades ago, and further popularised by Schneier [27]. Later on, attack trees were formalised by Mauw and Oostdijk [28]. An important extension of attack trees was introduced by Kordy et al. [29] to also include defences as a means to enable the analysis of the effectiveness of various countermeasure strategies. Overall, a large body of work in the area up until 2014 is neatly summarised in [30]. A fairly large subgroup in the field works with probabilistic attacks graphs, often times using Bayesian networks as the underlying formalism for analysis [31,32,33,34].

Today’s cyber attacks are complex and usually multi-hop in nature. Various atomic attacks are carried out one after the other by the threat actors to reach the target/s. The attack graph logic creates such causal chains of attacks to simulate possible behaviours of the threat actors. The success of each attack may enable another possible attack that was not accessible earlier. There can be single or multiple prerequisites for any attack step and defence measures can be implemented to prevent threat actors from performing specific attacks. Moreover, performing an attack step assumes some effort from the attacker. The probability of success of every attack may differ depending on the difficulty of the attack. Time-to-Compromise (TTC) is one such metric that can be used to determine the difficulty of an attack step or a simulated attack path comprising multiple attack steps.

Generally, the challenge with using attack graphs for threat modelling is the cumbersome task of manually generating a new attack graph for each system. The work in this paper is based on the Meta Attack Language (MAL) [35] framework. MAL overcomes this challenge by defining domain-specific languages (DSLs) for different domains. Conceptually, a MAL specification file of a system consists of different assets (e.g., Host), attack steps on the assets (e.g., Host.Compromise), defences on assets (e.g., Host.AntiMalware), and finally, associations/relations between different assets. In particular, we use a language named coreLang [36,37]. Figure 3 presents the overall structure of coreLang. Assets in coreLang are grouped into six categories: Compute Resources, Vulnerability, Data Resources, User, IAM (Identity and Access Management), and Networking. These categories contain the assets that can be interconnected to each other to represent a system. For more details on coreLang, the interested reader is referred to [36,37].

As the goal in this work is to assess the security of a large and complex infrastructure, it is logical to employ a tool. Although a number of tools are commercially available for such a task [38,39,40], it was decided to use securiCAD for this work because securiCAD does not require elaborate manual configurations and is a result of extensive research [40,41]. Using securiCAD [40], it is possible to simulate the potential attack paths for the modelled infrastructure. Cyber-security expertise is built-in within securiCAD, i.e., the configuration values regarding attacks pre-exist. Such values were collected from various studies [42,43] and from public vulnerability databases, such as the US’s National Vulnerability Database (NVD). Therefore, security expertise is not expected from the users. Instead, users can model their system architecture using a DSL such as coreLang and generate attack graphs.

We transform the proposed reference architecture into models using coreLang [36,37] in securiCAD. Once the models are built, attack simulations are performed using a number of attack scenarios. Given an attacker’s starting point, the potential paths to different target assets are identified and combined into a critical path with the most traversed steps and edges. The analysis is based on a shortest path calculation using Dijkstra’s algorithm. The resulting attack paths from the simulations enable assessment of the security posture of the FM by providing valuable information on the paths attackers can take from the initial compromise to reaching different target assets and how easy it is for them to succeed with the attacks. This allows for identification of weakest points in the architecture to help enhance the cyber-resilience of the flexibility market system.

4. Cyber-Security Assessment

This section provides details of the cyber-security assessment. The assessment consists of a comprehensive analysis covering most elements of the reference model. The focus of the analysis is on actors and data streams that are crucial and most relevant for the operation of a FM. The depicted scenarios are chosen carefully in order to form a good representation of the architecture’s overall security status.

4.1. Model Building

The reference architecture provides a base and needs to be complemented at modelling time for a more accurate assessment. For instance, it does not address IAM. A FM involves different users, and they need to be represented with dedicated user accounts in the model to accurately measure their impact. Similarly, defensive controls are not represented, except for security gateways. The modelled assets were protected with defences. Further additions include introduction of software vulnerabilities and hardware vulnerabilities to the hardware.

The model is built in securiCAD and consists of 26 views, where each view of the model represents an actor in the reference architecture shown in Figure 1. Views are a way to organise the model so that related objects are presented together. However, all objects are part of the main model, which means that their mutual impact, if any, is taken into account. These views are connected to each other using common assets, such as networks. Overall, the model consists of a total of 303 assets and 367 associations between these assets. For practical reasons, we show only a single view of the model in the paper (see Figure 4). The remaining model views are publicly available at [23].

4.2. Analysis

One of the advantages of an automated evaluation is the ability to explore different variations in the model. In terms of cyber-security, two kinds of variations are of particular interest and value. First, the placement of certain security mechanisms and secondly, their configuration to measure how well they perform. Well-configured security controls make the architecture more secure by increasing the time to compromise for the attacker or even eliminating potential attack paths altogether. The analysis aims to investigate the optimal security controls needed to protect the architecture from the attacks explored in the discussed scenarios. For each scenario in this analysis, we consider two configuration variations. As most of the assets in coreLang have defence mechanisms that are configurable, the following configuration variants are considered.

• A default and less secure configuration where defences are disabled.
• A more secure configuration where relevant asset defences are switched on.

The hypothesis behind (1) is to show the attack possibilities and the relevant attack paths. Then, in (2), for each scenario, we identify and configure relevant defences in order to show the most effective defensive controls to protect against the attacks.

4.3. Attack Scenarios and Scope

The analysis is performed based on a number of attack scenarios, i.e., by defining attacker starting positions and assets with high value (e.g., a network) to protect. This allows for the calculation of the possible attack paths. For this work, the focus is on scenarios where an attacker tries to impact the normal operation of a flexibility market (offers, activation signals, etc.) and thus the analysis mainly focuses on the attack scenarios identified in [2]. The following attacker starting positions are examined: at the smart meter (SM) in FAOs, on the Internet, and at the vendor. Additionally, the following attacker targets are considered: SM application, core Zone LAN in aggregator, SCADA core Zone LAN, and the RTUs in substations.

These attacker starting points and target assets form the scope of this analysis. Clearly, there are many other potential attacker starting points and target assets, but we believe the mentioned scenarios are good representatives of the architecture’s cyber-security status. The three attacker positions in combination with four different target assets result in a total of twelve attack scenarios.

Table 1. Table of explored attack scenarios in the analysis.

Scenario	Attacker Start	Target
1	At the SM in FAOs	SM application
2	At the SM in FAOs	Core zone LAN in aggregator
3	At the SM in FAOs	SCADA core zone LAN
4	At the SM in FAOs	RTUs in substations
5	On the Internet	SM application
6	On the Internet	Core zone LAN in aggregator
7	On the Internet	SCADA core Zone LAN
8	On the Internet	RTUs in substations
9	At the vendor	SM application
10	At the vendor	Core zone LAN in aggregator
11	At the vendor	SCADA Core zone LAN
12	At the vendor	RTUs in substations

summarises the explored scenarios. The results of the security evaluation using securiCAD come in terms of a reachability map from the attacker’s starting point and to the targets (i.e., all attack steps that are defined for each single entity present in the model). A simulation may show multiple attack paths that lead to the activation of an attack step, i.e., the main attack path, but also alternative paths that take a longer time to achieve but can still yield a similar end result. It is not feasible to show attack paths for all simulated scenarios in the paper. Thus, only a subset of representative attack paths are discussed, and the remaining attack paths are publicly accessible at the project repository [23].

5. Results

This section presents a selection of explored threat scenarios and attack simulation results as per the scope defined earlier.

5.1. Attacker at the SM in FAOs

Figure 4 depicts the model showing the view for an FAO actor. As SMs are part of customer premises and the less-protected FAOs, it is possible for an attacker to use them as a starting point to launch their attacks. In the following, we consider different scenarios that can result from an attacker connecting physically to SMs in FAO.

• Scenario 1: Full Access on SM Application

This scenario explores what can happen if an attacker enters the system by accessing hardware of the SM in FAOs. The target asset for the attacker in this scenario is the SM application and the contained sensitive data, such as consumption, credentials (including keying material), and firmware information. First, we run attack simulations of the model for configuration (1). Figure 5 shows the resulting attack path. As shown, once the attacker gains physical access to the SM hardware, the attacker can gain local connect to the SM application and then exploit a vulnerability in the application to modify it and gain full access on the SM application. If the attacker is able to gain full access on the SM application, it can read/write any associated data, e.g., read the SM credentials file. The attacker can further use these credentials to assume the identity of the home owner user and send wrong consumption data. In terms of FM, the impact of such an attack is that the asset owner could be fined for not fulfilling flexibility agreements and eventually be removed from the portfolio [2]. Moreover, SMs deployed by a DSO often share the same vulnerabilities (e.g., a static encryption key [11]). Thus, if an attacker can control one SM, they can control multiple SMs, which may result in power outages for many customers and high social and financial costs.

Now that the attack possibility and the probable attack path are shown, we focus on how to defend against this attack. The most obvious solution in this case is to protect the SM application from being exploited. It could be ensured that no vulnerabilities exist in the SM software (which is hard), or alternatively, we could protect the SM application with an IDPS asset. The IDPS asset can be seen as a host-IDS that acts like an antivirus or antimalware to protect the SM application and thus denies any possibility of a vulnerability being exploited. To test this security control, we simulate the scenario again with the newly added IDPS protecting the SM application. The resulting attack path (available at [23]) shows that although we are able to prevent the attacker from exploiting a software vulnerability, interestingly, the attacker is still able to gain full access on the SM application through an alternative attack path. An attacker can, instead, use a hardware vulnerability to gain full access on SM hardware and then its application. This implies that to be able to stop an attacker gaining full access on an SM application, it is not enough to protect just the application, but we will also need to protect the meter hardware. This can be achieved by turning the hardware asset defence named HardwareModificationProtection on. Simulation results for this case show no possibility for the attacker to gain full access on the SM application.

• Scenario 2: Man in the Middle on Core Zone LAN in Aggregator

An attacker connected on an SM can also attempt to reach and access the LAN in the Aggregator Core Zone. The attack path in Figure 6 shows that after gaining full access on the SM application, the attacker can reach the Internet by using the allowed connections (connection rules), and forwarding from one network to another. From the Internet, the attacker again uses network forwarding and allowed connection rules to enter the aggregator and reach Head END LAN and eventually the Core Zone LAN to launch the attack. An attacker who has access to this network can tamper or disrupt flexibility activation signals, or even disrupt or manipulate the flexibility measurements [2]. One way is through the modification of flexibility portfolio recordings to disrupt the service verification process. The consequence for the aggregator for this attack could be milder in terms of fines for not fulfilling contractual agreements. In severe cases, wrong flexibility activations may trigger grid protection, resulting in disconnection of customers and thus high social costs.

This attack path can be stopped by protecting the security gateways (connection rules, routing firewalls) and the networks. If the attacker can not forward from one network to another and all networks impose strict access control, then this attack path can be stopped as per simulations. However, the attacker will then instead have to rely on finding and exploiting vulnerabilities in the routing firewalls. The possible protection against this is discussed later.

• Scenario 3: Denial of Service (DoS) on SCADA Core Zone LAN

There is a possibility for an attacker connected at the SM in FAO to reach the SCADA Core Zone LAN through the Internet and launch attacks. As shown in Figure 7 (from the point where the attacker already has full access on the SM application), once the attacker reaches the Internet, the attacker can make use of a vulnerability in the security gateway in the Engineering Zone of the DSO to enable access to the Engineering LAN. As the Engineering LAN is typically allowed to connect to the SCADA Core LAN, the attacker can reach and access the SCADA Core LAN to launch a DoS attack on the network or even target the SCADA server or Historian which stores the historical data. The consequence of an attack on the SCADA server can be devastating and impact millions of people. The historical data provide necessary information for flexibility planning, activation, and verification and are typically not checked for integrity after being stored. Thus, if an attacker manages to impact the integrity of these data, all models based on the compromised data will be badly affected. This may also result in financial penalties due to imprecise flexibility planning and verification. In severe cases, power system monitoring techniques may fail, leaving critical grid conditions unresolved [2].

The most suitable place to defend against this attack is to strengthen the security gateway between the Internet and the Engineering LAN. If the attacker cannot exploit a vulnerability in the routing firewall, then it can not enter the Engineering LAN even if it is present on the Internet. With the routing firewall properly protected, the attacker has to find alternate ways to reach the Engineering LAN and the current attack path will be thwarted. At the same time, both the Engineering LAN and the SCADA Core LAN should have all three network asset defences (NetworkAccessControl, EavesDropDefense, ManInThe MiddleDefense) turned on for additional security. We simulate again to test the scenario with the Remove defence of the software vulnerability associated with the routing firewall turned on along with the above-mentioned network defences. The resulting attack path in Figure 8 shows that the attacker now takes an alternative path to reach the Engineering Zone through the SCADA DMZ Zone. Similar to the earlier case, the attacker uses the vulnerabilities in the routing firewall to gain access. This emphasises the importance of securing all possible entry points instead of just focusing on the obvious and most likely.

• Scenario 4: Deny RTUs in substations

For an attacker connected at the SM in FAO, it is also possible to reach the RTUs in either of the substations and deny their normal operation. There are two possible attack paths for this attack as per the simulations. The first attacker path shown in Figure 9 shows that when the attacker has already gained full access on the SM application, it can access and connect to the PL-C/LoRaWAN from the Home LAN using network forwarding and then exploit vulnerabilities in the kWh Meter to be able to reach and connect to the Energy Supplier Network. As the energy supplier uses a GPRS/LTE/Powerline network towards the Process LAN, this opens up the DSO network to the attacker. Once inside the DSO, the attacker can reach the substations from the Process LAN and be able to exploit vulnerabilities in the RTU to perform the attack. This attack path is made possible because the Process Zone hosts the front end, which acts as a relay between the operators in the SCADA Core Zone and the equipment in the substations. The consequence of this attack can be a blackout, which is nothing short of a disaster, depending on how long it takes for the grid operator to identify and rectify the problem.

Alternatively, the attacker can also reach the RTUs through the Internet. This path is similar to the previous scenario where once the attacker gets access to the Internet from an SM, the attacker can enter the SCADA DMZ LAN through accessing the connected networks and make its way to the Process LAN. Then, the attacker can reach the substations from the Process LAN and be able to exploit vulnerabilities in the RTU to perform the attack.

For both attack paths, there are multiple possible defences to stop them. First, it is crucial to stop the attacker at the perimeter of the DSO, so the associated connection rules should have their defence PayloadInspection turned on. Similarly, all the networks should be using all three possible defences available on the network asset, as well as only allow forwarding for legitimate traffic. Finally, the RTUs themselves should use defences both on the hardware and software level (just like SMs) to be able to protect themselves for the case when the attacker already has remote access to the substations. The simulation results with the above-mentioned defences indeed show that the mentioned attack paths to the RTUs in substations are not possible any more.

5.2. Attacker on the Internet

The Internet, being a public network, allows anyone to connect to it from across the globe and pose a threat. In the following, we consider scenarios where a threat actor is present on the Internet.

• Scenario 5: Full Access on SM Application

An attacker connected to the Internet can access and compromise an SM application. There are two possible attack paths for this attack. First, the attacker can use the allowed connections rules of the security gateway to forward itself from the Internet to the Home LAN, as shown in Figure 10. This happens if the traffic is not inspected and filtered to detect and stop malicious communications and only allow legitimate communication. Without any payload inspection, the attacker can then easily access all associated networks without any restriction. Once on the Home LAN, the attacker can exploit a vulnerability in the SM application and gain full access to it.

In the second possible attack path (available at [23]), the attacker can attempt to exploit a vulnerability in the routing firewall managing the connection rule between the Internet and the Home LAN to gain full access on it and modify it to gain access to the Home LAN. Once on the HOME LAN, the attacker can then exploit a software vulnerability in the SM application and gain full control over the SM.

These attack paths can be protected against using trivial defences. First, the affected routing firewalls and the SM applications can be protected by an IDPS. Secondly, the security gateways (connection rules) have PayloadInspection defences that should be turned on to perform traffic inspection and detect and block malicious traffic. As mentioned before, the IDPS asset associated with systems can be seen as a host-IDS and the PayloadInspection parameter on connection rules can be seen as a network-IDS. This is especially crucial for the traffic coming in from the Internet. The simulations with the above recommended defences showed that the above shown attack paths are not possible any more, but the attacker is still able to reach the SM from an alternate path (Internet → SCADA DMZ LAN → Engineering LAN → Process LAN → GPRS, LTE, PowerLine Network → Energy Supplier Network → PL-C/LoRaWAN → Home LAN). Although, it is unlikely that an attacker will take this attack path to reach an SM, this further signifies the importance of protecting all possible entry points and systems rather than focusing on the most obvious ones. Thus, to completely stop an attacker on the Internet from reaching the SM application, all security gateways need to be properly configured to inspect traffic. Similarly, the intermediary networks and the target assets need to have their appropriate defensive controls properly configured and enabled.

• Scenario 6: Man in the Middle on Core Zone LAN in Aggregator

An attacker on the Internet can easily attempt and reach the LAN in the Aggregator Core Zone. The attack path is similar to earlier described scenarios, where the attacker uses the lack of inspection by the security gateway to go from one network to another and eventually reach its target asset and perform the man in the middle attack. The possible defences to thwart this attack path are enabling payload inspection, protecting intermediary networks using their defences, and protecting the targeted assets.

• Scenario 7: DoS on SCADA Core Zone LAN

For this scenario, the expected attack paths of an attacker breaching the security through exploiting vulnerabilities in the security gateways or making use of the lack of payload inspection to use network forwarding to reach the targets still apply. However, it can be assumed that DSOs are more security savvy and those attack paths are less likely to happen in reality. Therefore, in the interest of keeping the analysis interesting, we focus on a different variation of possible attacks, ones that involve the human factor.

Let us assume that there is an attacker on the Internet that targets social engineering attacks on a user in the Office Zone of the DSO actor. Figure 11 shows the resulting attack path when an attacker targets a user of Office Apps. The attacker attempts a social engineering attack and either successfully assumes the identity of the user to exploit the associated privileges and authenticate the office application and gain specific access, or relies on tricking the user with some probability into taking some unsafe action and exposing the office application to be able to gain specific access to it. Gaining specific access means the attacker is able to gain low-privilege access on the application, which enables it to access the networks and connections associated with it. Once the attacker can access the connected networks, it can move to the DSO Office Zone LAN. Further lateral movement, thanks to the lack of payload inspection between networks, allows the attacker to reach the SCADA DMZ LAN and then the Engineering LAN. From the Engineering LAN, the attacker can reach and access the SCADA Core Zone and its LAN to launch the attack. The Engineering zone is allowed to send data to the SCADA Zone because it hosts services such as a vendor file transfer server that relies on collecting software and firmware updates from the Internet and transferring them to the SCADA Core Zone.

The above-mentioned attack path is reminiscent of real-world attacks, such as the hack of Ukraine’s power grid in 2015. According to experts [44], the attack on the power grid also began with a spear-phishing campaign targeting staff of multiple electricity distribution companies. Attackers sent emails with malicious Microsoft Word documents that when opened infected their machines and opened a backdoor for the hackers. This allowed the attackers access to the corporate networks. Once inside the corporate networks, the attackers gained access to the Windows Domain Controllers to gain access to the VPN credentials used to remotely log in to the SCADA network and perform further exploitation. Another alternative would have been to exploit vulnerabilities in the segregating firewalls or find alternative ways. This way, the attackers were able to social engineer their way into the SCADA network.

Attacks exploiting users are hard to defend against in general. Possible defences against this kind of attack include the SecurityAwareness defence of the user asset. The security awareness of the user makes it less likely that social engineering would be successful and reduces the likelihood that the user will engage in unsafe behaviour. If we assume that the user is fully security aware, then the attacker is not able to perform this attack and the attack path is not possible any more. The earlier discussed defences for protecting the different assets leading to the target asset also apply here.

• Scenario 8: Deny RTU in substations

The first possible attack path to this scenario resembles the attack path discussed earlier in Scenario 4. Although the attacker was connected on the SM then, it still used the Internet to approach the DSO and launch the attack. Instead of showing the same, we explore other possible ways for this attack to happen. An attacker can instead use and exploit a human error or lack of security awareness to launch this attack. The attack path (available at [23]) has a likeness to the last scenario, except that once the attacker gains access to the Engineering Zone, it moves to the Process Zone and gains access on the Process LAN. From the process LAN, the attacker can connect to the intermediary network between substations and the process LAN and gain a foothold in a substation. If an RTU is vulnerable, it will then be exploited. As mentioned before, this kind of attack can be prevented with a security-aware user and enabling earlier mentioned defences for all networks and targeted assets.

5.3. Attacker at the Vendor

Actors in a FM depend on services and equipment provided by external partners such as vendors. Traditionally, there exists an inherent trust between the vendors and the consumers, which has increasingly been violated in the recent past. A real-world example of the severity of such a threat comes from the recent SolarWinds hack [45]. In a typical attack, at any point in the supply chain, an attacker installs malicious code in the provided hardware or software that is eventually used by a consumer. The attack is very critical as multiple actors of a FM might be using the same equipment from the same vendor.

• Scenario 9: Full Access on SM Application

First, we show the possibility for an attacker to attempt a hardware supply chain attack on the SM. The attack path in Figure 12 shows that an attacker can attempt a supply chain attack on the SM hardware to gain full access on the SM hardware and the application.

Once the attacker has full access on the SM application, it is trivial for it to access the connected network. The attacker is able to access the HOME LAN network and perform man in the middle attacks on the network, allowing the ability to read and write all associated data. This enables the attacker to disrupt the operation of a FM in multiple ways, as detailed earlier. Figure 13 shows the attack path.

Hardware supply chain attacks are generally hard to protect against. One possible defence against these attacks is to perform SupplyChainAuditing on the hardware asset. In reality, this defence translates to testing newly acquired software and equipment in a sand-boxed fashion and inspect their behaviour prior to installing them into production. Even with the defence in place, it is still possible for an attacker to bypass the auditing process (attack path available at [23]). However, the probability of the original attack reduces significantly with the defence in place. In the upcoming scenarios, we will discuss more possible defences against these kinds of attacks.

• Scenario 10: Man in the Middle on Core Zone LAN in Aggregator

Using a hardware supply chain attack on the SM hardware, an attacker can also target the Core Zone LAN in the Aggregator. The attack path for this attack is fairly straightforward. Once the attacker has full access on the SM, it can reach the Home LAN as discussed earlier. From the Home LAN, the attacker can access the Internet which is connected to the Head End LAN in the Aggregator, which, in turn, is connected to the Operational Planning LAN and the Core Zone LAN. Once the attacker can access the Core Zone LAN, it can launch the attack. The possible defences for this attack path are also the same as discussed before.

• Scenario 11: DoS on SCADA Core Zone LAN

For this scenario, we explore the possibility of a software supply chain attack. The Engineering Zone of the DSO relies on a vendor (just like other actors in the FM) for software and hardware updates. As for all views, the securiCAD model view for the DSO engineering zone is available at [23]. We assume that the Office Station connected to the Engineering LAN takes its updates from a vendor. To be specific, the Office Station takes updates/software packages from a vendor-controlled software repository through the SoftwareProduct asset. If an attacker connects to the vendor system and gains full access, it can access and modify the data in the software repository and the SoftwareProduct used by the targeted application. This way, the attacker is able to compromise the Office Station application to gain full access on it. Since the application is directly connected on the Engineering LAN, which has direct access to the SCADA Core LAN, the attacker can reach and target the SCADA Core Zone with a DoS attack. The full attack path is shown in Figure 14.

The first possible defence against this attack is the SupplyChainAuditing defence of the Office Station asset. However, the attacker can still with a small probability achieve its goal by bypassing the auditing defence. This is because the defence itself is not viewed as perfect. To further make the job of the attacker difficult, we explore another possible security control to this attack. The model has an asset named Vendor Certificate connected to the SW repository asset. The idea is that the vendor can use this certificate to sign all software releases that are stored in the repository. If an attacker attempts to modify the stored software, this will then become detectable by the Office Station and the compromised updates/software is not installed. This shall completely thwart the shown attack path. Of course, the attacker can then target the certificate used by the vendor to sign, but the difficulty is significantly increased.

• Scenario 12: Deny RTU in substations

The last scenario in our considered scope is the possibility for an attacker at the vendor to target the RTUs in the substations. To show the attack possibilities, we again employ software supply chain attacks in the Engineering Zone of the DSO. The reason the Engineering Zone is chosen to show this attack possibility is because it hosts a number of critical systems. The Vendor File Transfer Server collects software and firmware updates from a vendor over the Internet. These updates are then transferred to the RTUs and the SCADA Core Zone. Assuming that an attacker can modify the vendor supplied RTU software update data, the attacker can perform a software supply chain attack to gain full access on all RTUs using the same RTU SW Updates product. The attack path is shown in Figure 15.

The possible defences against this attack include enabling supply chain auditing on all relevant application assets. This will reduce the attack possibility to only bypasses, assuming that the auditing is not fully effective. As a next step, the vendor should also use a certificate to sign the RTU software update releases. This allows the consumer of the updates to establish if the update is compromised and prevent the attack from happening.

6. Discussion

The presented analysis serves as a mechanism to identify weaknesses and potential sources of threats in FM systems. Our analysis shows that the attacker can reach their target assets in most of the considered scenarios. This is especially interesting to see in the scenarios involving the DSO, where the attacker is able to follow the allowed data flows and traffic directions to go from one zone to another and succeed with the attacks. OT networks such as SCADA were once isolated from other networks and physical access of the system was needed to realise an attack. With time, even these networks became connected to the Internet and thus physical access is no longer necessary for an attacker. This development also exposes these systems to both OT and traditional IT attacks. On a positive note, the analysis indicates that with properly configured defences in place on the assets, it is possible to make the attacker’s task difficult, and in some scenarios, entirely stop the attack paths.

Considering all simulated scenarios, it is clear that the biggest area of concern is an attacker originating on the Internet. In most scenarios, the attacker used access to the Internet to reach different areas in the architecture, i.e., the majority of the scenarios with the attacker starting on the Internet were quite similar to the scenarios where the attacker starts on the SM because the attacker anyway moves from the SM to the Internet. Interestingly, it is also much easier for an attacker to exist on the Internet compared to SMs and vendors. Another important outcome from the analysis is that protecting the most common entry points into the system is insufficient. The attacker can, and will, find alternate paths to reach its target, and it is thus imperative to monitor and protect all possible entry points.

The attack scenarios and security controls identified in the analysis provide valuable insights into developing an effective strategy to secure FMs. Clearly, all networks should be segregated from each other by using, e.g., security gateways, just like the way it is done in the analysed FM reference architecture. Moreover, the number of entry points from the outside should be limited. As remote access to critical infrastructure such as substations is crucial both as a function and for security, a virtual private network (VPN) can be employed as an effective remote access solution. However, strict access control policy based on multifactor authentication should be used for authentication. Based on the results from the simulations, we recommend a multi-layered approach to securing FMs. Starting with the perimeter, the security gateways need to be properly configured and protected. There should be payload inspection for all traffic using some kind of network-based IDPS and the assets themselves should be kept free from vulnerabilities using frequent patching and host-IDS. Then, all the networks need to employ defences such as for eavesdrop, man in the middle, and network access control protections, such as firewalls. Data should be encrypted to avoid eavesdropping. Assets should also follow the state-of-the-art end-point hardware and software security regulations and practices to protect against unauthorized modifications and to continuously patch software vulnerabilities. Finally, it is important to increase security awareness among employees.

As future work, it could be interesting to investigate the effectiveness of different protection scenarios using additional attack scenarios and identify the ideal placements for different defensive measures and tools. Estimation of the overall risk of FM depending on the simulated threat models and the TTC values will be another interesting area for future research. It could also be interesting to develop the reference model further and consider assets such as distribution-side phasor measurement units (PMUs) [46,47] as part of the assessment.

7. Conclusions

The security of flexibility markets is of paramount importance, yet it remains an understudied topic. This work presents a cyber-security analysis of a flexibility market system. The analysis is based on threat modelling where a reference architecture is proposed and transformed into models and attack simulations are performed. Analysis results show the different paths attackers can take to enter the system and reach their targets. The main results from the work include the identification of high-risk areas, such as the Internet links between market actors, and the resulting attack vectors. Additionally, vulnerabilities in software running on smart devices and other assets were found to be particularly susceptible to exploitation. To mitigate the identified risks, the paper proposes and evaluates multiple protection mechanisms, including intrusion detection systems, firewalls, antivirus solutions, hardware hardening, supply chain auditing, and security awareness training. The work highlights the importance of securing the critical infrastructure and physical systems in flexibility markets, particularly with the increasing use of public networks such as the Internet.