Command Disaggregation Attack and Mitigation in Industrial Internet of Things.

A cyber-physical attack in the industrial Internet of Things can cause severe damage to physical system. In this paper, we focus on the command disaggregation attack, wherein attackers modify disaggregated commands by intruding command aggregators like programmable logic controllers, and then maliciously manipulate the physical process. It is necessary to investigate these attacks, analyze their impact on the physical process, and seek effective detection mechanisms. We depict two different types of command disaggregation attack modes: (1) the command sequence is disordered and (2) disaggregated sub-commands are allocated to wrong actuators. We describe three attack models to implement these modes with going undetected by existing detection methods. A novel and effective framework is provided to detect command disaggregation attacks. The framework utilizes the correlations among two-tier command sequences, including commands from the output of central controller and sub-commands from the input of actuators, to detect attacks before disruptions occur. We have designed components of the framework and explain how to mine and use these correlations to detect attacks. We present two case studies to validate different levels of impact from various attack models and the effectiveness of the detection framework. Finally, we discuss how to enhance the detection framework.

1. Introduction

A large-scale industrial Internet of Things (IIoT) [1] is deployed to help utilities such as smart train and smart grid provide better service. A typical hierarchical system is adopted in many large-scale IIoTs to obtain flexible control [2,3,4]; this system includes many lower-layer sub-controllers, such as programmable logic controllers (PLCs) in power systems. Sub-controllers are in charge of command disaggregation. For example, a demand response (DR) load reduction of 70 MW in power grid is requested across the entire grid. The command needs to be disaggregated into some sub-commands such as load reduction of 10 MW, 20 MW, and 40 MW according to the capacity of endpoint field devices because the appliances have different levels of capacity. This disaggregation process continues until local commands for endpoint field devices are generated and exercised [5,6].

However, with the wide openness of communication infrastructure which is used to improve efficiency, reliability, and sustainability of services [7] such as smart grid, new vulnerabilities have been exposed [8,9,10,11,12]. High-skilled attackers can obtain many opportunities to remotely access sub-controllers to inject malicious commands and modify data from sensors. A real case was studied in [13] to demonstrate this ability of smart attackers.

When commands reach sub-controllers, malicious entities remotely attack sub-controllers to generate wrong executed commands called command disaggregation attack. The attack may result in disruptions of physical process. In this paper, we focus on the process of launching the command disaggregation attack and its detection method. Previous studies, such as [2], introduced the concept of command disaggregation attack. Attackers can inject false commands or modify sensory data to implement false command disaggregation. However, these studies did not describe how to launch effective command disaggregation attacks to result in damages to the physical system. Besides, when attackers simultaneously launch command disaggregation attacks and inject false feedback data to confuse the security detector, existing detection methods such as false data estimation [14] can not effectively identify anomalies. Detecting command disaggregation attacks with false feedback data injection is still an unexplored topic.

Driven by the above considerations, we depict two different command disaggregation attack modes: (1) false command sequence; and (2) wrong command allocation. The former refers to the situation that attackers delay the disaggregation of some commands to disorder its logic, thereby resulting in disruptions of physical process; the latter refers to the situation that disaggregated commands are issued to other than the expected or planned actuators, causing the failure of control objective or physical damages. We also describe three attack models to implement command disaggregation attacks in two kinds of modes. When attackers manipulate the disaggregation of commands, they simultaneously inject false feedback data to confuse security detectors to ensure that the attack goes undetected. To deal with the threats above, we provide a detection framework based on correlations among two-tier command sequences, which collects two-tier commands including those issued from the central controller and the sub-commands executed by actuators. We design components of the detection framework and explain the method of mining correlations among commands and using the correlations to detect attacks. Finally, two cases are studied to demonstrate the different levels of impact from various attack models and the effectiveness of proposed detection framework.

The rest of the paper is organized as follows. We introduce the related work and summarize our contributions in Section 2. We depict two kinds of modes and three attack models in Section 3. In Section 4, we describe the detection framework. Two case studies are given in Section 5. We discuss how to enhance the detection framework in Section 6 and conclude our work in Section 7.

2. Related Work and Our Contribution

2.1. Related Work

In this section, we first survey the state of the art of attacks that cause disruptions of physical process. Then, we review the works about attack detection.

Three methods, namely, false command injection, false data injection, and time-delay attacks, can be used to disrupt the physical system. In [15,16,17], attackers directly injected false commands into the controller to disturb physical process. False data injection attack was described in [18,19]. Attackers capture sensors to inject false data, which causes false state estimation or hides signs of faults leading to disruptions. In [7,20], authors described time-delay switch attack, which increases time delays in the sensing loop or in the automatic generation control signal to impact the control process. In [21], authors considered DoS attacks. Attackers jammed communication channels by intruding into the advanced metering infrastructure of smart grid. Commands and feedback data can not be transmitted to the actuators and controller thereby compromising the control process. In [13], authors described a real case that attackers can manipulate sub-controllers by infecting the firmware of a PLC. An attacker gets access to the PLC’s input values through the firmware from the physical world, processes them, and then provides outputs that are forwarded to the physical world through the firmware. Moreover, attackers also can modify feedback data which are transmitted to the central controller from the compromised PLC. These studies showed that the existing vulnerabilities in IIoTs can enable attackers to remotely disrupt physical process, but they did not consider the command disaggregation attack. Currently, there are some researches that have focused on command disaggregation attacks. For example, in [2], the authors demonstrated the possibility of command disaggregation attacks and revealed the cascading failure effect, but the process of command disaggregation attacks that can cause damage to physical system is not described.

Although many detection methods have been proposed to detect anomalies caused by attacks, they are not effective to identify false command disaggregation attacks. For example, in [22], some counter-attack mechanisms were proposed to defend attacks, however, attackers may find vulnerabilities and bypass these mechanisms to launch false command disaggregation attacks by injecting elaborately constructed false data or directly intruding into the controllers [2]. In [23,24], authors used the linear correlations among sensory data to detect anomalies. However, when false command disaggregation occurs and attackers simultaneously inject false data to confuse the security detectors [14], anomalies can not be detected. Likewise, false data estimation that used multiple data detectors with dissipativity-theoretic fault detection function in [14] and detection method based on correlations between commands and sensory data in [25,26] also failed in identifying the above attacks. In [27], authors used methods based on machine learning to detect attacks, however, when bad data is successively injected, the method is still ineffective to identify command disaggregation attacks. In [28,29], authors mined the correlations among commands to detect injected false commands. However, command disaggregation attacks modify commands after commands are collected from the controller, which leads to the undetected situation. If defenders only collect commands from actuators, multi-variant types of commands will increase the difficulty and inaccuracy of correlation mining.

2.2. Our Contribution

After summarizing the related work in attack and in detection, we clarify our contributions as

We introduce two kinds of command disaggregation attack modes, namely, false command sequence and wrong command allocation.

We describe three attack models to implement command disaggregation attacks in two modes. Attacks based on the three models can not be detected by the existing detection methods.

We provide an effective detection framework based on correlations among two-tier command sequences. Detecting command disaggregation attacks with false feedback data injection is still an unexplored topic and our method is the first to effectively identify command disaggregation attacks before a disruption occurs.

3. Command Disaggregation Attack

In this section, we first introduce a simplified model of IIoT control system. Second, we unveil two kinds of command disaggregation attack modes, including wrong command allocation and false command sequence, wherein we depict attack models.

3.1. System Model

Figure 1 shows the structure of a typical IIoT control system, which is composed of the central controller, sub-controllers, actuators, and sensors. The central controller issues command sequences based on the physical system state and sends these commands to the corresponding sub-controllers. Sub-controllers are responsible for command disaggregation and feedback data transmission from sensors to the central controller. There exist multi-tier sub-controllers. The sub-controller in the upper level sends disaggregated commands to the sub-controllers in the lower tier. Sub-commands are gradually disaggregated until the sub-controllers in the lowest level send sub-commands to the actuators. Actuators execute sub-commands to implement the physical process and the physical system state has a change. The current physical system state is evaluated based on values of sensors, and then new commands are issued to further control the physical process. An example of the command disaggregation is shown in Figure 1, where commands are issued simultaneously from the central controller at time t. After multi-tier sub-controllers disaggregate these commands, sub-commands are executed by the actuators. denotes a kind of command and denotes the executed sub-commands, which are defined in subsequent description of the system model.

Figure 1

The structure of IIoT control system.

The system model is described using six-tuple:where

is a finite set of commands from the central controller. is the kth kind of command. indicates the commands issued by the central controller at time t.

is a finite set of time series. A time series is the measured values of one sensor with the change of time. means the time series from the ith sensor. denotes the measurement of the ith sensor at time instant l. means the number of sensors.

is a finite set of physical system states. denotes the jth kind of state and . Detectors and controllers can evaluate the system state at time k, , based on values of sensors, which can be computed by where is the constant matrix. denotes the evaluated state at time k, and under normal circumstances, . = where denotes the value of time series at time instant k.

is a set of sub-commands executed by actuators. indicates the executed sub-commands by actuators when command from the central controller is and the system state is . Element defines the sub-command that will be executed by the kth actuator. N means the number of actuators. An actuator only executes a sub-command in unit time, and a sub-controller only disaggregates one command from the upper-tier sub-controller during once outflow of the central controller. denotes the executed sub-commands when the corresponding commands are issued from the central controller. is an element of AC(t) and denotes the sub-command executed by the ith actuator. The system state at time t, , is decided by and [14], which can be described as where and are constant matrices. indicates the time interval between the time t when current commands are issued and the time of its last outflow.

is a finite set of relationships among commands and system states. () indicates that the executed sub-commands are when the system state is and the command from the controller is .

is a subset of set S. A disruption occurs when the system state is .

The model is based on the assumption that the information and physical systems have not yet been attacked, and all observed states and commands can be regarded as a representation of normal system behavior. From the above process, we can know that the accurate feedback data and commands are critical for the normal running of systems. When security mechanisms such as authentication [30] and cryptography [31] are used to protect the data from sensors to controllers and commands from the controller to the sub-controllers, false command injection and bad data injection can be launched with less possibility. However, when attackers control the PLC’s firmware below the control logic by compromising a device through the Joint Test Action Group interface [13], these mechanisms may become ineffective. Besides that, adding authentication and cryptography mechanisms may be unwelcome in many existing IIoTs because of a large amount of investment. Moreover, security mechanisms may delay the response from the physical system, which can not be accepted by some real-time systems. In follow-up studies, we assume that attackers can bypass these mechanisms or focus on vulnerable systems without these security mechanisms.

We also use to denote a set. Any element satisfies where is any possible system state when command is issued.

To describe the attack models, we define two operations about sets, “−” and “+”. For any two sets and , and .

3.2. Two Kinds of Attack Modes and the Attack Models

In this section, we will disclose two kinds of attack modes and describe the corresponding attack models in details. During the implementation of the attack models, attackers usually inject false data into sensors or feed back false data to detectors to hide signs of attacks.

3.2.1. Wrong Command Allocation

When a command is disaggregated at system state , the sub-commands may be sent to false actuators or changed to other sub-commands leading to a situation that sub-commands are changed to . There exist two situations about wrong command allocation mode, including wrong command inner allocation and wrong command outer allocation. Wrong command inner allocation occurs when an attacker changes the executed sub-commands to the false sub-commands . Wrong command outer allocation occurs when attackers change to false sub-commands . In Figure 2, an example is shown to explain the two situations. are commands from the controller, and are physical system states. Commands at different system states can turn on/off valves. When the current command is and the system state is , if attacks make Valve 2 turned on, this situation is called wrong command inner allocation. If attacks turn Valves 3 or 4 off or on, this situation is called wrong command outer allocation.

Figure 2

An example: explaining different attack modes.

Next, we depict the attack models that implement the above two situations.

(1) Attack model based on wrong command inner allocation (WCIA)

means . To achieve this target, attackers can inject false data to interfere with the state estimation. As shown in Figure 3a, WCIA is described as follows:

Figure 3

Attack models based on wrong command allocation mode.

• Information collection

Attackers first find a set of issued commands , command , state , and state satisfying Equation (4).

• False data injection

When attackers discover that the current state is and command will be disaggregated, attackers inject bad feedback data into sub-controllers in charge of the disaggregation of and inform them the current state is . Attackers need to control different levels of sub-controllers based on different demands. If attackers inject false feedback data into the ith sub-controllers, they also need to inject the same false feedback data to manipulate the corresponding (i + 1)th tier sub-controllers. The disaggregation of commands is influenced and the executed sub-commands are changed from to . A disruption occurs when are executed because the system state becomes . To go undetected as described before, attackers again inject false feedback data after was executed, which needs to change the state from to (). Unlike the former false feedback data injection, this false state should be obtained by the central controller and sub-controllers, which means that attackers should directly inject false data into sensors or feed back the false state to all controllers.

(2) Attack model based on wrong command outer allocation (WCOA)

means . To achieve the target, attackers not only need to inject bad feedback data, but also to modify the command, as shown in Figure 3b. WCOA is described as follows:

• Information collection

Attackers first find a set of issued commands , commands and , state , and state satisfying Equation (5).

• Command modification

We use to denote the disaggregated commands of by the middle-tiers sub-controllers. Unlike the wrong command inner allocation, attackers first change the commands to when has been disaggregated as , and then transfer them to the next-tier sub-controllers.

• False data injection

When disaggregated commands have been modified, attackers need to inject bad feedback data to the next-tier sub-controllers. Bad data informs the next-tier sub-controllers that the current state is . The real situation is . If the commands received by the next-tier sub-controllers still require disaggregation, attackers should inject false feedback data to its next-tier controllers. Thus, attackers should try to control the nearest sub-controllers from the actuators to decrease the number of compromised sub-controllers.

When the sub-commands were executed by actuators, attackers should also re-inject false feedback data to confuse the controller. The state should be changed to ().

3.2.2. False Command Sequence

Under normal situations, if is executed before is issued from the central controller, then actuators should first execute sub-commands from the disaggregation of . Sub-commands from the disaggregation of then are executed. From the controller’s point of view, stands as sequential commands, however, the actuators execute the sequence when attacks based on false command sequence occur. To achieve the target, attackers need to delay the disaggregation of command , meanwhile, inform the controller that has been executed and command should be issued from the controller. After is executed, is disaggregated. For example, in Figure 2, under the normal situation, the controller first issues the command at the system state , and then issues the command . If is disaggregated before is disaggregated, the false command sequence occurs.

As shown in Figure 4, the attack model (FCS) is described as follows:

Figure 4

Attack model based on false command sequence mode.

• Information collection

Attackers first find command sequence satisfying Equation (6).

• Time-delay attack

Attackers manipulate the sub-controllers to delay the disaggregation of . The disaggregation of begins after the sub-commands from the disaggregation of are executed.

• False data injection

Commands are issued at state . After sub-commands from the disaggregation of commands are executed, the real physical system state is changed from to . Because the current state is not , the controller does not issue the commands . Thus, attackers inject false data into sensors to induce false state estimation. The controller issues the commands when it obtains the false state . After sub-commands AC(t) from the disaggregation of are executed, the state becomes . To enable command to be disaggregated, attackers again inject false data to tell the controller and sub-controllers that the current state is . When the sub-commands is executed, the real state is changed from to and a fault will occur. Attackers can enhance attack effect by avoiding anomaly discovery. To achieve this target, fault data can be continuously injected into controllers and detectors to tell them that the current state is .

4. Detection Framework Based on Correlations among Two-Tier Command Sequences

WCIA, WCOA, and FCS change executed commands during the process of disaggregation, meanwhile, inject false data to confuse detectors. The existing detection methods in Section 2, such as false data evaluation [14] and event correlation based method that collects commands from the central controller [28], can not discover anomalies caused by these attacks. To fill the gap, we propose a novel and effective detection framework to identify attacks based on WCIA, WCOA, and FCS. We first describe the structure of the detection framework. Second, we examine how to mine correlations and use these correlations to identify anomalies caused by command disaggregation attacks.

4.1. Detection Framework

The detection framework is in charge of collecting command sequences, mining correlations, and identifying anomalies. As shown in Figure 5, the framework is comprised of command collector, correlation analyzer, correlation database, and exception detector. The functions of the four components are described below.

Figure 5

The structure of detection framework.

• Command Collector

Command collector is responsible for collecting commands from IIoTs. Command collector gets commands from two sites, as shown in Figure 1, including commands from the central controller and sub-commands from all actuator inputs. Every time a command collector receives a four-tuple , where , and means the time when sub-command is executed by the ith actuator. Data is then transferred to two other components, namely, correlation analyzer and exception detector.

• Correlation Analyzer

Correlation analyzer tries to discover whether correlations exist among commands and sub-commands. Correlation analyzer mines correlations by using the recently collected history data. Once in a while the analyzer will update the correlations in correlation database. We will discuss which correlations and how they are mined in the next subsection.

• Correlation Database

Correlation information is stored in the correlation database. Correlation information includes discovered correlations and the time and number of occurrences of commands and sub-commands. Correlation database provides the corresponding information when the correlation analyzer or exception detector requires.

• Exception Detector

Exception detector examines anomalies of the input four-tuple based on correlation information. The exception detector directly utilizes correlations in database, instead of waiting for knowledge from the correlation analyzer, to identify anomalies. Therefore, the time that the detector spends in identifying anomalies is not related to correlation mining. The detector can provide the real-time result when a 4-tuple is input.

4.2. Correlation Mining and Exception Detection

We mainly mine two kinds of correlations including correlations between a command and sub-commands, and correlations between executed sub-commands.

4.2.1. Correlation between a Command and Sub-Commands

If executed sub-command can be obtained by the disaggregation of command , there exists a correlation between command and sub-command , denoting as . From an input four-tuple, we can not easily judge which command is correlated with an executed sub-command because multiple commands may be issued simultaneously from the central controller. We use greedy rules to mine this kind of correlation by analyzing a large number of four-tuples. We first define one parameter:

Latter support ratio denotes the ratio of the number of occurrences that is executed when command is disaggregated, to the number of occurrences that command is executed. It can be computed as where denotes the number of occurrences that is issued from the controller and is executed by the actuator in an effective time interval . means the number of occurrences that sub-command is executed by the kth actuator. The value of depends on the characters of physical system and transmission delay.

At the beginning of correlation mining, there exist many 4-tuples . The latter support ratio between any executed sub-command and any command is computed by analyzing these 4-tuples. For any sub-command , the process of mining which commands are correlated with the sub-command can be divided into two phases including verified correlation selection and correlation validation. The flowchart is shown in Figure 6 and the details are described as follows:

Figure 6

The flowchart of correlation mining between a command and a sub-command.

Phase I: verified correlation selection. In this phase, the correlation analyzer only needs to find a command satisfying where is a set of commands and it is equal to C when correlation mining between sub-command and commands begins.

Phase II: correlation validation. In the second phase, the correlation analyzer judges whether there exists a correlation between and .

We use to denote the set that comprises correlations related to that have been validated. If does not satisfy Equation (7), the correlation exists and we add the correlation into set . If satisfies Equation (7), the correlation does not exist. After that, is removed from set . where is the set containing all time intervals from the time of issuing command to the time of executing in history data, for example, is an element of .

The two phases are executed repetitively until set is null.

4.2.2. Correlation among Executed Sub-Commands

If Equation (8) is satisfied for executed sub-commands and that are correlated to command , a correlation exists between and , denoted as . means . This kind of correlations denotes that there exists a linear relationship between the number of occurrences of two sub-commands. where y(k) and x(k) indicate the number of occurrences that is executed by the ith actuator and the number of occurrences that is executed by the actuator when command is issued at its kth outflow. is the error threshold. , , and are input parameters and are obtained based on characters of system and data analysis.

The flowchart of correlation mining among sub-commands is given in Figure 7. The key procedure is to compute , which is elaborated as

Figure 7

The flowchart of correlation mining between two sub-commands.

The correlation analyzer can obtain from the correlation database. is a constant vector and can be computed in Equation (9) by applying the least squares method to minimize estimation error .

After computing , we will validate whether (8) is satisfied for any k . When (8) is satisfied for any k, the correlation exists. Otherwise, there does not exist a correlation between and . Correlations and history data should be updated due to the degradation of system performance and changes in behaviors [15]. At the beginning of update, existing correlations will be directly removed from the database and new correlations are computed based on the mentioned process.

Lastly, we introduce the detection process of the exception detector.

Exception detector identifies anomalies based on broken correlations. For a sub-command from the input four-tuple , if we can not find a command to ensure that correlation exists in the database, then an alarm will be issued. For any correlation , if (), the exception detector will verify whether the correlation is broken under the new command and sub-command . If an existing correlation is broken, an alarm is issued .

5. Case Study

In this section, we investigate two cases about tank system and energy trading system in the smart grid to illustrate the impact of attacks and the effectiveness of our detection framework.

5.1. Scenarios

5.1.1. Scenario 1:3-Tank System

A tank system [16,32] with 100 sub-tank systems of the same liquid is utilized in this case. Figure 8 demonstrates the structure of tank system. The factory produces liquid C by the neutralization process of ingredient A and ingredient B. The ratio of ingredient A to ingredient B is 1. Error within 10% is allowed, and 1 mL A and 1 mL B can neutralize 2 mL liquid C. Ingredient A and ingredient B flow out from their tanks by 3 mL/second. Liquid C flows out from its tank by 6 mL/second. Every sub-system that can produce liquid C is composed of three tanks with ingredient A, three tanks with ingredient B, and one tank used to neutralize liquid C, six pumps used to output ingredient A or ingredient B, one valve used to output liquid C. When the central controller issues a command, Group Operational Systems will issue the same command to its all next-tier sub-controller.

Figure 8

The structure of a tank system.

We only describe a sub-system to illustrate the control process. Table 1 describes the 14 executed sub-commands and 7 sensors. Sensors S11, S12, and S13 measure the amount of ingredient A in Tank11, Tank12, and Tank13, respectively. Sensors S21, S22, and S23 measure the amount of ingredient B in Tank21, Tank22, and Tank23, respectively. Sv1 measures the amount of liquid C in TankC1.

Table 1

Description of data in the tank system.

Command/Time Series	Description
P11o/P11f	Switch on/off Pump P11
P12o/P12f	Switch on/off Pump P12
P13o/P13f	Switch on/off Pump P13
P21o/P21f	Switch on/off Pump P21
P22o/P22f	Switch on/off Pump P22
P23o/P23f	Switch on/off Pump P23
V11o/V11c	Open/Close Valve V11
T11	Measurements of Sensor S11
T12	Measurements of Sensor S12
T13	Measurements of Sensor S13
T21	Measurements of Sensor S21
T22	Measurements of Sensor S21
T23	Measurements of Sensor S23
Tv1	Measurements of Sensor Sv1

A plan of producing mL liquid C within s is provided to the central controller. The central controller will continuously issue commands including turning on the pump that outputs ingredient A at time 0 s (), turning off the pump that outputs ingredient A at time M s (), turning on the pump that outputs ingredient B at time M + 60 s (), turning off the pump that outputs ingredient B at time s (), opening the valve that outputs liquid C at time s (), and closing the valve that outputs liquid C at time s (). The process is executed repetitively if users have a new order of goods. When the sub-controller will output mL liquid A for a sub-system, it will open the pump with the largest amount of ingredient A until the output is equal to mL. If the tank with the largest amount of ingredient A is insufficient, the sub-controller will open other pumps to produce ingredient A. Thus, the sub-controller can simultaneously open multiple pumps to output ingredient A. For example, when users will produce mL liquid C within s, the sub-system should open two pumps of outputting ingredient A. If sub-controllers open multiple pumps and receive the command “turning off the pump”, they also issue sub-commands to turn off multiple pumps. The corresponding ingredient will be supplied when two or more tanks with ingredient A or ingredient B are empty. The initial volume of every tank with ingredient A or ingredient B is mL.

The above neutralization process depicted is simulated in Java, where the central controller, actuators, and sub-controllers are designed as components by using Java Class. Every switch and sensor are seen as attributes of related actuators. When some attributes occur a change, the central controller issues new commands. Some executed sub-commands can cause the changes of the attributes. Different components communicate with each other by function call with parameters. The parameters include commands and feedback data. The central controller automatically keeps running and issues commands based on the users’ input and the designed control process. During the operation of the system, values of sensors, sub-commands, and commands are written into different files per unit time. Moreover, every sub-controller component provides an interface for users. When users call the interface and input parameters, sub-controllers have been compromised and commands and feedback data can be modified.

5.1.2. Scenario 2: Energy Trading System in the Smart Grid

With the increasing proliferation of new energy, many users can become suppliers who sell energy to other users called consumers. Every supplier has an energy storage system that stores extra energy. When consumers need to buy energy, energy is routed to these consumers from suppliers based on energy routing schemes.

A simplified model of energy trading system in the smart grid [33,34] is shown in Figure 9, where there are 3 suppliers and 3 consumers. The central controller receives sensory data from consumers and suppliers and sends commands to control switches that are responsible for outputting or inputting energy. Sensory data from the consumers describes how much energy has been input and data from the suppliers depicts how much energy can be outputted. When a switch is turned on, energy can be input or be outputted by 500 w/s. When the output of energy is larger than the demands of consumers, extra energy will be wasted. When supplied energy can not satisfy demands of consumers, some consumers have to turn off some appliances. If the amount of energy routed to a consumer is larger than his demands, extra cost needs to be paid. The control process needs to try to avoid the above three situations.

Figure 9

The model of energy trading system in the smart grid.

In the model, there are 12 sub-commands and 6 sensors, which are shown in Table 2. Sensors Ss1, Ss2, and Ss3 measure the amount of energy that can be provided by suppliers s1, s2, and s3, respectively. Sensors Sc1, Sc2, and Sc3 measure the amount of energy that has been bought by consumers c1, c2, and c3, respectively.

Table 2

Description of data in the energy trading system.

Command/Time Series	Description
w1o/w1f	Turn on/off switch w1
w2o/w2f	Turn on/off switch w2
w3o/w3f	Turn on/off switch w3
w4o/w4f	Turn on/off switch w4
w5o/w5f	Turn on/off switch w5
w6o/w6f	Turn on/off switch w6
T11	Measurements of Sensor Ss1
T12	Measurements of Sensor Ss2
T13	Measurements of Sensor Ss3
T21	Measurements of Sensor Sc1
T22	Measurements of Sensor Sc1
T23	Measurements of Sensor Sc3

At the beginning of every circle, consumers sent their demands w and suppliers send the amount of their energy to the central controller. The central controller will continuously issue commands including turning on the switch that outputs energy at time 0 s (), turning on the switch that inputs energy at time 0 s (), turning off the switch that outputs energy at time K s (), turning off the switch that inputs energy at time s (). When the suppliers will output K w energy, it will turn on the switch with the largest amount of energy until the output is equal to K w. If multiple users request power, the sub-controller will turn on other switches to output energy. The initial volume of every storage system is w. Energy will be compensated when two or more suppliers can not supply enough energy. The described model with the trading process is also simulated in Java and the details of implementation are similar to scenario 1.

5.2. Attack Cases

In this subsection, we introduce six attack cases based on WCOA, WCIA and FCS. Under normal circumstances of scenario 1, users randomly receive orders of goods including mL, mL, and mL. We show the normal measurements of sensors with the change of time under random orders of goods in Figure 10. Figure 10a,b show the measurements of sensors about ingredients A and B. Figure 10c shows the amount of liquid C. When the value in TankC1 reaches the highest point in a cycle, the ratio of ingredient A to ingredient B is 1. Hence, liquid C can be obtained. Under normal circumstances of scenario 2, consumers randomly receive orders of energy including w (one consumer) and w (two consumers). We also show the normal measurements of sensors with the change of time under random orders of energy in Figure 11. Figure 11a–c show the amount of energy in storage systems of three suppliers. Figure 11d–f show the amount of energy obtained by three consumers in every circle.

Figure 10

Measurements from sensors under the normal situation of scenario 1.

Figure 11

Measurements from sensors under the normal situation of scenario 2.

Six attack cases are described as follows:

Attack case 1 in scenario 1: When the controller issues command , malicious entities launch attacks based on WCIA to turn on pump p13 by telling sub-controller sc-22 that Tank13 has the most ingredient A.

Attack case 2 in scenario 1: At s, the controller issues the command and malicious entities launch attacks based on WCOA by manipulating the sub-controller sc-11 and modifying state feedback to sc-22 and sc-23. Operation “turning on the pump p11” is replaced by the operation “turning on the pump p21”.

Attack case 3 in scenario 1: At s, the controller issues command and attackers launch attacks based on FCS. Malicious entities first manipulate sub-controller sc-22 not to disaggregate command . Command is disaggregated after command is disaggregated at s.

Attack case 4 in scenario 2: When the controller issues command , malicious entities launch attacks based on WCIA to turn on w1 by telling sub-controller sc-11 that supplier s1 has the most energy.

Attack case 5 in scenario 2: At s, the controller issues the command and malicious entities launch attacks based on WCOA by manipulating the sub-controller sc-11 and modifying state feedback to sc-11. Operation “turning on the switch w1” is replaced by the operation “turning off the switch w2”.

Attack case 6 in scenario 2: At s, the controller issues command and attackers launch attacks based on FCS. Malicious entities first manipulate sub-controller sc-11 not to disaggregate command . Command is disaggregated after command is disaggregated at s.

During the above attack processes, attackers also modify data of sensors to confuse the central controller and detectors, thereby resulting in sensory data same to those in Figure 10 and Figure 11.

5.3. Attack Impact

5.3.1. Case 1

Figure 12 demonstrates the real measurements of sensors under attack case 1. Real measurements refer to the real values of sensors, which may be different from received sensory data by the central controller or state estimator. Compared with Figure 10, ingredient B normally flows into TankC1. However, the change in the amount of ingredient A is abnormal since s. From the beginning of the second circle, Tank13 always outputs ingredient A until the tank is empty. Before Tank13 is empty, the ratio of ingredient A to ingredient B in TankC1 is 1 and the factory can produce liquid C. When Tank13 is empty, the sub-controller still turns on pump p13 and outputs ingredient A from Tank13, which leads to a false ratio and fails to produce liquid C. Figure 12c demonstrates the above process. The ratio is false and liquid C can not be obtained in the seventh circle.

Figure 12

Measurements from sensors under attack case 1.

5.3.2. Case 2

Figure 13 describes the real measurements of sensors under attack case 2. Unlike in Figure 10, ingredient A in Tank12 and Tank13 is normal. From s, ingredient A should be outputted from Tank11 and Tank13. However, ingredient A is only outputted from Tank13 in Figure 13a. In the third circle (from s to s), 180 mL ingredient A flows into Tank13. In Figure 13b, 540 mL ingredient B flows into TankC1 from Tank21 from s to s and 180 mL of ingredient B flows into TankC1 from Tank23. The ratio of ingredient A to ingredient B is not 1 and liquid C can not be produced. At the beginning of the fourth circle, the TankC1 is not empty, but users still obtain the wrong product.

Figure 13

Measurements from sensors under attack case 2.

5.3.3. Case 3

Figure 14 describes the real values of sensors under attack case 3. The change in the amount of ingredient B is normal in Figure 14b. Unlike in Figure 10a, Figure 14a shows that the change in the amount of ingredient A in Tank13 is abnormal. When turning off pump p13 occurs before turning on pump p13, the ingredient A will be outputted continuously from Tank13. At , users can not obtain the liquid C because of false ratio. At the beginning of the second circle, the liquid in TankC1 still exists and liquid C is still not obtained. It also fails to obtain liquid C at the third circle, the fifth circle and the sixth circle because the amount of ingredient A in Tank13 is zero.

Figure 14

Measurements from sensors under attack case 3.

5.3.4. Case 4–Case 6

Figure 15 describes the sum of the amount of supplied energy or the sum of the amount of energy obtained by consumers under attack cases 4–6. In Figure 15a, we show the sum of the amount of energy obtained by consumers under attack case 4. Compared with the situation in Figure 11d–f, we can find that at the 7th circle and the 8th circle, consumers can not buy energy. That is because when the central controller turns on the switch w1 to output energy, energy in the storage system of supplier s1 is zero because of attacks. In Figure 15b, we also show the sum of the amount of energy obtained by consumers under attack case 5. Compared with the situation in Figure 11d–f, we can find that in the first circle, consumer c1 can not buy energy. That is because when attacks occur, the switch s1 is not turned on and energy can not be outputted. In Figure 15c, the sum of the amount of energy supplied by supplier s1 is shown. We can clearly see that supplier s1 does not output energy at the first circle, which enables consumers to turn off some appliances. Moreover, supplier 1 loses a large amount of energy in the interval from time to time .

Figure 15

Impact of attack case 4, attack case 5, and attack case 6.

The above six cases demonstrate that command disaggregation attacks can lead to disruptions of physical process and create great impact.

5.4. Effectiveness of Our Detection Framework

We employed java to implement the detection framework described in Section 4, where every component is described as a Java class and we use MySQL Database software as the correlation database. Different components use functions to exchange information with the database. In each component, we add functions to implement the corresponding operations. We analyze the data from tank system in Figure 8 and energy trading system in Figure 9. The data is collected from the files that are written by tank system and energy trading system. The information comprises sensory data from sensors, commands from the central controller, and executed commands from the actuators. We set s. Data is collected from s to s under random orders of goods and energy purchase.

We check whether the proposed detection framework can effectively identify six attack cases. Two kinds of correlations are obtained by analyzing data. In Table 3, the correlations between a command and executed sub-commands are described. 14 correlations in scenario 1 and 12 correlations in scenario 2 are discovered. To mine correlations between sub-commands, we set parameters , , and . We can obtain 24 correlations in scenario 1 and 12 correlations in scenario 2 as shown in Figure 16. Any link between two sub-commands can denote two existing correlations between two sub-commands. For example, the correlations between two sub-commands, and , are described as where denotes the number of occurrences that is executed when is disaggregated at its outflow, and indicates the number of occurrences that is executed when is disaggregated at its outflow.

Table 3

Correlations between commands and executed sub-commands.

Command	Correlation	Scenario
pao	<pao,p11o>, <pao,p12o>, <pao,p13o>	1
pbo	<pbo,p21o>, <pbo,p22o>, <pbo,p23o>	1
pac	<pac,p11c>, <pac,p12c>, <pac,p13c>	1
pbc	<pbc,p21c>, <pbc,p22c>, <pbc,p23c>	1
pvo	<pvo,v11o>	1
pvc	<pvc,v11c>	1
Ooute	<Ooute,w1o>, <Ooute,w2o>, <Ooute,w3o>	2
Opute	<Opute,w4o>, <Opute,w5o>, <Opute,w6o>	2
Coute	<Coute,w1f>, <Coute,w2f>, <Coute,w3f>	2
Cpute	<Cpute,w4f>, <Cpute,w5f>, <Cpute,w6f>	2

Figure 16

Correlations between executed sub-commands. A link denotes two correlations between two nodes.

Table 4 displays the results of detection based on two types of correlations under six attack cases. Results show that when attackers launch a command disaggregation attack based on WCIA in scenario 1 at s, the correlation between sub-commands will be broken and the alarms are instantly shown. When an attack based on WCOA at s is launched in scenario 1, there does not exist a correlation between command and sub-command in the database and defenders can achieve the alarms instantly. When an attack based on FCS in scenario 1 occurs at s, there does not exist a correlation between command and sub-command . An alarm is issued until the disaggregation of the next command occurs at s. When attackers launch a command disaggregation attack based on WCIA in scenario 2 at s, the correlation between sub-commands will be broken and the alarms are instantly shown. When an attack based on WCOA at s is launched in scenario 2, there does not exist a correlation between command and sub-command in the database and defenders can achieve the alarms instantly. When an attack based on FCS in scenario 2 occurs at s, there does not exist a correlation between command and sub-command . An alarm is issued until the disaggregation of the next command occurs at s. These alarms can be obtained when false sub-commands are executed, and occur before disruptions of physical process. During the process, our detection framework does not issue false alarms, which demonstrates that our methods of correlation mining are effective.

Table 4

Broken correlations under attacks.

Attack Case	Alarm
1	<pao,p13o,p11o>, <pao,p13o,p12o>, <pao,p12o,p13o> at t=480 s
2	<pao,p22o> at t = 960 s
3	<pac,p11o> at t = 60 s
4	<Ooute,w1o,w2o>, <Ooute,w1o,w3o>, <Ooute,w2o,w1o> at t=0 s
5	<Ooute,w2f> att=0 s
6	<Coute,w1o> att=60 s

We also implement two other detection methods in [14,35] to detect six attack cases. Because false feedback data is injected into the state estimator, the detection method in [14] cannot identify six attack cases. The detection method in [35] also does not show any exception under the six attack cases because detectors use commands from the central controller.

To better illustrate the performance of the proposed detection framework, we randomly launch attacks based on WCIA, WCOA, and FCA in scenario 1 and scenario 2. Every type of attack is launched many times at the different time. We find that attacks based on FCA and WCOA can be identified with 100% accuracy in two scenarios. Attacks based on WCIA in scenario 1 can be identified with 95% accuracy because some elaborately constructed attacks enable the correlation between two sub-commands not to be broken. An example will be described in Section 6. 47.5 % attacks based on WCIA in scenario 2 can be identified. It is lower than the accuracy in scenario 1 because there does not exist a correlation among sub-commands and . When correlations can not be mined among sub-commands, attacks based on WCIA may not be detected. For the detection of the above attacks, the detection framework does not issue any false alarm.

The experiments demonstrate that the detection framework can effectively identify many command disaggregation attacks, and can find anomalies before disruptions of physical process occur.

6. Discussion of Detection Framework Enhancement

This section discusses further improvement measures for the defects of our detection framework.

Difficulties of correlation mining. A large number of linear relationships exist among data of complex IIoTs [36], however, the relationship between two sub-commands may be nonlinear, which can increase the difficulty of identifying command disaggregation attacks. Thus, the detection framework can utilize other methods, such as information theory [35] to identify nonlinear relationships, which can be decided by defenders.

The futility of detecting elaborately constructed attack sequences. Experiments in Section 5 have shown the effectiveness of the detection framework. While the priest climbs a post, the devil climbs ten. Hence, if attackers launch attacks based on WCIA without breaking correlations between sub-commands, the proposed detection framework may not issue an alarm. For example, when the system in Figure 8 attempts to output ingredient A by merely opening a pump, attackers can open two pumps to output additional ingredient A, which can conduct false ratio of ingredient A to ingredient B. When the normal sub-command sequence is and attackers continuously manipulate the sub-controllers to issue command sequence , correlations among sub-commands are not broken. To cope with the tricky attack, defenders can improve the performance by mining correlations among more types of data, e.g., mining the linear relationship between the number of opening pumps that output ingredient A and the number of opening pumps that produce ingredient B. The numbers are equal in the normal situation, but the relationship is broken under the above attacks and an alarm can be issued.

7. Conclusions

In this study, we focus on the command disaggregation attack and its detection method. We describe three attack models to implement command disaggregation attacks in two kinds of modes. The examples of the tank system and energy trading system demonstrate that command disaggregation attacks in two modes can cause severe damage to physical process and an effective detection method is necessary. We also provide a novel framework to detect command disaggregation attacks. The framework utilizes the correlations between commands and sub-commands to identify anomalies. The two cases demonstrate that our detection framework can identify undetected command disaggregation attacks by the existing detection methods with high accuracy if there exist corresponding correlations among commands and sub-commands. Besides that, our method can identify anomalies before a fault occurs. In future, we will strengthen the detection framework to detect command disaggregation attacks in more complex IIoTs.