The number of attacks using vulnerabilities in the network is increasing rapidly every year, and attacks using vulnerabilities in the network are mainly used. In addition, CVSS scores, which are mainly used to detect such attacks, have a problem in that they do not reflect the specialized parts of each security environment, because they are a universal evaluation method. Therefore, in this paper, we propose a method that can determine the risk of attacks utilizing network vulnerabilities on nodes and edges, and we calculate them comprehensively to calculate the risk of each attack route and accordingly select the priority. The CVSS score, attack type, and vulnerability association analysis were applied to calculate the risk of nodes, edges, and attack routes. CVSS only used access location and CIA scores, and the impacts of the attacks were determined through attack types that occurred during the year collected in advance. In addition, the effect of vulnerabilities between nodes connected to each other through experts was judged and analyzed. Experiments were conducted through a self-generated network to verify the proposed method.

In this method, an attack graph was created, and an optimized route was then created by analyzing the associations and vulnerabilities between nodes and edges based on various points of information present in the nodes and edges included in the generated graph. The vulnerability of each node was analyzed using CVSS, and the relationship between nodes was analyzed to calculate the edge value. This allowed for the risk of nodes and edges to be measured and identified the most vulnerable attack route. The contributions obtained through the proposed method in this study are as follows.

The rest of the paper is organized as follows. In Section 2, we provide related work. In Section 3, we present the VCAG-SS that evaluates nodes and edges to calculate the risk of the attack route. In Section 4, we experimentally verify the proposed method. Finally, Section 5 draws conclusions and discusses future work.

#### **2. Related Works**

As shown in Section 1, attackers use various vulnerabilities present in the network to perform attacks. To defend against such attacks, we need to know what vulnerabilities exist on each node in the network and what routes can be created by them, and we typically use attack graphs to identify them. CVSS is used for assessments of attack possibility or risk on these routes.

#### *2.1. Attack Graph*

An attack graph is used in various fields, such as attack detection, identification, and defense. In the security field, it helps establish an effective defense system by identifying the intention, attack range, and vulnerability, and providing this information to the defender. It also creates attack scenarios that extract possible routes that attackers can use to break into target networks, which are then used to predict and block future attacks. This approach creates an attack graph for the target, and it conducts attack simulation and attack optimal route analysis. This approach makes it possible to understand what components the network has, and the related cyber assets and problems (damage, situation, etc.) that occur when each asset is attacked.

When carrying out an attack on a target, the attack graph provides priority to decision makers, thus enabling quick and accurate decision-making. By evaluating the attack graph-based target attack method, it provides the decision-maker with the expected effect according to the attack route and the future occurrence situation. Related technologies include Multihost, multistage Vulnerability Analysis (MulVAL), NETSPA, Dijkstra, and Floyd. Jha et al. [4] proposed a method for determining the possibility of an attack through an attack graph to which minimum hitting and greedy algorithm could be applied, so that the minimum security measures to ensure the safety of the network could be determined. Jajodia et al. [5] described a tool that implemented an integrated topology approach to network vulnerability analysis. Then, an attack graph was created to analyze the network security conditions of the Topological Vulnerability Analysis (TVA) tool, Exploit, Nessus vulnerability scanner, and attack route analysis leading to a specific attack target, and the vulnerabilities for each network were analyzed. Ingols et al. [6] proposed a method for analyzing multiple prerequisite graph-based attacks that linearly expanded as the size of the network increased. Ammann et al. [7] proposed a more concise and expandable method with which to solve the expandability and complexity problems that occurred in the existing attack graph generation method. Thus, an attack graph was created and applied to a large network to identify useful information. Wang et al. [8] proposed an attack graph-based automation method that strengthened the network in preparation for intrusions performed in multiple stages, and unlike previous methods, it minimized the cost with satisfactory conditions at the beginning. Sheyner et al. [9] defined the attack model and attack graph in network security, proposed a method for accordingly generating and visualizing the attack graph, and built an attack graph tool to automatically generate the attack graph. This was visually shown to the user, so that vulnerability analysis could be easily performed. Yoon et al. [12] proposed an attack graph-based moving target defense (MTD) technique that used software-defined networking (SDN) to change the host network configuration according to the host importance, and they built a hierarchical attack graph model that provided network topology and network vulnerabilities that could be used to make MTD shuffling decisions. Gonda et al. [13] proposed a method of inferring the importance of vulnerabilities in a LAG or connection graph analysis and relaxed planning graph using node centrality measurement. Thus, the number of meaningless attack vectors was quickly reduced, and the vulnerabilities of each node were properly reflected. In

Lu et al. [14], a graph neural network (GNN)-based attack graph ranking method was proposed, and the optimal route of the attack graph was measured through the suitability analysis of the GNN.

#### *2.2. Common Vulnerability Scoring System*

Starting with the Internet worm in November 1988, there has been increasing demand for computer accident response over time, and many accident response teams have provided their own security incident results, but the vulnerability analysis standards were different from one another, thus resulting in the problem that the standards for vulnerabilities became unclear. To solve this problem, the CVSS method was proposed.

CVSS is an open-source-based framework that can calculate vulnerability risk, and it performs risk assessment using items such as access route, complexity, authentication, confidentiality, integrity, availability, etc. The National Institute of Standards and Technology's National Vulnerability Database (NVD) also provides relevant information. This has the advantage of providing a standard for measuring the vulnerability score, providing an open framework for evaluating the vulnerability score, and prioritizing and supporting vulnerabilities through vulnerability score evaluation. CVSS upgrades vulnerability evaluation items through continuous updates; in this method, three types of matrix information (base, temporal, and environmental) are calculated, and these are used to calculate a vulnerability value. This method is also useful for using the network vulnerability level or detailed values (CIA, access vector, complexity, authentication, etc.) as they are. A recent study improved the CVSS and suggested a more suitable formula for each network.

Yang et al. [15] proposed a DBRank algorithm that calculated the vulnerability of a node by considering the gain and spread of the vulnerability according to the attacker's characteristics. Spanos et al. [16] proposed the Weighted Impact Vulnerability Scoring System (WIVSS) with improved CVSS, and in their method, the CIA weight was modified from the existing base matrix. They proposed new rule about CIA. For example, the weights were defined higher in the order of confidentiality, integrity, and availability, partial value was multiplied by 0.5 of complete value, and impact score range was defined from 0 to 7. Based on these rules, new confidence, integrity, availability values were proposed. In CVSS 2.0, when the CIA value were 'None', 'partial', and 'complete', their weights defined 0.0, 0.275, 0.660. And the weights in confidence, integrity, availability were all the same. But in this method, confidence was 0.0, 1.5, 3.0, integrity was 0.0, 1.2, 2.4 and availability was 0.1, 0.8, 1.6. Through this, more detailed vulnerability risk scores could be obtained.

Jacobs et al. [17] proposed a system for predicting exploits using the information provided by NVD's CVSS and MITER's Common Vulnerabilities and Exposures (CVE), along with other information. The features used in that study were selected through three steps. First, all the available information was extracted from the collected data set, and then information having a share of less than 1% in the entire vulnerability database was removed. Then, meaningless information was removed through expert opinion. Gallon et al. [18] applied CVSS to the attack graph to increase accuracy. The CVE identifier and the base, temporal, and environmental scores of CVSS were used. As such, rather than applying the existing CVSS as is, it was necessary to improve CVSS, and apply a method suitable for each network or attack graph. Gencer et al. [19] proposed a method for determining a fuzzy-based vulnerability score using CVSS score. To define the relationship between the exact inputs and fuzzy multiple outputs, they used a fuzzy logistic regression (FLR). They also used the least squares method to estimate the parameters of the presented model. Ref. [20] proposed a system utilizing a Markov chain and CVSS that identified and evaluated vulnerabilities that occur frequently on the Internet of Medical Things (IoMT). They analyzed representative vulnerabilities and weaknesses from IoMT, and they measured scores by defining CVSS information according to the IoMT network. Moreover, the probability for IoMT threats was calculated based on the Markov transition probability matrix. Ref. [21] proposed a security system for detecting vulnerabilities that exist in the government's website. They used vulnerability scanners to analyze vulnerabilities that

existed on websites and measured CVSS scores for vulnerabilities. Through this method, they were able to identify what risks existed on the website and accordingly propose recommendations. Ref. [22] proposed a method to reduce the CVSS matrix by using a decision tree (DT) and reduce the error of the resulting score. A group of 15 experts calculated a vulnerability assessment using the basic CVSS matrix and found that most vulnerabilities scored differently. Therefore, to reduce these errors, basic CVSS metrics were classified, and overlapping parts were removed through a correlation analysis between metrics. In addition, the score was calculated by constructing an attribute subset through a DT-based attribute selection. Ref. [23] proposed a method of detecting vulnerabilities and determining priorities by analyzing the variables and the characteristics of the network environment. Various information was collected through open-source intelligence (OSINT), defined as global, IP, and vulnerability variables, and the risk was calculated using the CVSS based on the variables.

#### *2.3. Vulnerability Correlation*

Most vulnerability research has focused on vulnerability classification and the vulnerability analysis of security assets. However, by applying the attack graph to the network and comparing the vulnerabilities of each node, it has been confirmed that they are affected by the vulnerabilities of other nodes, rather than independent vulnerabilities [24]. This correlation is mainly expressed as a matrix, and refs. [25–28] also studied how to advance this matrix. For example, in a specific network, if an attacker gains access by exploiting the vulnerability of one node, then in this state, the attacker continues to perform additional attacks using other weaknesses to reach the desired target node. This method shows that there is a correlation between vulnerabilities, and it can be confirmed that vulnerabilities are used as a precondition for attacking other vulnerability. Therefore, it is possible to obtain an optimized attack route or pattern in a vast network by analyzing and understanding the correlations between vulnerabilities.

Li et al. [24] performed a network security analysis by creating a matrix showing CVE correlation information between two nodes. At that time, a vulnerability analysis graph (VCG) was defined to identify the vulnerability correlation, and the correlation was defined as one metric based on the precondition between the CVEs of the two nodes. Liang et al. [29] proposed a method with which to evaluate a network security risk using VCG. They generated VCG, and the node in the graph included the attacked node IP, the name of the vulnerability, the permission obtained through the attack, and the security state at the edge. Nan et al. [30] performed a vulnerability correlation analysis for a network situation analysis while using a correlation coefficient. Further, Debnath et al. [31] proposed a CVSS-based vulnerability and risk assessment (HPCvul) to analyze and evaluate vulnerabilities in high-performance computing (HPC) networks. Standardization was performed to enable smooth sharing of data, and the possibility of an attack using vulnerabilities was identified using an attack graph. Static and dynamic risk assessments were conducted; the static risk assessments were used to explore known vulnerabilities in the network and evaluate the relationship between vulnerabilities to derive the possibility of successful exploitation, while the dynamic risk assessment was used to perform a real-time risk analysis.

Previous research has applied methods such as redefining CVSS scores for each environment [20,21,23], collecting additional information for risk assessment [15,17,23], applying CVSS weights [16,18], and combining them with other algorithms [19,22,28–30], and an improved CVSS-based risk calculation method has accordingly been proposed. However, these methods are based on existing CVSS mechanisms, so they only evaluate the risk by calculating the scores of each vulnerability while not considering possible associations that could arise from vulnerabilities (PC, servers, users, etc.) in the network. Further, even in the case of analyzing the correlation, a graph-based analysis using VCG was the main focus. Therefore, this paper proposes a simple yet effective relationship analysis method between vulnerabilities to solve the previous research problem of only

calculating individual vulnerability scores, and a method for calculating the risk of attack route as well as vulnerability scores.

#### **3. Vulnerability Correlation and Attack Graph-Based Node-Edge Scoring System**

In this paper, we propose VCAG-SS, a node-edge vulnerability correlation analysis method for attack graph-based optimized attack route detection. The nodes PCs, servers, users, and the like are included in the network, and node information includes IP, access location, and CVE information. Further, the edge refers to the relationship between the vulnerabilities of the nodes. For example, assuming that CVEi and CVEj vulnerabilities exist, CVEi steals administrator information through an attack, and CVEj performs an attack under the precondition that it has the authority of an administrator, then this indicates that CVEi is an attack that must be carried out before CVEj is performed. Therefore, the vulnerability correlation analysis identifies the relationship between the vulnerabilities existing between the two nodes. The information collected in this way calculates the individual risk of nodes and edges through the VCAG-SS, and the overall risk score for the attack route is calculated by adding the node risk score and the edge risk score of the attack route. For the node risk, the CVSS score is used, and for the edge risk, the access location, attack type, CIA, and correlation are used. The proposed method calculates the edge weight using the correlation index between vulnerabilities and the CIA values for each access location, attack target, and vulnerability; through this, the node-edge value that provides the optimal route at the minimum cost is identified. The proposed method can be expressed as:

$$VCAG - SS\_{route} = (nodeRank\_{route} + arcsRank\_{route}) \ast Path\_{route} \tag{1}$$

Based on the node risk, edge risk, and number of routes, the attack priority risk is calculated for the corresponding route. The node risk is determined as in Equation (2), and the CVSS score of the vulnerability occurring in the node is used. The edge risk is as expressed in Equation (3), and the evaluation is performed with the access method of the two nodes, the type of attack performed on each node, the CIA, and the correlation between the two nodes.

$$nodeRank = \mathbb{C}VSS\_{node\\_Score} \tag{2}$$

$$\text{arsRank} = w\_1 AL + w\_2 AT + w\_3 CLA + w\_4 CLI \tag{3}$$

Equations (4)–(6) are the methods used to obtain each item of the edge risk, where *AL* is the access location, *AT* is the target of attack, *CIA* is the CIA value for each vulnerability, and *CCI* is the correlation index between vulnerabilities. *w*1, *w*2, *w*3, and *w*4, respectively, refer to the weights according to the access location, attack target, CIA value for each vulnerability, and the correlation index between vulnerabilities, which are arbitrarily calculated by the user according to the relative importance of the four values. The *AL* values are calculated according to the proposed method with the access methods (network, local, etc.) of two nodes. To determine which attack method was used in the attack type, the CIA used the CVSS-based CIA of the vulnerability. The vulnerability correlation index can be used by experts to evaluate the correlation between possible vulnerabilities in the two nodes.

*Access Location* (*AL*) = *Nodei AL weight*∗ *Nodej AL weight* (4)

$$Attack\ Type\ (AT) = \frac{number\ of\ attack\_i}{\sum\_{k=1}^{n} k\_{attack\_i}}\tag{5}$$

$$
\mathbb{C}IA = \mathbb{C}VSS\_{conifoldity} + \mathbb{C}VSS\_{integrity} + \mathbb{C}VSS\_{available} \tag{6}
$$

$$\text{CVE correlation index } (\text{CCI}) = \mathcal{c}\_{i,j} \tag{7}$$

#### *3.1. Access Location*

The access location is one of the important factors to determine the vulnerability of hosts and servers, and it can be divided into external and internal access. External access refers to direct access to the host or server from the external network, without going through a host or server in another internal network, and an attacker can perform various attacks through the external network. Representative attack methods include DDos, hijacking, drive-by, password, and phishing attacks. Conversely, internal access means that the host or server can only be accessed through another internal host or server. As such, external access can only be exposed to a larger variety of attacks than internal access, so there are much more vulnerabilities in external access.

The access location can be largely divided into external and internal, and in detail, it can be divided into network, adjacent network, local, and physical. "Network" means that "the node (host, server, etc.) can be accessed from all external networks"; "adjacent network" means "the node can only be accessed from the adjacent external network"; "local" means "the node can be accessed only from the internal network"; and "physical" means "the node can only be accessed by a physical method". The access location was defined based on the attack vector (access vector) provided by the CVSS, and it was proposed to be applicable according to the CVSS version as presented in Table 1.

**Table 1.** Access location weight according to CVSS version.

We calculated the edge weights based on the association between the two nodes; the access location weights defined in Table 1 are defined for the two nodes and the edge weights in Table 2 are defined according to Equation (4).

**Table 2.** Access location weight based on associations between two nodes.

#### *3.2. Attack Type*

The attack type was defined based on the thirteen vulnerabilities that were defined in [32] and the relative vulnerability occurrence rate according to Equation (5). ∑n <sup>k</sup>=<sup>1</sup> kattacki means the total number of occurrences of each vulnerability provided, and the number of attack*<sup>i</sup>* is the number of occurrences of a specific vulnerability in the previous year. Through this, the relative weight of each type of vulnerability can be obtained. *w* is the weight given to the attack target, and we used a *w* value of 2. The 13 attack targets are DoS, Code Execution, Overflow, Memory Corruption, Sql Injection, XSS, Directory Traversal, Http Response Splitting, Bypass something, Gain Information, Gain Privileges, CSRF, and File Inclusion. For example, if there were vulnerabilities that

occurred in 2021 and the number of occurrences was as presented in Table 3, it could be calculated as (1836/14,318) = 0.1287 in the case of DoS, and as (1680/14,318) = 0.1173 in the case of overflow.

**Table 3.** Number of identifications by attack target that occurred in 2021 [32].

#### *3.3. CIA Impact by Vulnerability*

The CIA impact for each vulnerability used the CIA impact of the base metric used in the formula proposed in the CVSS [33]. CIA refers to confidentiality, integrity, and availability. The corresponding values used the CIA impact value provided by each version of CVSS, and Table 4 presents those values. Moreover, suitable weights can be used depending on the CVSS version. In CIA, the values for each type of C, I, and A are the same for each version.

**Table 4.** CIA impact according to CVSS Version.

#### *3.4. Correlation Index between Vulnerabilities*

We generated a matrix based on the prerequisites between the CVE of the two nodes. A correlation between nodes can help identify what kind of relationship there is. At that time, information such as the presence or absence of pre and post conditions, similar attack methods, and conflicting attack methods was identified. Through this, the correlation index between vulnerabilities was generated, and the method was as follows:

$$c\_{i,j} = c\left(v\_{i\prime}v\_j\right) \tag{8}$$

In the proposed correlation index method (*c*), the vulnerabilities belonging to the two nodes (*i*, *j*) are identified, and the prerequisite relationship is identified accordingly. If the vulnerability in *vi* is a prerequisite or an attack that occurs in advance to the vulnerability in *vj*, then the matrix is defined as a value of 1; in the opposite case, it is defined as a value of 0. This is also determined when the two nodes are opposite to each other. That is, all the preconditions between the two nodes are grasped (*vi*↔*vj*). The preconditions of the two nodes analyzed in this way can be expressed in the manner listed in Table 5, and the weights for each situation are defined and used in the previously defined arsRank.

**Table 5.** Weight according to preconditions between two nodes.

#### **4. Experiment**

In this section, an experiment is conducted using a network established by obtaining the opinions of experts and data generated with vulnerabilities. It evaluates the risk of each node and edge present in the network, defines six possible attack routes, and calculates the risk of each route.

#### *4.1. Data Set*

In this paper, we defined the network and detailed information (vulnerability, port, address, etc.) according to each node. In particular, the network and its vulnerabilities were established with the advice of a group of experts. The network built using this method is illustrated in Figure 1, and the attacker started the attack through node A and aimed to reach node J, the final target. Each node contained vulnerabilities for an attacker to perform an attack, and there were nine nodes (PC and server), with 11 vulnerabilities defined.

**Figure 1.** Network that included nodes and vulnerabilities generated in this experiment.

#### *4.2. Priority Evaluation According to Attack Route*

First, the attack priority was calculated through a method that suggested the risk of each node and edge. Table 6 lists the result of calculating the risk for each node, and Table 7 presents the result of calculating the risk for each edge. C<sup>1</sup> and C2 denotes CVE-2007-5969, CVE-2014-2440. All values related to CVSS were calculated based on version 2.0. The node risk was calculated using the CVSS basic score of the vulnerabilities of each node (PC, server, etc.), and the edge risk was calculated by applying the risk calculation method suggested in Section 3. Regarding the weight of each item of edge risk, the attack location, attack type, and node association were judged to be more important than the CIA, and the weight was calculated while reflecting this.

**Table 6.** Node risk calculation results.

**Table 7.** Edge risk calculation results.

For the node risk, the experimental results confirmed that nodes with vulnerabilities with relatively high CVSS scores showed higher values. It was confirmed that nodes with various vulnerabilities scored higher than attacks that could penetrate through a single vulnerability, such as nodes C, G, and I, and that nodes that could attack with various nodes such as nodes D and G also scored higher. In terms of the edge risk, it was confirmed that the nodes (attack locations) that can be accessed from outside rather than inside and the attack types that occurred more frequently as of 2021 showed relatively higher risks. As a result of comparing D-G and G-D edge analysis, it was confirmed that the edge risk differed depending on the correlation between each vulnerability, and that even when connected to various nodes such as node D, different risk scores were calculated depending on how the vulnerability of each node was related to the vulnerability of node D. Further, in the case of A-C, it was confirmed that the vulnerabilities used to attack the two nodes and the corresponding correlation showed different edge risks, although they were the same nodes. Next, the risk for each attack route was calculated based on the calculated node and edge risk; Table 8 lists the attack route used in this experiment. Table 9 lists the results, and the attack route risk was calculated with 10 as the maximum. In the attack pathroute risk calculation, along with the risks of nodes and edges, the path route that was calculated based on the total number of nodes passed to reach the final target, node J, is also included. pathroute is a value obtained by dividing the maximum number of routes to reach the final goal by the number of corresponding attack routes. The longer the pathroute, the lower the value. There were six routes in total, and the nodes and the edges used according to each route were as follows.

**Table 8.** Nodes and edges along the attack route.

**Table 9.** VCAG-SS risk assessment results according to attack vectors.

It was confirmed that the risk of the fourth attack route was the highest, and it was confirmed that the risk increased that much because the path was connected to the most nodes, and passed through D nodes with various attack methods. Further, the vulnerability score for Path 3 was higher than those for Paths 1 and 5, which had the same number of paths. It was confirmed that the access method (access location) of the nodes was from the outside, and it was an attack type that was used relatively more frequently than the attack type used in other routes. It was also confirmed that attack routes containing routes with a high edge risk had a relatively high attack route risk scores than the other routes. We compared the proposed method with the method used in previous research. Since most previous research works do not provide open network data and the information used is different from each other, we compared research works that improved the value of CVSS. As presented in Table 10, the priority for attack routes is the same as a result of comparing the proposed method with existing methods, and there is only a deviation in the degree of risk for each route.

**Table 10.** Comparative experimental results.

#### **5. Conclusions**

In this paper, we proposed a method for defining node and edge values based on the information of the network, accordingly calculating the risk of each node and edge, and calculating the risk of a specific attack path through this. In previous research, the information contained in the node was used preferentially; in particular, the vulnerability scores provided by CVSS were used. However, in this study, we aimed to solve the problems associated with previous studies by proposing a method to calculate edge risk along with these values. A formula for calculating edge risk score was defined; access location, attack type, CIA, and correlation were calculated; and we attempted to use correlation to calculate more accurate risk scores through a vulnerability correlation analysis of two nodes. In the process of calculating the edge risk score, by analyzing the link between the two nodes, it was possible to determine which node was more dangerous when moving from one node to the next. This method also helped reduce the error of the risk generated by calculating the risk using only the CVSS information held by previous research. For the experiment, a network was built, an attack route was defined, and the risk level for each attack route was finally calculated. As a result of the experiment, the risks for 12 nodes and 13 edges were calculated, and through this, the risk score increased as the number of vulnerabilities increased or the number of nodes that could go through the node increased. In the edge risk score, it was confirmed that the risk was calculated differently depending on the prerequisites required for the vulnerability even if the two nodes were the same, and even if the two edges started from the same node, the risk varied depending on which vulnerability the arrival node had. Moreover, we calculated the risk score for six attack routes, and it was confirmed that the higher the risk calculated through nodes and edges, the higher the risk, which depended on the correlation between the states of the nodes

included in the attack path and the vulnerability. In addition, we confirmed the number of paths according to the attack route, and we confirmed that the states of the nodes and edges included in it was more important than the number of paths. Unlike previous research, this paper proposed a method of measuring risk score by defining an edge rather than improving its own values of the CVSS. This made it possible to calculate a simple and effective attack route risk score. However, since the values of CVSS 2.0 were used as is, the values were old, and an association analysis between nodes was performed, but the pre and post conditions of vulnerabilities were judged through experts, so a more accurate analysis should be conducted. Therefore, in future research, we will propose a more sophisticated risk calculation method by constructing a more complex network data set, calculating the risk along the attack path, and upgrading the node risk and edge risk. Further, since the number of paths to go through increases as the network becomes larger, we will also study how to effectively apply the number of paths to the attack vector risk.

**Author Contributions:** Conceptualization, S.-S.H.; methodology, G.-Y.S.; software, G.-Y.S.; validation, J.-S.L. and H.-R.O.; formal analysis, I.-S.H.; investigation, H.-R.O.; resources, I.-S.H.; data curation, H.-K.K.; writing—original draft preparation, G.-Y.S.; writing—review and editing, S.-S.H.; supervision, J.-S.L.; project administration, H.-R.O.; funding acquisition, H.-R.O. All authors have read and agreed to the published version of the manuscript.

**Funding:** This work was funded by the Defense Acquisition Program Administration and Agency for Defense Development under the contract cybercenter-MIS-997(21.10.15).

**Institutional Review Board Statement:** Not applicable.

**Informed Consent Statement:** Not applicable.

**Data Availability Statement:** Not applicable.

**Conflicts of Interest:** The authors declare no conflict of interest.

#### **References**

## *Article* **Development of an Open-Source Testbed Based on the Modbus Protocol for Cybersecurity Analysis of Nuclear Power Plants**

**Israel Barbosa de Brito † and Rafael T. de Sousa, Jr. \*,†**

Electrical Engineering Department (ENE), University of Brasilia (UnB), Brasilia 70910-900, Brazil

**\*** Correspondence<EMAIL_ADDRESS>Tel.: +43-660-3287490

† These authors contributed equally to this work.

**Abstract:** The possibility of cyber-attacks against critical infrastructure, and in particular nuclear power plants, has prompted several efforts by academia. Many of these works aim to capture the vulnerabilities of the industrial control systems used in these plants through computer simulations and hardware in the loop configurations. However, general results in this area are limited by the cost and diversity of existing commercial equipment and protocols, as well as by the inherent complexity of the nuclear plants. In this context, this work introduces a testbed for the study of cyber-attacks against a realistic simulation of a nuclear power plant. Our approach consists in surveying issues regarding realistic simulations of nuclear power plants and to design and experimentally validate a software testbed for the controlled analysis of cyberattacks against the simulated nuclear plant. The proposal integrates a simulated Modbus/TCP network environment containing basic industrial control elements implemented with open-source software components. We validate the proposed testbed architecture by performing and analyzing a representative cyberattack in the developed environment, thus showing the principles for the analysis of other possible cybernetic attacks.

**Keywords:** cybersecurity; nuclear power plants; Asherah Nuclear Power Plant Simulator; GNS3; PLC; OpenPLC; SCADA; ScadaBR; Modbus; ModRSsim2; industrial control systems (ICS)

#### **1. Introduction**

The main question addressed by this research is the design and validation of an easily reproducible and accurate testbed for nuclear power plant (NPP) cybersecurity research. It is important to bring results regarding the protection of such cyber-physical infrastructures because there is concern of attacks against the monitoring and control systems used in real nuclear plants. However, there are inherent risks associated with the safe operation of radioactive materials and high costs involved in suspending nuclear plant operation for safely testing cyber-attacks and defense measures. This scenario makes the use of nuclear power plant simulations almost unavoidable in these situations. Therefore, presently and in the foreseeable future, this question needs to be addressed to comprehend the possible cyber-attacks, their related risks, and to compose adequate protection measures.

As lately increased computing power allows the operation of realistic simulations of nuclear reactors on personal computers, this paper contributes with the design of a robust simulation-based testbed for NPP cybersecurity studies, combining low-cost hardware and software, to enable realistic simulations of the controlled physical processes and the used communications networks. The validation of the proposal raises another paper contribution in the form of a method for simulating cyber-attacks, presenting a case scenario that illustrates how to minimize the cost, difficulty, and complexity of NPP cybersecurity analysis, while maximizing the accuracy, reproducibility, and scalability of this type of experimental setup.

Recent years have seen a rise in cases of cyber-attacks against critical infrastructure. The impact of these attacks covers a spectrum that ranges from essential service interruption and financial loss to physical destruction. These attacks have been facilitated by the

**Citation:** de Brito, I.B.; de Sousa, R.T., Jr. Development of an Open-Source Testbed Based on the Modbus Protocol for Cybersecurity Analysis of Nuclear Power Plants. *Appl. Sci.* **2022**, *12*, 7942. https://doi.org/10.3390/app12157942

Academic Editors: Leandros Maglaras, Helge Janicke and Mohamed Amine Ferrag

Received: 7 July 2022 Accepted: 27 July 2022 Published: 8 August 2022

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2022 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/).

increasing digitalization in critical infrastructure sectors, and the convergence between information technology (IT) and operational technology (OT).

Examples taken from industry at large include: in 2013, the cyber-attack that paralyzed a German steel processing plant; and the attacks of 2015 and 2016 against Ukraine's power distribution grid, responsible for disrupting the power supply of thousands of homes [1]. Specifically in the nuclear industry, cases are known such as: in 2003, in the USA, the Slammer worm disabled the safety monitoring system at the Davis–Besse nuclear power plant (NPP); in 2006, in the USA, controller data traffic overload caused the shutdown of unit 3 at the Browns Ferry NPP; in 2010, in Iran, the Stuxnet worm destroyed uranium enrichment centrifuges; in 2014, in South Korea, hackers gained access to critical information about the operation of Korea Hydro & Nuclear Power NPP and demanded the shutdown of 3 reactors [2,3].

In response to the growing perceived cybersecurity threat against nuclear power plants, the academia has sought to contribute on several fronts. Research in this area encompasses proposals such as: qualitative assessments; best practice proposals; risk evaluations; cyberattack scenario studies; development of intrusion detection systems (IDS); precautions with supply chain; and cyber–physical protection systems; among others.

Many of these studies rely on computer simulations as their main working tool, be it purely software-based, or in a hybrid configuration (hardware-in-the-loop, HIL). Indeed, for many decades, the use of computer simulations has turned into established practice in the nuclear industry, particularly for training purposes, but also in the design and licensing phases of the construction and operation of the reactors. The inherent risks associated with the safe operation of radioactive materials and the high costs involved make the use of simulations unavoidable in these situations [4].

Nuclear codes and full scope simulators are of high complexity and financial value, and are generally beyond the wider reach of the academic community. Additionally, they offer little flexibility, as they are designed specifically for the NPP model where they will be employed. Finally, they do not address important aspects for real-world cybersecurity studies, such as industrial communications networking and the interfacing of OT with the company's IT structure. This scenario leaves researchers with the task of developing appropriate testbeds in order to: on the one hand, be able to draw sufficiently general conclusions about the cybersecurity of nuclear power plants; and, on the other hand, avoid oversimplification of the simulated scenarios.

Fortunately, in recent years, computing power has increased enough to allow the operation of realistic simulations of nuclear reactors on personal computers. Examples are the series of simulators developed and made available to the public by the International Atomic Energy Agency (IAEA) [5,6]. On the other hand, operating system (OS) virtualization technology has become popular to the point of enabling, by means of virtual machines (VM), the integration of these simulations with other typical OT elements in the form of software, such as supervisory control and data acquisition system (SCADA) and programmable logic controllers (PLC); in communication networks that use protocols specific to the automation industry. Together, these techniques enable the conformation of robust testbeds for NPP cybersecurity studies.

The purpose of this paper is to take advantage of these developments to propose one such testbed. Centered on the possibility of carrying out cyber-attacks against the Asherah NPP Simulator (ANS), developed by the University of Sao Paulo (Brazil) for the International Atomic Energy Agency (IAEA) Coordinated Research Project (CRP) "Enhancing Computer Security Incident Analysis at Nuclear Facilities" [4,7]; integrated into a Modbus/TCP virtual network communicating with complementary OT elements based on open-source software.

The remainder of the paper is organized as follows: Section 2 review the literature and explore research gaps to be improved; Section 3 describes how the proposed testbed was designed and implemented; Section 4 applies the testbed to perform a specific cyberattack scenario and evaluates the experimental results; Section 5 discusses the possibility of employing the testbed for intrusion detection and defensive capabilities research; and

Section 6 draws general conclusions, discusses limitations and suggests areas for future studies.

#### **2. Related Work**

Our general hypothesis argues for the potential benefits of adoption of purely softwarebased industrial testbeds or in combination with low-cost hardware, for cybersecurity research purposes. Furthermore, we believe that these need to be based, as far as possible, on realistic simulations of the controlled physical processes and of the communications networks used, both in its OT and IT dimensions. In this way, we will be able to minimize the cost, difficulty, and complexity while maximizing the accuracy, reproducibility, and scalability of this type of experimental setup.

From this perspective, we list below some related work (this does not focus on the uses of a HIL configuration for training purposes such as [8]); by way of example and without any attempt to exhaust the list of initiatives in the area. At the same time, we recognize that some of these works consider testbed development to be only a preliminary step to achieve diverse specific research goals. Nonetheless, we believe that the principles that guided the development of our testbed can be of value to the cybersecurity community in general.

C. N. Boldea, 2011 [9], suggested an open-source software framework to setup a SCADA testbed where the network would be provided by the application GNS3, connecting at one end a Modbus client simulator (ModRSsim2) and at the other end a SCADA server (Free Scada). The author indicates the possibility of performing DoS attacks from a VM situated in the same network against port 502 of the Modbus client. The article presents some good ideas, but does not offer further elaboration or describe practical results eventually obtained.

J. Z. Thornton, 2015 [10], designed a virtual SCADA laboratory where the physical process (gas pipeline) was modeled out of complex mathematical equations simulated by the Simulink/Matlab software [11]. This allows for a more complete study of the behavior of a physical system during a cyber-attack. The control logic expressed in ladder language was emulated by Python programming. The communication via Modbus/TCP by Python libraries (modbus\_tk). The SCADA was partly implemented with a proprietary solution (GE iFix) and partly by Python libraries (TKInter). The pervasive use of Python on the testbed, while positive from a monetary perspective, could have contributed to diminishing the realism of the proposed virtual lab. Furthermore, the use of proprietary software should be avoided, if possible, in our view.

M. Andrey Teixeira et al., 2018 [12], present the development of a SCADA testbed to be used for cybersecurity research. Their setup was dedicated to controlling a water storage tank in a HIL configuration via the Modbus protocol. The effects of reconnaissance industrial network cyber-attacks on the testbed were assessed and used to train machine learning (ML) algorithms, in order to develop an automated IDS. However, the choice of the industrial subprocess to be simulated is too simple, and thus limits the possible practical applications of the model. Furthermore, it resorts to specific commercial hardware such as the Schneider PLC model M241CE40, which restricts the generality of its conclusions and complicates the reproducibility of the experiment.

S. Figueroa-Lorenzo et al., 2019 [13], in order to test their proposal to improve the security of the Modbus protocol, have built a virtual testbed, containing TCP/IP software network elements (firewall, routers and switches) made available by Cisco for use in the network simulator GNS3. Since the authors' approach was based on applying the Transport Layer Security (TLS) technique to traditional Modbus TCP/IP protocol, they assumed that the cybersecurity of the model is guaranteed by design. It then remained to evaluate possible problems arising from implementation flaws and low performance, which could be verified with the help of the arranged setup. This article shows the power and flexibility of virtualized testbeds, for exploring various aspects of cybersecurity of industrial control systems (ICS). However, it relied on proprietary software in its choice of implementation (Cisco GNS3 Appliances).

F. Zhang et al., 2019 [14], describe a testbed architecture to demonstrate a multilayered defense-in-depth-based IDS. That included an engineering workstation to run the SCADA, a data storage unit, a National Instruments cDAQ9188 Ethernet chassis, and a malicious computer running the Kali Linux OS. This setup allowed for different attacks, such as Denial of Service (DoS) and man-in-the-middle (MITM). However, the physical process representing a nuclear reactor subsystem was simulated only notionally. This limitation was remedied in a later work by the authors, as in 2020, F. Zhang et al. [15] proposed a HIL testbed built with the Asherah NPP Simulator (ANS), which is capable of a realistic simulation. It also comprises a PLC, in order to conduct false data injection attacks and collect data to ML training of a PLC process data anomaly detector. Still, it could be argued that the choice of commercial PLC (Siemens S7-1200) and proprietary software (Prosys OPC UA) contribute to prevent the widespread applicability of the proposed framework.

O. Pospisil et al., 2021 [1], summarize recent works in the area of industrial testbeds; motivated by the lack of quality real data in the quantities and features required for ML applications aimed at automating cybersecurity tasks. Although not specific to the nuclear industry, the study describes concepts and strategies common to the development of these testbeds. As choices related to the following factors: industrial processes to be studied; project category (physical, simulation, virtual, hybrid); application scenario (cybersecurity, education, functional testing, standards development); industrial communication protocols (Ethernet/IP, Profinet, EtherCAT, Modbus, Siemens S7); and levels of the automation pyramid to be modeled, according to the ANSI/ISA-95 model (ISO 62264) [16]. Specially levels L0 to L2, where: L0 deals with production processes (sensors and actuators); L1 with control (PLCs); and L2 with supervision (SCADA). The paper goes on to describe several testbeds set up in their university's laboratory for data collection purposes. The wealth of scenarios explored, however, may pose difficulties for researchers with fewer laboratory resources. In particular, in relation to testbeds assembled from a great diversity of physical equipment and proprietary protocols.

E. Aboah Boateng et al., 2022 [17], set up a testbed based on open-source software to compare the performance of the ML one-class neural network (OCNN) training algorithm on a Modbus/TCP network against previous works aimed at developing automated IDS for ICS. Those last employed one-class support vector machine (OCSVM) and isolation forest (IF) ML algorithms to detect PLC operation anomalies. The authors made the fortunate decision to implement the traffic light operation program; originally developed for the Siemens S&-1212C PLCs, in the open-source soft PLC OpenPLC instead. The humanmachine interface (HMI) was also chosen to be provided by the free supervisory system ScadaBR. Despite this, we consider the simplicity employed for the network, consisting only of Modbus communication occurring between the HMI and the Soft PLC, to be overly limiting. This could explain why the anomalous scenarios described in the article were not really emulated, but only imagined. Moreover, the physical process of low complexity controlled by exclusively binary variables would hardly occur in real situations involving critical industrial subsystems.

In contrast to the works listed above, our proposal is intended to be both close to industrial practice and financially effective. We resort to a complex simulation of a nuclear power plant. This is in turn monitored and controlled by a supervisory system and PLC, based on opensource software and low-cost microcontroller, actually used for factory operations and remote monitoring by certain companies. The emulated network environment allows both the reproduction of communications by the popular industrial protocol Modbus, and the reproduction of cyber-attacks actually developed to be used against real ICS.

#### **3. Proposed Testbed for Cybersecurity Analysis of Nuclear Power Plants**

In this section, we present the requirements considered in building up the proposed testbed, and we discuss the idea that guided the validation of our design. Then, the testbed components are detailed and discussed. The followed methodological process can be seen in the flowchart depicted in Figure 1.

**Figure 1.** Methodological flowchart.

The requirements that guided the assembly of our testbed were as follows:

We consider this testbed capable of emulating a variety of cyber-attacks against Modbus/TCP-based nuclear power plant simulated ICS. In order to validate this hypothesis, we planned to use it to perform an insider cyber-attack. This consisted in simultaneously: (a) replacing a local PLC by a Rogue PLC (Level 1 of the ANSI/ISA-95 model [16]), to modify the values of the registers used to control an actuator critical to the NPP operation (Level 0); and (b) interpose and modify the communication between Levels 1 and 2, so that the SCADA shows a normal situation in relation to the physical process, effectively blinding the system to the attack in progress (men-in-the-middle attack or MITM). The described levels and their respective roles can be seen in Figure 2.

This testbed also allows the application of the IAEA concepts of defensive computer security architecture (DCSA) [18,19] (not part of this study), a practical technique to protect facility functions that support safety and security that make use of, depend on, or are supported by digital technologies. Therefore, a researcher can implement the concepts of computer security levels (implementing a graded approach) and computer security zones (delivering defense in depth) and develop cyber-attack scenarios to assess ways in which an adversary could exploit vulnerabilities in systems performing facility functions.

The requirements and envisioned cyber-attack in turn guided the choice of the components shown in Table 1 below.

**Table 1.** Nuclear testbed. List of components.

<sup>1</sup> Note: running inside Simulink/MATLAB on a Windows 10 (64-bit) VM., <sup>2</sup> Note: VMware Workstation Player [29] and Oracle VirtualBox [30] used as hypervisors for the GNS3 appliances and VMs., <sup>3</sup> Note: installed on an Ubuntu 20.04 VM., <sup>4</sup> Note: visual tool to manage the open-source MySQL Community Edition [31] database, utilized by ScadaBR.

In what follows, we briefly explain the capabilities and justify the selection of the above listed components. We also describe the adjustments made in order to integrate them into the testbed and enable the proposed cyber-attack.

#### *3.1. Modbus/TCP Protocol and the Modbus Simulator*

Modbus is a protocol for industrial communications that was created more than 40 years ago (by PLC manufacturer Modicon, now Schneider Electric) and still enjoys great popularity for real world SCADA/ICS implementations. There are several reasons for this: it is an open standard that is easy to implement and optionally available for almost all commercial automation equipment. This allows the same plant to easily integrate equipment from different manufacturers into its operations.

The protocol is also a favorite for cybersecurity studies, since in its standard form it has no mechanisms to ensure confidentiality or data integrity, among other vulnerabilities. It is also possible use search engines for Internet connected devices, like Shodan [32], to locate and remotely attack Modbus systems. Furthermore, since different brands of PLC accept the protocol as an option and it responds to external commands regardless of authentication, they can easily be victimized by injection attacks [33,34].

Last but not least, the open-source software chosen to build our testbed; specifically, ScadaBR and OpenPLC, both support the Modbus protocol. It should be noted that commercial PLC brands in general feature their own proprietary protocols and in some cases accompanying simulation software, also proprietary.

Modbus/TCP is one of three variants of the protocol and allows communication over Ethernet networks on standard port 502 (the other two being Modbus ASCII and Modbus RTU). It uses the client-server architecture and its communications are based on exchanging Ethernet Request and Response frames, as can be seen in Figure 3.

**Figure 3.** Modbus/TCP client-server communication.

Figure 4 shows how the Modbus TCP packet is encapsulated in the data section of the conventional Ethernet Frame. It is structured as follows: MBAP (Modbus Application Protocol) header followed by the PDU (Protocol Data Unit) section. This last section contains the message itself, consisting of: (a) function code, which indicates the desired operation (such as read and write); and (b) data, related to the operation defined in the previous field, such as addresses or values to write. Table 2 shows common Modbus function codes.

**Figure 4.** Modbus TCP packet structure.

**Table 2.** Common Modbus function codes.

The protocol has a particular addressing scheme that consists in dividing its memory area into four sections; for discrete (Boolean) and analog values (Coils and Registers), read-only or read-write, as can be seen in Table 3. Each of these addresses can store data types of up to 16 bits. Therefore, to use 32-bit data types, it is necessary to use two consecutive addresses for each of these values. In the particular implementation of our testbed, characterized by simulated physical processes of mainly continuous nature, we chose to use only the Holding Registers section of Modbus memory. There, all values simulated by the ANS, Boolean or analog, were saved in FLOAT 32-bit format.

**Table 3.** Modbus addressing scheme.

The Modbus simulator chosen to enable communication between the different modules of the testbed was ModRSsim2 [20]. This program behaves as a server that responds to requests from Modbus clients located at different IP addresses; through port 502 of the VM where it is installed. Thus, it was used as the ANS's Modbus memory, which could then be remotely accessed by ScadaBR and OpenPLC.

#### *3.2. Asherah NPP Simulator (ANS) and Its Adapted Modbus Communications Interface*

The Asherah NPP Simulator (ANS) was specially developed for cybersecurity assessments, by the University of Sao Paulo, Brazil [4,7]; in the framework of an international cooperation project sponsored by the International Atomic Energy Agency (IAEA). It has a core design that mathematically simulates the nuclear physics of the Three Mile Island (TMI) reactor, the 2772 MWt Pressurized Water Reactor (PWR) Babcock and Wilcox (B&W). In addition to the core, it also simulates the various instrumentation and control (IC) modules required to operate the several subsystems commonly found in a real nuclear power plant [4].

Its unique features and the absence of similar research software availability determined the choice of ANS for our testbed. The high degree of complexity and realism of ANS could only be achieved by the developing work [35,36], and the verification and validation activities [4] performed by the developers with the support of experts involved in the IAEA CRP Enhancing Computer Security Incident Analysis at Nuclear Facilities. The proprietary software Simulink/MATLAB provided the adequate environment for the development of the ANS' 3200 blocks and more than 250 scripts. Simulink/MATLAB is the one of the two proprietary software used in our setup (the other being the OS Windows 10). In spite of this, the Simulink/MATLAB software is widely available in university laboratories around the world. ANS itself can be provided to IAEA member states upon formal request at [6]. In its current version, ANS can be deployed without the need of Matlab/Simulink, as a

runtime standalone version or in a docker/container [37] application (also without the need of any proprietary software).

In Figure 5, we can see a general view of the ANS subsystems, divided into three subsections. The two above, from left to right, show: (a) the control loops and protection system; and (b) primary and secondary loops. The bottom subsection shows the external interface, comprised mainly by the Comm Module and Matlab Historian.

**Figure 5.** General View of the ANS subsystems.

In the version used (Windows—Release 14 dec 20), ANS was specially prepared to communicate via the OPC UA protocol (Open Platform Communications Unified Architecture). Thus, in order to enable a new Modbus communications interface, it was necessary to implement the following superficial modifications to the program: (a) map the sensor and controller variables to new areas of the Modbus server ModRSsim2 (Holding Registers Area only—two registers for each variable since they must be written as 32-bit FLOAT), as can be seen in Figure 6; (b) create a new initialization script for the new Modbus command variables (ans\_load), which must be run in the Matlab Command Window; and (c) disable the original OPC UA communication modules and create and activate new Modbus modules by means of scripts based on Modbus read and write functions from MATLAB Instrument Control Toolbox, as shown in Figure 7.

Note that both applications, the Modbus server and the ANS, were installed on the same machine and therefore shared the same IP. The operating system used was Windows 10. From this point on, we could have chosen to install the rest of the testbed components on other physical machines connected by a hardware switch. Instead, we elected to build the entire testbed on a single machine by means of OS virtualization technology.

**Figure 6.** Mapped holding registers area of ModRSsim2.

**Figure 7.** ANS Modbus communications interface.

#### *3.3. GNS3 Topology*

The open-source program GNS3 (Graphical Network Simulator-3) [21] was used to create a simple TCP/IP network topology needed to set up the testbed and carry out the planned insider cyber-attack. This program allows emulation and simulation of various network equipment, such as routers, switches, and firewalls; besides OS VMs. It supports several free hypervisors such as VirtualBox and VMware Workstation Player. The elements used to build the topologies are called appliances. The main elements used in our implementation, all free, were the following: VyOS Router; 2 Ubuntu 20.04 VMs (ScadaBR and OpenPLC), and; Kali Linux. Another facility provided by GNS3 is its simple integration with the well-known communication protocol analyzer software Wireshark [28], which in turn is able to analyze Modbus traffic. Several such units can be inserted into the topology segments at the same time.

In essence, our testbed was assembled to study and manipulate the Modbus/TCP communication in an industrial subnet between the PLCs of a nuclear power plant and its supervisory system. As intervening elements, inserted in the system by the Insider, we have: (a) a computer with the OS Kali Linux distribution installed, a well-known platform used for pen test (penetration testing) and equipped with several libraries for cyberattacks; and (b) a "Rogue" PLC whose function is to substitute an internal control of the plant, previously neutralized by the malicious agent. All mentioned elements were installed in VMs whose IP and MAC addresses were fixed, and are in turn interconnected through Ethernet via a simple switch.

This configuration is sufficient to carry out insider attacks between the ANS and the HMI, since it is assumed that the subnet is segregated from the Internet in critical infrastructures such as NPP (Air Gap). However, the VyOS router [22] was also added and configured in the topology to allow access to the internet of the test environment and thus facilitate the installation and configuration of the programs and also allow for HIL testing (Arduino Wi-Fi). The resulting GNS3 topology is shown in Figure 8 and its IP scheme in Table 4 below.

**Figure 8.** GNS3 nuclear testbed topology.

#### *3.4. ScadaBR HMI and Historian*

ScadaBR [24] is an open-source supervisory system that presents several features expected by our testbed in order to reproduce a situation close to the industry practice in a virtual environment. In particular: visualization of automation data in real time; construction of graphical screens; and continuous recording of variable changing values in a database. This last function, also called Historian or Datalogger, is provided by the relational database management system (RDBMS) linked to the main program. It is fundamental to enable deeper studies based on the analysis of data captured over long periods of time, such as, for example, the creation of datasets for IDS automation research through the training of ML algorithms. In the version we used, the supervisory links to an Apache Derby RDBMS by default. However, most ScadaBR users migrate the application to use the MySQL [31] manager instead, which would provide performance and stability gains to the Historian in real applications. We repeated the procedure in our testbed and, in order to facilitate the manipulation of this database, we also installed the MySQL Workbench [27] graphical tool in the same VM.

Regarding the choice of variables to be monitored by ScadaBR, it is important to recognize that the version of ANS that was employed continuously provides the values of 153 different input and output (IO) variables (sensors, actuators, setpoints, and commands). These are grouped into 19 subsystems distributed among the three main circuits found in PWR reactors (primary, secondary, and tertiary). Thus, any practical study involving cyber-attacks against the ANS and evaluation of its impacts must commence by selecting a relevant subset of this universe.

Besides the desired participation of the nuclear reactor (RX) and its reactivity control variables, our choice of subsystems of ANS to be included in the ScadaBR HMI was guided by their close relationship to those that are likely to be mostly affected in the cyber-attack scenario planned as a validation test for the proposed framework. To this end, we determined that the attack would primarily involve the condenser cooling pump (CCP). This system in the tertiary circuit is responsible for controlling the balance between steam and water in the condenser (CD) linked to the output of the power plant's electrical generator driving turbine (TB). Its improper operation could, in the extreme, cause the interruption of the turbine (TB) operation, and indirectly of the nuclear reactor. Another feature that makes this subsystem attractive for an insider is that it is usually physically located outside the nuclear island.

These considerations led to the development of a HMI consisting in the numerical and graphical screens shown in Figures 9 and 10. In those, we have just linked the variables associated with the chosen subsystems: main control; condenser cooling (CC); condenser (CD); turbine (TB); and reactor (RX). Their characteristics are described in greater detail in the experimental section of this paper.

**Figure 9.** ScadaBR HMI—Synoptic Panel 1 (Numerical and Main Control).

**Figure 10.** ScadaBR HMI—Synoptic Panel 2 (Graphical).

#### **4. Conducting the Cyber-Attack Scenario and Evaluating the Results**

As mentioned before, our cyber-attack scenario consisted in the replacement of an internal ANS control by a malicious external one that tampered with a critical variable value, while simultaneously a real-time value-changing MITM attack prevented the anomalous activity from being detected by the HMI.

In more specific terms, the attack consisted of using the Rogue PLC to set the value of CC\_PumpSpeedCmd to 75, while the HMI instead showed its normal value around 100, for main control power output of 100%. In the absence of manipulation, this variable adjusts the condenser cooling pump (CCP) speed to keep the condenser (CD) vapor pressure close to a reference value (5200 Pa), as can be seen in Figure 11.

#### **Figure 11.** CD Press CTRL.

Thus, it was expected that the artificially imposed slightly lower fixed value would not be easily noticed and would gradually increase that condenser pressure, eventually reproducing the damaging effects described above. To do this in practice in our testbed, we followed these steps:

#### *4.1. ANS Preparation*

The procedure for disabling internal ANS modules in Simulink/MATLAB involves commenting them out and at the same time enabling the necessary command connectors in the communications section. Specifically, Figure 12 shows how we disabled the CD Press CTRL module and the internal variables CC\_PumpSpeedCmd and CC\_PumpOnOffCmd. Figure 13 shows how we activated these same variables in the communications area, so that they can be controlled externally. The physical equivalent of this operation would be the replacement of the legitimate PLC or its control programming for another version. We assume that the malicious agent would have the ability to make this physical modification, in a real situation.

**Figure 12.** CD Press CTRL module commented out.

**Figure 13.** CC control variables communications activated.

#### *4.2. Rogue PLC*

The Rogue PLC has been implemented in the open-source program OpenPLC [23]. The software was developed according to the IEC 61131-3 standard [38], which defines the 5 PLC programming languages (Ladder Logic—LD, Structured Text—ST, Instruction List— IL, Function Block Diagram—FBD, and Sequential Function Chart—SFC). It is divided into two main parts: the Editor and the Runtime. The Editor is where programs are created. The Runtime can be embedded in low-cost microcontrollers such as the ones of the Arduino family, or in a generic target like a Soft-PLC (Windows or Linux). In addition, there is a web-based platform to define, monitor, and manage the program to be executed and the various PLCs in use.

A ladder program was designed in the OpenPLC Editor that enabled manual control of the cyber-attack, via simple circuitry based on the Arduino board ESP8266 NodeMCU v1.0 ESP-12E (button PB1 ON—attack activated; button PB2 ON—attack interrupted). This Arduino board was connected to the Wi-Fi network of the test environment [39]. To link the variables defined in the program to the Modbus memory IO target variables; to manipulate only the desired Holding Registers in it, without messing with the other addressing areas, and to have access to more analog outputs, we followed the OpenPLC addressing conventions and created 3 slaves (one of Device Type ESP8266 and two of

Device Type Generic TCP), as can be seen in Figure 14 and according to the settings shown in Table 5.

**Figure 14.** ESP8266 NodeMCU v1.0 OpenPLC address mapping.

<sup>1</sup> Note: these are the offsets pointing to the beginning of the variables in the Holding Registers area of ModRSsim2.

The ladder program logic is as follows. When the attack is triggered (the normally open button PB1 is physically pressed on the arduino board), the consecutive Holding Registers corresponding to CC\_PumpSpeedCmd (Hccpspeedcmd at 400,225 and Lccpspeedcmd at 400,226) are written with the values 17,046 and 0000 (FLOAT 7.5E+01, or 75) on the ModRSsim2 Server. When the attack is stopped, the CC\_PumpSpeedCmd registers are written with the values 17096 and 0000 (FLOAT 1.0E+02, or 100). The registers related to CC\_PumpOnOffCmd (Hccponoffcmd at 400,285 and Lccponoffcmd at 400,286) are kept at 16,256 and 0000 (FLOAT 1.0E+00, or 1) throughout the operation. The MOVE instruction was used to transfer the content of the operand at input IN to the operand at output OUT when the Input EN is ON. The local variables used are shown in Table 6 and the implemented ladder program in OpenPLC Editor is shown in Figure 15.

**Figure 15.** Rogue PLC ladder program in OpenPLC Editor.

**Table 6.** Rogue PLC ladder program local variables.

#### *4.3. Attack Platform*

Kali Linux [25] distribution was chosen to unleash the value-changing MITM attack. This platform allows for performing cyber-attack scenarios with the purpose of assessing its consequences. It offers a wide range of tools for information security and ethical hackingrelated tasks, such as penetration testing, computer forensics and reverse engineering. In its inventory there are tools tailored exclusively for cyber-attacks against SCADA/ICS. For example, the Metasploit framework, which comes pre-installed by default on Kali, offers modules that can be used to find Modbus servers and clients; and read and write

Modbus registers [40]. For some equipment, it is even possible to upload, analyze, and then download and replace the PLC ladder logic (modicon\_stux\_transfer module) [41].

These Metasploit modules in particular, or exploits, as they are called, could have been used in our testbed to write constant values to the ModRSSim2 server registers and thus achieve the same results as those obtained by the simple Rogue PLC logic just described. As can be seen by the sequence of commands shown in Figure 16, it is possible to employ the "modbusclient exploit" to write the values 17,046 and 0000 (value 75) for the two bytes after the 224 address offset (variable CC\_PumpSpeedCmd) of the ModRSsim2 Server at IP <IP_ADDRESS> (ANS VM).

**Figure 16.** Metasploit Modbus injection attack example (CC\_PumpSpeedCmd = 75).

Instead, we preferred to demonstrate the HIL implementation capabilities of our testbed, and emphasized its potential for increased programming complexity, and scalability provided by the use of soft PLCs; which allows the developing of cyber-attacks that require a greater knowledge of the plant control system (not addressed in this study). For example, by the external cloning the logic of the internal controller being replaced, it would be possible to enable more subtle attacks to be carried out, with greater control of the manipulated variables and eventual return to normal control whenever desired. In

principle, a well-informed Insider would know the implementation details necessary to perform this procedure. In any case, this point demonstrates the flexibility of the testbed and illustrates an alternative way to perform the same Modbus injection cyber-attack.

As for the MITM attack itself, the specific tool used was Ettercap (also present by default on Kali Linux distributions) [26]. It allows us to snoop live TCP/IP connections and to filter content on the fly. In the validation experiment we performed the in-transit change of Modbus response packets from ANS to ScadaBR. This was done in two steps. First, Ettercap applied the ARP poisoning technique (sending unsolicited ARP replies simultaneously to both of its targets) to make ANS (<IP_ADDRESS>) believe that the ScabaBR (<IP_ADDRESS>) was located in the Kali VM IP address (<IP_ADDRESS>); and to make ScabaBR believe that ANS was in Kali address, as shown in Figure 17. Ettercap could now eavesdrop and pass on these packets in both directions.

**Figure 17.** Ettercap ARP poisoning (ANS and ScadaBR).

The second step consisted in filtering and changing the ANS responses to Modbus READ requests made by ScadaBR. Among the various values contained in these response packets, we wanted to change in transit only the ones corresponding to CC\_PumpSpeedCmd (to its normal value of 100, regardless of the actual value being transmitted by ANS). As Ettercap filtering was not designed with the Modbus protocol in mind, it was necessary to design a script that took into account: (a) Ettercap's filter syntax and offset addressing rules; (b) the specifics of the HMI implementation; and (c) ScadaBR's execution routines.

Ettercap filter offsets (pointed to by DATA.data + OFFSET = "value") start at the beginning of the DATA section of the Ethernet frame, which coincides with the beginning of the Modbus TCP packet section for the Modbus TCP protocol. On the other hand, for the set of variables chosen to be monitored by the HMI, ScadaBR performed 3 sequential requests whose responses had fixed length and thus could be used as identifiers (Length: 251 [ 00 fb ] Registers 8–131; Length: 243 [ 00 f3 ] Registers 132–251; Length: 113 [ 00 43 ] Registers 280–311). We also knew that we must change only the contiguous registers located at 224 and 225, to the value 0X42C80000 = 100 DEC. With these considerations taken into account, it was possible to write the appropriate filter script, shown in Figure 18 and capable of changing only the desired packets and registers.

**Figure 18.** Ettercap MITM changing values filter script.

It is understood that different configurations in the HMI would require adaptations to the presented script. Once again, we assume that the Insider has in-depth knowledge of the control architecture. It should be noted that in a real situation, we would also have several SlaveIDs for different PLCs, which in ANS correspond to internal control modules, all gathered under a single SlaveID.

#### *4.4. Combined Cyber-Attack*

The planned cyber-attack was successful and able to: (a) block the internal control of CC\_PumpSpeedCmd; (b) inject an arbitrary constant value of 75 into CC\_PumpSpeedCmd; and (c) show the normal value of CC\_PumpSpeedCmd = 100 on the HMI, during the attack. Figure 19 shows the Arduino board ESP8266 NodeMCU v1.0 breadboard circuit and the OpenPLC web interface monitoring page for the implemented Rogue PLC ladder program. All the programmed variable values are displayed in real time. Additionally, while the attack is occurring, the Ettercap filter script continuously outputs the message that indicates that the MITM is in progress, as show in Figure 20. Next, in Figure 21, we can see the local value for CC\_PumpSpeedCmd in the Matlab ANS interface is indeed modified to 75 by the Rogue PLC, and at the same time, the false value of 100 is presented in the ScadaBR HMI.

Figure 22 below shows another way to visualize the same cyber-attack; this time from inside the GNS3 topology with the help of two Wireshark instances. The lower one in the figure, located between the ANS VM and the Switch in the topology, captures the NPP response packets to the supervisory before the real-time modification performed by the Kali/Ettercap MITM. The upper one, between the ScadaBR VM and the Switch, captures the same packets after the modification. Since each response corresponds to the same Modbus transaction value, it is possible to check the results by reading the fields corresponding to records 224 and 225; which show 75 for the lower one and 100 for the higher one.

**Figure 19.** Attack ON—Rogue PLC.

**Figure 20.** Ettercap MITM (CC\_PumpSpeedCmd transmitted as 100).

**Figure 21.** ANS and HMI under attack.

**Figure 22.** Attack with Wireshark packet analysis example.

#### *4.5. Impact Assessment*

To evaluate the impact of the proposed cyber-attack on ANS' subsystems, we based ourselves on the following aspects:

Contrary to our original expectations, setting the value of CC\_PumpSpeed to 75 (through the variable CC\_PumpSpeedCmd) did not significantly affect the nuclear reactor operational variables. In these circumstances, the most impacted variables were the condenser vapor pressure (CD\_Press) and the turbine outlet pressure (TB\_OutSteamPress). So, we repeated the attack for several different values of CC\_PumpSpeed, varying it in steps of 5 units, between 75 and 15; and assessed the variables' equilibrium values in comparison with their rated values (which can be obtained from the ANS manual).

While proceeding in this way, it is important to consider the operational limits imposed by the simulator itself. The ANS has a reactor protection system (RPS) that triggers the socalled reactor´s SCRAM (emergency shutdown) whenever certain thresholds are exceeded. Figure 23 shows how its logic is implemented.

**Figure 23.** ANS reactor protection system (RPS).

For the subsystems monitored in the setup, whenever any of the following variables exceeds its respective threshold, the OR gate depicted propagates the ON (1) signal to the SCRAM Output (CR\_ScramCmd): CD\_Level > CD Overflow = 1.5 (m); CD\_Press > CD OverPress = 6760 (Pa); mod (RX\_OutCoolTemp − RX\_InCoolTemp) > RX OverTempDiff = 40 (k); and 0.5 \* (RX\_OutCoolTemp − RX\_InCoolTemp) > RX OverTemp = 580 (K). The only one of these parameters that varied for the different scenarios was the CD\_Press, whose maximum threshold was reached with CC\_PumpSpeed between 55 and 50. We have disabled the triggering of this protection system in order to proceed with tests for CC\_PumpSpeed values below 50. However, states very far from the operating limits may lose its physical meaning for the simulation or be impossible to achieve in real equipment.

After completing these rounds of attacks, it was verified that the final results for the monitored variables at the various levels followed essentially the same pattern as revealed by the initial attack, with regard to the main variables affected; except that the condenser vapor pressure and the turbine outlet pressure increased more and more with the decrease of the condenser cooling pump speed.

In the following tables, we have applied color-coding to visually differentiate the degree of deviation of the measured values from the operating values under normal conditions. Rated values are represented in green. Values just below the rated (up to less than 10%) are in light blue, and below 10% in dark blue. Values just above the rated (up to 10%) are in orange, and above 10% in red. The tables also show other relevant information such as the original labels, ranges, units and descriptions, as defined by the ANS developers (Figures 24–27).

**Figure 24.** Simulated results (CC—Condenser Cooling).

**Figure 25.** Simulated results (CD—Condenser).

**Figure 26.** Simulated results (TB–Turbine).

**Figure 27.** Simulated results (RX—Reactor).

From the experiments performed, it was possible to arrive at the following conclusions about the cyber-attack against the condenser cooling pump speed, especially for values below 50:

#### **5. Intrusion Detection and Defensive Capabilities**

Besides demonstrating the ability of the testbed to access realistic cyber-attacks against a nuclear power plant simulator, we would also like to emphasize its potential for conducting studies for the development of intrusion detection techniques and for the possible

automation of this process. Since ICS are deterministic systems, we believe that, for cyber-attacks similar to the one employed, their detection could be done mainly by joint monitoring [42]: network parameters; and operational variables.

To illustrate the network monitoring approach, we have chosen the "Time from request" network parameter in Modbus TCP packets destined for ScadaBR (<IP_ADDRESS>). This value measures the response time between the request from the supervisor and the response from the ANS, and can be easily captured by Wireshark, as shown in Figure 28. Next, we extracted about 2000 of these packets, at the point between the supervisor and the Switch (HMI\_ScadaBR Ethernet0 to Switch eth3); and used this data for graphical comparison between normal operation and under MITM attack, as depicted in Figures 29 and 30. The approximate average delay (shown in these pictures as colored lines) of about 0.01 seconds is noticeable when we compare the normal response time with the situation under attack.

**Figure 28.** Time from request—Wireshark snapshot.

**Figure 29.** TFR comparison—normal.

**Figure 30.** TFR comparison—MITM.

To demonstrate the operational variables approach, and guided by the experimental results above described, we chose to relate the variables CC\_PumpSpeed and CD\_Press. If a pattern for their simultaneous values in a nominal operation situation could be found, this in principle would allow the detection of elaborate cyber-attacks against one of them; such as replay attacks, where the value shown in the HMI corresponds to the oscillations of that variable values in a previous period.

In normal operation with the Main Reactor (RX) power at 100%, the variable CC\_PumpSpeed, held at the constant value of 100 by our cyber-attacks, actually oscillates with values close to 102. This can be seen most clearly in the graphs in Figure 31, where the first 1000 or so measurements after the start of normal reactor operation are shown. The graph depicted on the left shows the values for each observation and the graph on the right shows the density or frequency of values associated with the various measurements, for the same data set.

**Figure 31.** CC\_PumpSpeed nominal oscillations (around 102).

Furthermore, small operation transients, even in normal operation, are expected and were observed during the simulations. Therefore, we used MySQL Workbench to extract a sample of 600 observations where one of these transients were present, as shown in Figure 32, and thereafter studied the relationship between the values of CC\_PumpSpeed and CD\_Press in this range.

**Figure 32.** CC\_PumpSpeed and CD\_Press simultaneous transients.

After normalizing these values between 0 and 1, as shown in Figure 33 (a standard preparatory procedure necessary to employ various ML algorithms), we determined the linear correlation between the variables to be very low (−0.1925). However, the respective scatter plot clearly displays the formation of an underlying non-linear pattern, as seen in Figure 34. This found locus could presumably be used to detect anomalies. Although mere visual inspection will be insufficient to detect non-linear relationship patterns for more than two chosen variables or features, appropriate mathematical and computational techniques can be employed instead. The same procedures could be expanded in order to train ML algorithms, by including new variables and enlarging the dataset.

Besides the possibility of studying anomaly detection techniques, this testbed also allows the application of a graded approach and defense in depth, by implementing computer security levels and computer security zones, and assessing the technical computer security measures needed to protect facility functions. One example of practical implementation of a defensive computer security architecture (not part of this study), would be the use of a decoupling mechanism between computer security zones containing the PLCs and the supervisory.

**Figure 33.** CC\_PumpSpeed and CD\_Press—data normalization.

**Figure 34.** CC\_PumpSpeed and CD\_Press Data—scatter plot.

#### **6. Conclusions**

In this work, we developed and validated a testbed for conducting cybersecurity assessment in nuclear power plants. The main advantages of this setup are its realism, flexibility, and low cost. It allows the simulation of several cyber-attack scenarios against a simulated NPP communicating with its supervisory system (SCADA/HMI), through the Modbus TCP protocol. It is worth mentioning that this study was carried out based on a simulator of a hypothetical power plant (Asherah NPP) and that vulnerabilities that could lead to a similar attack on existing plants were not exploited. We also showed how it is possible to use this environment to generate the datasets needed for intrusion detection studies, and stated that it allows for implementation of defensive computer security architecture.

For the proposed cyber-attack scenario, the performance of several simulations allowed to demonstrated how to force condenser cooling pump parameters against their nominal operating values is detrimental to the continuous operation of PWR-type NPPs. In particular, the impact assessment points to the risk that cyber-attacks against the condenser cooling pump speed control could result in material and financial damage to the NPP. The situation described also highlights the danger posed by Insiders, endowed with specific knowledge about the inner workings of the NPP ICS and acting within the Air Gap protected area.

We realized that an important limitation of this testbed is the substantial memory load imposed by the employment of several virtual machines in the GNS3 topology, especially in terms of RAM. Thus, more modest computing environments could experience problems when trying to reproduce or expand the conditions described. However, it was possible to perform all the above procedures with a personal computer equipped with an AMD Ryzen 7 3700X 8-Core Processor 3.60 GHz and 32.0 GB of RAM installed. The RAM memories defined in the topology were: 6 GB for the Windows/ANS VM; and 2 GB for each of the Linux VMs.

Several possibilities for future studies are envisioned. Such as:

**Author Contributions:** Conceptualization, I.B.d.B. and R.T.d.S.J.; Data curation, I.B.d.B.; Formal analysis, I.B.d.B. and R.T.d.S.J.; Funding acquisition, I.B.d.B. and R.T.d.S.J.; Investigation, I.B.d.B.; Methodology, I.B.d.B. and R.T.d.S.J.; Project administration, I.B.d.B. and R.T.d.S.J.; Resources, I.B.d.B. and R.T.d.S.J.; Software, I.B.d.B.; Supervision, R.T.d.S.J.; Validation, I.B.d.B.; Visualization, I.B.d.B.; Writing—original draft, I.B.d.B.; Writing—review and editing, I.B.d.B. and R.T.d.S.J. All authors have read and agreed to the published version of the manuscript.

**Funding:** This research was funded by Agência Brasileira de Inteligência—ABIN—grant number 08/2019.

**Institutional Review Board Statement:** Not applicable.

**Informed Consent Statement:** Not applicable.

**Data Availability Statement:** Not applicable.

**Acknowledgments:** R.T.d.S.J. gratefully acknowledges the support of CNPq grants 465741/2014-2 and 312180/2019-5, the Administrative Council for Economic Defense—CADE grant 08700.000047/2019- 14, the National Auditing Department of the Brazilian Health System DENASUS grant 23106.118410/2020- 85, the General Attorney of the Union—AGU grant 697.935/2019, the General Attorney's Office for the National Treasure—PGFN grant 23106.148934/2019-67 and the University of Brasilia—UnB COPEI grant 7129. This work was made possible thanks to the support of International Atomic Energy Agency which provided the Asherah NPP Simulator (ANS).

**Conflicts of Interest:** The authors declare no conflict of interest.

#### **Abbreviations**

The following abbreviations are used in this manuscript:

#### **References**

MDPI St. Alban-Anlage 66 4052 Basel Switzerland Tel. +41 61 683 77 34 Fax +41 61 302 89 18 www.mdpi.com

MDPI Books Editorial Office E-mail<EMAIL_ADDRESS>www.mdpi.com/books

MDPI St. Alban-Anlage 66 4052 Basel Switzerland Tel: +41 61 683 77 34

www.mdpi.com

ISBN 978-3-0365-4846-3


**6. Diagnostic tests**

In the case of a diagnostic process of BK, an interview with the patient and microbiological tests are important. The clinical appearance of the infection is not a reliable factor indicating the causative pathogen. Routine proceeding should be the collection of material for culture and preparation of direct material. In patients wearing contact lenses, the contact lens itself may provide key information about the pathogen. The corneal ulcer should be cultured for the identification of the causal organism and make an antibiogram for achieve an antibiotic susceptibility before commencing antimicrobial therapy [31]. Based on the American Academy of Ophthalmology, it is still recommended to perform the first culture and/or smears in the following situations [9]: