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.


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.

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.

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. (ii) 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. (iii) 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.

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. 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 C(t) = {c 1 , ..., c n } are issued simultaneously from the central controller at time t. After multi-tier sub-controllers disaggregate these commands, sub-commands AC(t) are executed by the actuators. c i denotes a kind of command and AC(t) denotes the executed sub-commands, which are defined in subsequent description of the system model.

System Model
where C matrix ∈ R nd×nd is the constant matrix. S(k) ∈ S denotes the evaluated state at time k, and under normal circumstances, S(k) = S(k). Ts(k) ={ts 1 (k), ..., ts nd (k)} T where ts i (k) denotes the value of time series ts i at time instant k. • AC = {AC 11 , ..., AC ij , ..., AC mn } is a set of sub-commands executed by actuators. AC ij = {ac ij (1), ..., ac ij (N)} T indicates the executed sub-commands by actuators when command from the central controller is c i and the system state is s j . Element ac ij (k) 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. AC(t) = {ac i 1 j 1 (1), ..., ac i N j N (N)} T denotes the executed sub-commands when the corresponding commands C(t) are issued from the central controller. AC(i, t) is an element of AC(t) and denotes the sub-command executed by the ith actuator. The system state at time t, S(t), is decided by S(t − d t ) and AC(t − d t ) [14], which can be described as where A ∈ R nd×nd and B ∈ R nd×N are constant matrices. d t indicates the time interval between the time t when current commands are issued and the time of its last outflow. • Re = {r 1 , ..., r m×n } is a finite set of relationships among commands and system states.
indicates that the executed sub-commands are AC ij when the system state is s j and the command from the controller is c i .
.., f s y } is a subset of set S. A disruption occurs when the system state is f s i .
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 subCom(c i ) to denote a set. Any element x ∈ subCom(c i ) satisfies where s j is any possible system state when command c i is issued.
To describe the attack models, we define two operations about sets, "−" and "+". For any two sets Q 1 and Q 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.

Wrong Command Allocation
When a command c i is disaggregated at system state s k , the sub-commands may be sent to false actuators or changed to other sub-commands leading to a situation that sub-commands AC ik are changed to AC jl . 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 AC ik to the false sub-commands AC jl ∈ subCom(c i ). Wrong command outer allocation occurs when attackers change AC ik to false sub-commands AC jl / ∈ subCom(c i ). In Figure 2, an example is shown to explain the two situations. c1, c2, c3, c4 are commands from the controller, and s1, s2 are physical system states. Commands at different system states can turn on/off valves. When the current command is c 1 and the system state is s 1 , 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. Next, we depict the attack models that implement the above two situations.
(1) Attack model based on wrong command inner allocation (WCIA) 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: Controller n-1th tier sub-controller nth tier sub-controller nth tier sub-controller ...  •

Information collection
Attackers first find a set of issued commands C(t), command c i , state s k , and state s l satisfying Equation (4). •

False data injection
When attackers discover that the current state is s k and command c i will be disaggregated, attackers inject bad feedback data into sub-controllers in charge of the disaggregation of c i and inform them the current state is s l . 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 AC ik to AC il . A disruption occurs when AC il are executed because the system state becomes s m ∈ Fs. To go undetected as described before, attackers again inject false feedback data after AC il was executed, which needs to change the state from s m to s i (s i = A × s k + B × AC(t)). 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) 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 C(t), commands c i and c j , state s k , and state s l satisfying Equation (5). •

Command modification
We use Rear(c i ) to denote the disaggregated commands of c i by the middle-tiers sub-controllers. Unlike the wrong command inner allocation, attackers first change the commands Rear(c i ) to Rear(c j ) when c i has been disaggregated as Rear(c i ), 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 s l . The real situation is s k . 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 AC jl were executed by actuators, attackers should also re-inject false feedback data to confuse the controller. The state should be changed to s i (s i = A × s k + B × AC(t)).

False Command Sequence
Under normal situations, if c i is executed before c j is issued from the central controller, then actuators should first execute sub-commands from the disaggregation of c i . Sub-commands from the disaggregation of c j then are executed. From the controller's point of view, < c i , c j > stands as sequential commands, however, the actuators execute the sequence < c j , c i > when attacks based on false command sequence occur. To achieve the target, attackers need to delay the disaggregation of command c i , meanwhile, inform the controller that c i has been executed and command c j should be issued from the controller. After c j is executed, c i is disaggregated. For example, in Figure 2, under the normal situation, the controller first issues the command c 1 at the system state s 1 , and then issues the command c 3 . If c 3 is disaggregated before c 1 is disaggregated, the false command sequence occurs.
As shown in Figure 4, the attack model (FCS) is described as follows: •

Time-delay attack
Attackers manipulate the sub-controllers to delay the disaggregation of c i . The disaggregation of c i begins after the sub-commands from the disaggregation of c j are executed.

•
False data injection are executed, the real physical system state is changed from s k to s h . Because the current state is not s l , the controller does not issue the commands C(t). Thus, attackers inject false data into sensors to induce false state estimation. The controller issues the commands C(t) when it obtains the false state s l . After sub-commands AC(t) from the disaggregation of C(t) are executed, the state becomes s n . To enable command c i to be disaggregated, attackers again inject false data to tell the controller and sub-controllers that the current state is s i . When the sub-commands AC ii is executed, the real state is changed from s n to s m 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 s i .

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.

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.

• 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 < C(k), k, AC(k), t AC(k) >, where t AC(k) = {t AC(k) (1), ..., t AC(k) (N)}, and t AC(k) (i) means the time when sub-command AC(i, k) ∈ AC(k) 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.  Figure 5. The structure of detection framework.

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.

Correlation between a Command and Sub-Commands
If executed sub-command ac ij (k) can be obtained by the disaggregation of command c l , there exists a correlation between command c l and sub-command ac ij (k), denoting as < 1, c l , ac ij (k) >. 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 P ac ij (k) (c l , ac ij (k)): denotes the ratio of the number of occurrences that ac ij (k) is executed when command c l is disaggregated, to the number of occurrences that command ac ij (k) is executed. It can be computed as where N(c l , ac ij (k)) denotes the number of occurrences that c l is issued from the controller and ac ij (k) is executed by the actuator in an effective time interval T interval . N ac ij (k) means the number of occurrences that sub-command ac ij (k) is executed by the kth actuator. The value of T interval depends on the characters of physical system and transmission delay. At the beginning of correlation mining, there exist many 4-tuples {< C(1), 1, AC(1), t AC(1) > , ..., < C(k), k, AC(k), t AC(k) >, ..., < C(T), T, AC(T), t AC(T) >}. The latter support ratio between any executed sub-command AC(k, l) = ac ij (l) and any command c i ∈ C is computed by analyzing these 4-tuples. For any sub-command ac ij (l), 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:  where Cd is a set of commands and it is equal to C when correlation mining between sub-command ac ij (l) and commands begins.
Phase II: correlation validation. In the second phase, the correlation analyzer judges whether there exists a correlation between c m and ac ij (l).
We use Sd(ac ij (l)) to denote the set that comprises correlations related to ac ij (l) that have been validated. If c m does not satisfy Equation (7), the correlation exists and we add the correlation < 1, c m , ac ij (l) > into set Sd(ac ij (l)). If c m satisfies Equation (7), the correlation does not exist. After that, c m is removed from set Cd.
where T(c m , ac ij (l)) is the set containing all time intervals from the time of issuing command c m to the time of executing ac ij (l) in history data, for example, [k, t AC(k) (l)] is an element of T(c m , ac ij (l)). The two phases are executed repetitively until set Cd is null.

Correlation among Executed Sub-Commands
If Equation (8) is satisfied for executed sub-commands ac mn (i) and ac pq (j) that are correlated to command c l , a correlation exists between ac mn (i) and ac pq (j), denoted as < 2, c l , ac mn (i), ac pq (j), θ * >. θ * means θ(c l , ac mn (i), ac pq (j)). 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 ac mn (i) is executed by the ith actuator and the number of occurrences that ac pq (j) is executed by the j th actuator when command c l is issued at its kth outflow. ε is the error threshold. p n , p m , 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 After computing θ * , we will validate whether (8) is satisfied for any k ∈ [max(p m , p n ) + 1, N]. When (8) is satisfied for any k, the correlation exists. Otherwise, there does not exist a correlation between ac mn (i) and ac pq (j). 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 ac mn (h) ∈ AC(k) from the input four-tuple {C(k), k, AC(k), t AC(k) }, if we can not find a command c i ∈ C(k) to ensure that correlation < 1, c i , ac mn (h) > exists in the database, then an alarm will be issued. For any correlation < 2, c l , ac mn (i), ac pq (j), θ * >, if c i = c l (c i ∈ C(k)), the exception detector will verify whether the correlation is broken under the new command c i and sub-command AC(k). If an existing correlation is broken, an alarm is issued .

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.

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.

Group Operational Systems
Central Controller Tank11  Tank12  Tank13  Tank21 Tank22 Tank23 TankC1 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. 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 M × 3 × 2 × 100 mL liquid C within T = 3 × M + 240 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 (pao), turning off the pump that outputs ingredient A at time M s (pac), turning on the pump that outputs ingredient B at time M + 60 s (pbo), turning off the pump that outputs ingredient B at time 2 × M + 60 s (pbc), opening the valve that outputs liquid C at time 2 × M + 180 s (pvo), and closing the valve that outputs liquid C at time 3 × M + 240 s (pvc). The process is executed repetitively if users have a new order of goods. When the sub-controller will output M × 3 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 M × 3 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 M × 3 × 4 × 100 mL liquid C within 3 × M + 240 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 60 × 6 × 3 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.

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.
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.  At the beginning of every circle, consumers sent their demands K × 500 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 (Ooute), turning on the switch that inputs energy at time 0 s (Opute), turning off the switch that outputs energy at time K s (Coute), turning off the switch that inputs energy at time K + 10 s (Opute). 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 60 × 6 × 500 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.

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 60 × 3 × 2 × 100 mL, 60 × 3 × 4 × 100 mL, and 60 × 3 × 6 × 100 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 60 × 500 w (one consumer) and 60 × 2 × 500 w (two consumers). We also show the normal measurements of sensors with the change of time under random orders of energy in Figure 11.  Six attack cases are described as follows: Attack case 1 in scenario 1: When the controller issues command pao, 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 t = 960 s, the controller issues the command pao 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 t = 0 s, the controller issues command pao and attackers launch attacks based on FCS. Malicious entities first manipulate sub-controller sc-22 not to disaggregate command pao. Command pao is disaggregated after command pac is disaggregated at t = 60 s.
Attack case 4 in scenario 2: When the controller issues command Ooute, 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 t = 0 s, the controller issues the command Ooute 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 t = 0 s, the controller issues command Ooute and attackers launch attacks based on FCS. Malicious entities first manipulate sub-controller sc-11 not to disaggregate command Ooute. Command Ooute is disaggregated after command Coute is disaggregated at t = 60 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 Figures 10 and 11. 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 t = 480 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 10, ingredient A in Tank12 and Tank13 is normal. From t = 960 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 t = 960 s to t = 1440 s), 180 mL ingredient A flows into Tank13. In Figure 13b, 540 mL ingredient B flows into TankC1 from Tank21 from t = 960 s to t = 1440 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 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 t = 480, 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 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 t = 60 to time t = 260.  Figure 15. Impact of attack case 4, attack case 5, and attack case 6.

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

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 T interval = 60 s. Data is collected from t = 0 s to t = 3 × 10 6 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 p n = 0, p m = 2, and ε = 1. 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, p11o and p13o, are described as F(pao, p11o, t) = 0.75F(pao, p13o, t) − 1 + 0.25F(pao, p13o, t − 1) F(pao, p13o, t) = 0.65F(pao, p11o, t) + 1 + 0.35F(pao, p11o, t − 1) where F(pao, p11o, t) denotes the number of occurrences that p11o is executed when pao is disaggregated at its t th outflow, and F(pao, p13o, t) indicates the number of occurrences that p13o is executed when pao is disaggregated at its t th outflow. Coute 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 t = 480 s, the correlation between sub-commands will be broken and the alarms are instantly shown. When an attack based on WCOA at t = 960 s is launched in scenario 1, there does not exist a correlation between command pao and sub-command p22o in the database and defenders can achieve the alarms instantly. When an attack based on FCS in scenario 1 occurs at t = 0 s, there does not exist a correlation between command pac and sub-command p11o. An alarm is issued until the disaggregation of the next command occurs at t = 60 s. When attackers launch a command disaggregation attack based on WCIA in scenario 2 at t = 0 s, the correlation between sub-commands will be broken and the alarms are instantly shown. When an attack based on WCOA at t = 0 s is launched in scenario 2, there does not exist a correlation between command Ooute and sub-command w2 f in the database and defenders can achieve the alarms instantly. When an attack based on FCS in scenario 2 occurs at t = 0 s, there does not exist a correlation between command Coute and sub-command w1 f . An alarm is issued until the disaggregation of the next command occurs at t = 60 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. < 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, w2 f > at t = 0 s 6 < Coute, w1o > at t = 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 w4o, w5o, w6o, w4 f , w5 f , and w6 f . 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.

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 {< p11o, t = 0 >, < p12o, t = 480 >, < p13o, t = 960 >} and attackers continuously manipulate the sub-controllers to issue command sequence {< p11o, t = 0 >, < p12o, t = 0 >, < p13o, t = 480 >, < p11o, t = 480 >, < p12o, t = 960 >, < p13o, t = 960 >}, 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.

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.