A SCADA (Supervisory, Control And Data Acquisition) system is a cyber network of communicating devices used for instrumentation and control of a distributed infrastructure, such an electric power grid, in order to manage the respective physical processes. The SCADA system of a power grid can monitor and control various electric equipment along the power delivery path — including various transformers, circuit breakers, protective relays and automatic re-closers — while acquiring different measurements, which provide information about the loading conditions at different parts of the power grid and the health conditions of transmission lines, etc. Hence, correct operation of a SCADA system is critical to the reliability of any power distribution system.
A successful malicious attack targeting at the SCADA system could potentially cause extensive power outage. However, most of the SCADA systems currently in active use have been deployed for decades and very few of them were originally designed with security in mind [14, 17, 23]. These legacy SCADA systems were assumed to operate in isolation at first, with obscurity and physical isolation being the main security strategy. But nowadays, this design assumption is challenged not only by new security threats — including demonstrated break-in’s of power substations , discovered worms on PLCs (Programmable Logic Controllers) and other industrial control system platforms [12, 18], and the exposure of supposedly obstructed documents (such as SCADA system configuration and operation manuals) on the Internet  — but also by the changing operational model which desires a higher level of integration with relatively open systems , such as the AMI (Advanced Metering Infrastructure), in the envisioned smart grid for data sharing and orchestration of process control.
In particular, legacy SCADA systems are typically vulnerable to forged data or commands sent from intruding or compromised devices (i.e. insider attacks) [8, 14, 17]. For instance, a compromised SCADA RTU (Remote Terminal Unit) could launch the false command attack whereby an attacker impersonates the master station to send false control commands to other RTUs, say, to maliciously trip a particular circuit breaker. On the other hand, false readings from compromised instrumentation devices could present a distorted picture of the system status to the master station, thus triggering false alarm and possibly disruptive action . Currently, most legacy SCADA systems could have little defense to this kind of attacks as no source authentication or command verification mechanism is in place [1, 14, 17]. Implementing cryptographic defence on the old-generation devices in these SCADA systems is impossible due to their resource constraints, and protection has to resort to the bump-in-the-wire approach  which is generally regarded as very inefficient. The increasing connectivity of these legacy SCADA systems with external smart grid systems, which have comparatively more open access, could increase the attack surface for attackers to compromise devices inside the SCADA systems or send forged data or commands directly from outside. Nonetheless, these legacy SCADA systems will take decades to be phased out from operation since they are so highly integrated with the power equipment they monitor . It is thus essential to devise mechanisms to safeguard legacy SCADA systems as they are increasingly integrated with newer smart grid systems.
This paper discusses and compares two different strategies to secure legacy SCADA systems for safe integration with smart grid systems. Both approaches do not require any modification on the devices or communication channels and are scalable for different number of devices. The first approach, called the “data diode” approach [5, 19, 24], is commonly adopted in the industry and aims to preserve the isolation of a legacy SCADA system while facilitating outward information flow to the newer smart grid system. The second approach aims to open up a legacy SCADA system for bidirectional information flow, with mechanisms in place to detect and identify false commands sent by intruding devices or compromised nodes. This paper proposes a high-level, architectural framework for the second approach to implement a detect-and-respond strategy to neutralize the effects of false command attacks on a SCADA field network. While this paper focuses on false command detection based on verification against an authenticated copy of commands received through a secure channel, the framework provides a general basis for incorporating other attack detection methods [8, 13, 7] as well to implement a defence strategy. This paper will also compare the applicability and usability of the two approaches.
The contributions of this paper is two-fold. First, a generic architectural framework is proposed to implement the detect-and-respond strategy for the defence of legacy SCADA systems against false command attacks, with a view to opening up these SCADA systems for integration with the relatively more open smart grid systems. The proposed technique is non-intrusive and truly add-on without requiring modifications on existing devices and systems. It is also scalable in the sense that only one defending device is needed per field network. To demonstrate the practicality of the proposed framework, an instantiation of the detect-and-respond strategy on the Siemens Sinaut 8FW protocol  — an common industrial protocol for legacy SCADA systems — is presented with experimental results. Second, this paper presents a comprehensive review of the current landscape of the research in legacy SCADA system protection. It compares the data diode and detect-and-respond approaches for legacy SCADA system protection, discussing their benefits and limitations, and provide practical guidelines for their application.
The rest of this paper is organized as follows. In the next section, legacy SCADA systems and false command attacks against them are discussed. The data diode strategy and the detect-and-respond strategies are presented in Section 3 and Section 4 respectively. Finally, a conclusion with a comparison of the two strategies is given in Section 5.
2 Background on False Command Attacks against Legacy SCADA Systems
A typical SCADA system, as depicted in Figure 1, consists of PLCs (Programmable Logic Controllers) and RTUs in older versions and IEDs (Intelligent Electronic Devices) in newer versions as the basic units for deployment in power substations or remote sites (for monitoring transmission lines) at different geographic locations. Each of these field devices has interfaces to sensors and actuators used to monitor and control equipment in a power delivery system. The field devices in a substation or remote site form a local network, known as the field network, and are usually connected together over a broadcast medium to a sub-master or data concentrator, which in turn is connected to the MTU (Master Terminal Unit) or master station at the main control center through leased lines over the telecom operator’s network. While various topologies are in use for connecting field devices with the sub-master, a broadcast channel — such as EIA-485 serial ports in party-line mode over a pilot cable (as shown in Figure 2) or DNP3 in multi-drop or data concentrator mode111Earlier SCADA systems were designed based on proprietary protocols. DNP3 is a standard adopted in newer SCADA systems to provide a protocol specification for connecting RTUs and IEDs with a MTU. Details can be found at http://www.dnp.org. — is typically used in SCADA systems.
Despite the cost efficiency achieved in cable layout and maintenance, the use of broadcast channels also eases insider attacks from compromised devices. For example, a compromised RTU can pose the MTU to issue a forged command to another RTU or PLC, causing the latter to behave abnormally. Experiments have been repeatedly reported to demonstrate the possibility of using off-the-shelf protocol analyzer software to intercept control messages and inject false commands in some legacy SCADA systems , with some showing the possibility to trip a circuit breaker maliciously. In a few cases, even though the circuit breaker signaled the master station it had opened, the master station did not respond because it had not instructed the circuit breaker to open.
This type of attacks was inconceivable in the original design of SCADA systems, and SCADA devices have little resource to defend against them. Obscurity in system design, command formats and operation, combined with physical isolation, have long been the main and possibly the only strategy for securing legacy SCADA systems. However, the effectiveness of obscurity may have become unreasonable. For instance, it has been demonstrated that fuzzing can effectively discover or recover unknown SCADA commands of a SCADA device . Physical break-in’s to power substations have been occasionally reported . Even worse, obscurity and isolation are no longer effective in the envisioned smart grid, wherein SCADA systems have to coexist and possibly communicate with other relatively open networks, in order to implement two-way flow of information and energy. Operation in isolation could be an overly strong assumption for SCADA systems to operate nowadays against the backdrop of the smart grid.
Exploitation of software vulnerabilities on field device computing platforms is a necessary, key step to compromise field devices in a SCADA system. This is the only possible way which allows an attacker to install his code on a target machine and spread it to others. The belief that embedded processors used in field devices have relatively less exploitable software vulnerabilities or it is difficult to compromise an embedded system has become untenable, as demonstrated by the case of the Stuxnet worm discovered in 2010, which has a rootkit to infect PLCs over a proprietary SCADA system and damaged a number of centrifuge equipment in an Iranian nuclear facility [12, 18]. Subsequent generations of Stuxnet were also discovered. In fact, it has been demonstrated that with crafted instructions and data, compromising an embedded processor is within reach to attackers in general. These compromises could normally go undetected by the MTU since, as demonstrated by the Stuxnet worm, a compromised device could play man-in-the-middle to conceal all malicious activities from the MTU.
In addition, should a physical break-in to a substation or remote site be possible, an attacker could simply tap in his own attacking devices directly onto the SCADA network to manipulate other innocent devices. With the increasing connectivity with other systems in the smart grid, this threat is particularly real since these newer smart grid systems typically have more open access points to general users. For instance, a smart meter may be accessible to a household user’s computer for reading meter data and setting consumption patterns and alerts. Similarly, an electric vehicle charging station in a public car park could have a digital interface open for the general public for functionalities like making reservation or checking charging status of an electric vehicle.
3 Data Diode Approach
A data diode is a unidirectional gateway, similar to a firewall, which sets a digital barrier to enforce network perimeter control for a restricted network (such as SCADA systems) to fend off unwanted accesses from less secure networks (smart grid systems) it is connected to. Yet a data diode provides a stronger security guarantee than a firewall since strict one-way communication — from the restricted network to the less secure network only — is enforced by a certain physical law rather than digital logic, with little chance of reverse communication. Data diodes are often built using fibre optics coupler or transceivers, through the removal of the transmitter component from one side of the communication and the respective receiver component from the opposite side.222Although different hardware implementations of a data diode exist, supporting different physical channels (e.g. RS-232, EIA-485, USB, Ethernet) most make use of optical couplers to guarantee physical isolation. This makes it physically impossible to compromise such devices to achieve reverse connectivity. Moreover, they usually do not contain firmware, thus requiring minimal or no configuration at all, or have minimal software supported by micro-kernels that can be formally verified. Whereas, firewalls are often prone to configuration mistakes and relatively accessible for exploit by skilful attackers. While firmware upgrade is regularly needed in firewall maintenance, patching is seldom needed for data diode deployment. Finally, data diodes are the only devices receiving the EAL7 (Evaluation Assurance Level 7), the highest grade in the Common Criteria (an international standard evaluating the level of security of equipment).
Data diodes allow organisations to retrieve valuable data generated at the process level from a critical infrastructure for consumption by a wider group of users in a relatively more open system while assuring the isolation and integrity of the critical infrastructure. As shown in Figure 3, a data diode allows data acquired by SCADA field devices to be pulled out from the SCADA system so that they can be combined with other datasets captured by smart grid systems like AMI and EV (Electric Vehicle) systems which poll the physical conditions of the same electric power grid, in order to give a more holistic and precise picture of the conditions of the electric power grid for more accurate data analysis and hence resource planning. The correlation of these different datasets can also provide valuable insights for fault identification and predictive maintenance. Should the analysis lead to desired actions to be carried out in the SCADA system, the feedback will be through human communications. While existence of compromised nodes is possible in the smart grid systems, the data diode guarantees that they cannot send in false commands to field devices in the legacy SCADA system or infect/compromise them.
Despite similarities in the isolation mechanism, commercially available data diode solutions differ in supported services and protocols. In order to support TCP/IP-based SCADA protocols, such as MODBUS/TCP and DNP3, data diodes usually have to make use of additional software components for each side of the unidirectional link to emulate the bidirectional message flow for the three-way handshake and acknowledgements needed in a typical TCP session. As shown in Figure 4, the software components include an application proxy and a protocol breaker . The application proxy emulates the TCP server on the sender side to respond to the SCADA device (TCP client) with TCP connection-oriented messages and acknowledgements while forwarding messages from the TCP client to the unidirectional link. Similarly, the application proxy emulates the TCP client on the receiver side. But it does not forward any message from the TCP server on the receiver side to the unidirectional link. Note that only TCP connection messages sent from the SCADA system to the smart grid system are allowed by the data diode. The protocol breaker acts as a middleware for packet encapsulation and possibly applying encryption and forward error correction to data transferred over the unidirectional link. Forward error correction is especially important to ensure correct data delivery for the noisy environment of typical SCADA systems.
4 Detect-and-Respond Approach
While data diodes provide strong security and isolation/decoupling assurance for legacy SCADA systems, sometimes they are too restrictive for certain application scenarios of the smart grid. Neither is it optimal to rely on human communications for feedback to a SCADA system. There is a realistic need for two-way flow of data between a SCADA system and a smart grid system. Proposals such as  therefore emerged to add a reverse channel to data diodes. But whether the advantages of a data diode over a typical firewall can be preserved in such a modification is highly uncertain. More importantly, to what degree that the security assurance of a data diode is undermined with the addition of a reverse channel needs to be assessed carefully. In scenarios requiring bidirectional data exchange between a SCADA system and a smart grid system, it is therefore more reasonable to assume the existence of compromised devices in the SCADA system [8, 11, 13, 7, 14, 17, 18] and devise mechanisms to detect false commands [8, 11, 13, 14] and/or identify compromised nodes [14, 17]. In general, a detect-and-respond strategy is preferred despite that many of the proposed schemes in the literature merely cover attack detection. Once a false command is detected, its impacts should be voided or neutralised promptly, and ideally, in an automatic manner with minimum human intervention required.
We present a generic, high-level architectural framework to implement the detect-and-respond strategy for legacy SCADA systems. An embodiment in the form of a trusted protection agent is also given to illustrate typical steps needed to neutralise the effects of false commands injected by compromised field devices. The notion of the protection agent is similar to that of a trust node in . The difference is that the protection agent actively neutralises the effects of false commands, whereas, the trust node only serves as a trusted routing agent to selectively relay messages between field devices and the master station. Since the framework is defined in a general setting, it should be applicable to different types of SCADA protocols and provide a basis for systematically crafting defence mechanisms fit for different SCADA systems and field devices. Besides, there is also flexibility for incorporating different detection algorithms or mechanisms such as [8, 13] into the framework.
4.1 Protection Agent
As depicted in Figure 5, a protection agent is installed as an add-on device in each field network of a SCADA system, which can be made up of with PLCs, RTUs or IEDs. Leveraging on the broadcast medium typically found in most field networks, the protection agent — as a network sniffer — monitors commands issued to all the field devices on the network to detect malicious activities. As a safe assumption, the protection agent is generally a much more powerful machine than typical field devices, given that the underlying processor used in the protection agent could be generations away from those used in the field device of a legacy SCADA system. In addition, compared to the low-bandwidth physical channel used by these field devices (typically, in the range of 1.2-19.2 kbps [21, 15, 23]), the protection agent can easily be equipped with a wireless link of much higher bandwidth to the MTU or master station. We can therefore assume that the protection agent has a faster (with a higher bandwidth and a lower latency) and typically more reliable communication channel (for most of the time) with the MTU than the field devices. On the basis of a more powerful machine with a faster communication channel to the MTU, security hardening on the protection agent is much easier. We assume that the protection agent has a secured, authenticated channel with the master station. Multi-factor entity authentication (for example, those based on pre-shared secret keys stored in a tamper-resistant device, physical unclonable functions [20, 10], or even new approaches  etc.) could be adopted to implement this authenticated channel to strengthen its security assurance. Compared to the field device platforms with little resources for the implementation of cryptographic defence, the protection agent is more ready to implement cryptographic algorithms and protocols, as well as, other security mechanisms requiring more resources (such as firewall or remote code attestation). In short, the protection agent can be viewed as a trusted proxy for the MTU.
On the other hand, the protection agent can be seen as a reliable incognito for the MTU, monitoring what is happening in the field network. The previously observed problem of some legacy SCADA systems that the MTU is not aware of a circuit breaker having been tripped by an attacker since it has not initiated the tripping  would not happen if a protection agent is installed in the field network. When the protection agent observes the tripping command in the field network but does not receive the same command through the trusted communication channel shared with the MTU, it would report the tripping event back to the MTU, which would then be aware of a possible intrusion. While there is possibility that an attacker might physically remove the protection agent from a field network, security mechanisms could be implemented on the protection agent to detect any malicious removal. For instance, the MTU can run a challenge-response verification protocol with the protection agent by sending a sequence of specially crafted random messages (destined at a void device identity) to the protection agent via the field network; if the protection agent is disconnected from the field network, it would not be able to receive these messages to respond to the MTU’s challenge correctly. Besides, remote code attestation could be implemented to provide the assurance that the software being executed on the protection agent has not been tampered with. It should be emphasized that a protection agent offers more resources and flexibility than a typical field device like an RTU or PLC for implementing preventive security measures and intrusion detection mechanisms.
4.2 Detect-and-Respond Defence of Protection Agent
|Queue||State to queue newly received SCADA and authenticated commands||read commands from the receiving port queue the command to the SCADA or authenticated queue accordingly|
|Listen||Idle state when the SCADA queue is empty||check if the SCADA queue is non-empty and trigger the “Start” state when the queue is non-empty|
|Start||State to tell between a new SCADA command received or an old SCADA command pending the completion and confirmation of corrective actions taken||check whether a new SCADA command arrives and trigger command verification if positive|
|Check Rule||State to check the local rule set to see if the received SCADA command is illegitimate and violates the prescribed rules||evaluate the SCADA command against the local rule set if the SCADA does not pass any of the rules, trigger the correction process. Otherwise, check the authenticity of the SCADA command|
|Verify Command||State to check whether the received SCADA command is really from the MTU through the use of the authenticated channel||if the SCADA command has a matched authenticated command received in the authenticated queue, issue a pass, otherwise, request the MTU to verify through the authenticated channel and check again if the SCADA command fails, trigger the correction process|
|Fight-back||State to correct or reverse the actions caused by a malicious command||look up from a pre-set table for the corrective actions needed for a particular SCADA command issue the listed SCADA commands to the affected RTUs to reverse the actions of the malicious command|
|Verify Correction||State to confirm the correction be in effect||read the status of the affected RTUs to confirm the corrective actions have been applied|
The detect-and-respond mechanism of the protection agent can simply be implemented as a finite state machine as shown in Figure 6. The basic idea is as follows:
Whenever the MTU issues a SCADA command to any field device, it also sends an authenticated message of the same command (protected by a certain cryptographic algorithm such as AES-CCM) to the corresponding protection agent which is connected to the same field network as the concerned field device is.
The protection agent listens or eavesdrops in the field network, sniffing all SCADA commands issued to the field devices in the same field network, and verifies the authenticity and integrity of each of these SCADA commands by comparing them with the authenticated commands directly received from the MTU in the authenticated channel shared between the protection agent and the MTU.
For any forged or false command detected (say, by comparing the command received in the field network and that received in the secured channel), the protection agent, possibly after verifying with the MTU, issues a SCADA command to the affected field device to reverse the action caused by the false command to cancel out any undesirable action initiated by the attacker. This is called the “fight-back” or neutralization mechanism as the protection agent takes action — in response to a detected malicious command — to correct it.
In principle, the neutralization mechanism could invalidate or void out forged commands, restoring the field device to the original state. But the degree of neutralization or residual effect of a false command would depend on the actual implementation of the logic and the SCADA command set of a field device. This defence approach shares some similarities with the fight-back mechanism of OSPF (Open Shortest Path First) — a link state routing protocol used in the Internet — through which an innocent router could publicly renounce a malicious route update forged by an attacker .
In case of missing commands, the protection agent can request the MTU to resend a command over the secured, authenticated channel for verification. Besides, the implementation of the protection agent could be further extended by including additional false command detection mechanisms beyond comparison with an authenticated copy of a legitimate command. For example, the detection mechanisms of [8, 13] can possibly be used by the protection agent to trigger neutralization, preferably after confirmation by the MTU. However, in order to respond correctly to any maliciously injected commands, the deployed detection mechanism should provide sufficient details to help identify the commands falsely injected by the attacker.
In some cases, a forged or malicious command could be immediately detected in the local field network without relying on authenticated messages from the MTU. For example, the remote software update of a field device is normally prohibited by most utility operators. However, in some SCADA systems composed of RTUs, the denial of a remote software update request is implemented on the MTU side only, while the RTUs in the field network usually have no mechanism to deny a software update request or distinguish whether it is initiated by the MTU or an intruding device. In other words, a compromised RTU or an intruding attacker device could still initiate a remote software update at any RTU in the same field network, which will not be denied by the latter. This flaw would greatly facilitate the spread of worms or malicious instruction sequences over a field network. In a typical SCADA deployment, a firewall usually only safeguards a field network from external attacks and would not be able to stop such an insider threat since the attack is launched from within the field network by a compromised field device or an intruding device connected to the field network. In contrast, the protection agent could possibly halt the malicious software update. A local rule set can be implemented on the protection agent, explicitly specifying that only manual update is allowed. When the protection agent detects an automatic software update command, it can immediately halt the update by issuing another command, without having to check with the MTU. On the other hand, unlike a firewall, the protection agent does not present a single point of failure. If the protection agent is down, the field network would still operate as usual, merely without protection by the protection agent, whereas, if a firewall is down, all communications between the field devices and the MTU would be interrupted.
The same technique can be used for other clearly harmful actions. For instance, the protection agent can enforce that a certain range of parameters is prohibited in some SCADA commands. With the local rule on protection agents, the damage of the centrifuge equipment caused by the Stuxnet worm could be avoided, since the command with parameters causing excessive spin speed could be invalidated by the protection agent. Similarly, the protection agent can be configured to eliminate or invalidate set point commands — which are used in typical SCADA systems to preset the thresholds on certain measured system variables (such as voltages or phase angles at certain point of a power grid) for triggering protective actions like tripping a circuit breaker — with harmful parameters.
In details, two command queues are implemented in the protection agent, which respectively stores SCADA commands received in the field network and authenticated commands received through the secured, authenticated channel between the MTU and the protection agent. When the SCADA command queue is empty, the protection agent is at the “Listen” state waiting for new SCADA commands. The arrival of a new SCADA command will trigger the protection agent to verify the authenticity of the requested action and reverse it in case it is a fake command. A list of tasks to be implemented at different states of the protection agent is shown in Table 1.
The detect-and-respond strategy deviates from intuition and standard techniques used in securing a communication network. Whereas existing schemes would suggest filtering all bogus messages injected by an attacker, the proposed mechanism aims to tolerate the intrusion for a while if the resulting malicious actions are not critically harmful and then correct or neutralize the malicious actions. For critical actions which are usually banned by norm, the local rule set in the protection agent would stop them immediately from onset. Since the detect-and-respond approach favors local, distributed defence, it is more scalable than centralized defence.
4.3 Example Implementation with Siemens Sinaut 8FW Protocol
|Telegram Type||Priority to neutralize||Protection agent’s actions to neutralize|
|control (Type 64) replace command (Type 195)||High||Topple the command Report the action back to MTU and wait for acknowledgement. If negative acknowledgement is received, topple the command back.|
|analogue/digital set point (Type 65-67/68-70) modification of threshold value limit (Type 205) modification of smoothing factor (Type 206) remote parameterization (Type 212)||High||Temporarily store a copy of the suspected command Apply the latest confirmed parameter setting stored in the protection agent to form a command Use replace command (Type 195) to switch the parameter setting back Report the action back to MTU and wait for acknowledgement. If negative acknowledgement is received, apply the stored suspected command, otherwise, erase stored command|
|start-up request (start up/restart) (Type 211) switch on/off recipient in master station (Type 203) switch off record transfer from/to station (Type 204)||Medium||Report to the MTU and wait for confirmation. If confirmed, topple the command.|
|switch on/off for temporal lists (Type 201-202) synchronization of fine time (type 207) setting of minutes (Type 208) setting of calendar (Type 209) switch on/off addresses in the lists (Type 210) 4-byte-storage interrogation control (Type 214) interrogation command ZFBIT and STOP-cause (Type 215-222)||Low||Report to the MTU and wait for confirmation. If confirmed, topple the command or restore the stored parameters.|
|check command (Type 192) check command (type 192) message repeat request / TFK-acknowledge (Type 193) start acknowledgement (Type 194) single/group interrogation command (Type 196-197) multiple request (Type 198-200) matrix-check command (Type 213)||Low||Neutralization is not necessary.|
Table 2 illustrates how the detect-and-respond defence strategy can be implemented with respect to the command set of the Siemens Sinaut 8FW protocol , a popular industrial protocol commonly used in legacy SCADA systems. The Sinaut 8FW protocol was the standard protocol used by Siemens devices and systems for communicating control and monitoring messages between MTU systems and RTU devices before being replaced by IEC 60870-5-101. It was broadly supported by devices provided by other manufacturers like ABB and GE. Each command is enclosed in a control message in the form of a telegram. Table 2 only shows telegram types sent in the control direction (from the MTU to field network), with other telegram types in the monitoring direction (from the field network to the MTU) skipped since these telegram types are largely for messages sent to the MTU.
False commands that may have critical impact on the functioning of a SCADA system are neutralized first and then verified with the MTU, whereas, the less critical ones are corrected upon confirmation from the MTU. Most of the neutralization actions can be readily implemented through the replace command telegram. For commands which switch on/off a certain feature or function, the neutralization can simply be done by toppling the command in the oppositive direction with respect to the false command. For commands which involve updating of parameters like thresholds or set points to trigger preventive actions, the protection agent stores the latest version of all the parameters of a field device (with parameters of different field devices stored in different tables) and apply relevant ones to form a replace command when necessary to revert the parameters affected by a false command.
Experimentation was carried out on an Intel 2.5GHz Quad Core Celeron CPU (with 8GB RAM) to estimate the time required to assemble a neutralization command or telegram for different types of false commands. The average time required to look up the parameters for a particular field device identity and form the neutralization telegram in response to different false commands is 3.21 ms with a standard deviation of 0.23 ms. Compared to the maximum tolerable delay for SCADA transactions, which is 0.54s, this processing delay is insignificant (which is only about 0.6% of the allowable SCADA transaction delay). It is fair to say that the bottleneck to satisfy the acceptable SCADA transaction delay constraint lies mainly in the network latency. For typical 4G mobile cellular networks, the latency is in the range of 20-50 ms — given that the length of SINAUT 8FW telegram is relative short ( bytes) and the transmission delay could therefore be ignored compared to the latency. The round trip delay could be less than 0.1s, and the overall delay for a neutralization action seems acceptable with respect to the upper limit of 0.54s.
4.4 Advantages of the Detect-and-respond Strategy
The detect-and-respond strategy embodied by the protection agent offers a number of advantages as follows.
Strong cryptographic mechanisms can be adopted to protect the communications between a field network and the MTU (via a protection agent), without replacing any field devices or modifying their code. This is truly an add-on approach. No laying of new cables is needed, as wireless links like 4G mobile cellular networks could be used between protection agents and the MTU. The protection mechanism is non-intrusive.
Compared to the bump-in-the-wire approach [1, 14] which adds a new cryptographic device per field device, a smaller number of protection agents are required, with one required for each field network in most cases. A typical field network could have at least 30 devices, meaning that the bump-in-the-wire approach requires at least 30 times in the number of new, add-on devices compared.
The protection agent would not become a bottleneck since additional protection agents can be deployed to a given field network. In such cases, the set of field devices in a network can be grouped into partitions based on their identities and multiple protection agents could be installed in the network with each responsible for a distinct partition. Since any number of protection agents can be added to a field network and the field devices need not be aware of the presence of a protection agent, the solution is scalable.
The detect-and-respond strategy is particularly effective to defending insider attacks, which existing solutions like firewalls often cannot withhold. A firewall normally cannot filter messages sent from a field device located behind it. Neither can it filter a forged message from outside if no authentication mechanism is in place.
The instrumentation and control of a power grid is usually carried out by a SCADA system which is a distributed network of cyber-physical devices taking measurements and issuing commands at different parts of a power grid. Obscurity and operation in isolation have long been the security strategy of SCADA systems. However, this is no longer a reasonable assumption for SCADA systems in the smart grid context with the need of connectivity with other relatively open networks. In particular, false command injection is a real threat to legacy SCADA systems. While effective security mechanisms and algorithms for command authentication are largely an overkill for implementation on field devices in legacy SCADA systems, these devices would normally take decades to be phased out as they are closely integrated with the power equipment. This paper discusses and compares two different approaches, namely, the data diode strategy and the detect-and-respond strategy, to secure legacy SCADA systems for safe integration with other smart grid systems. A detailed comparison of the two approaches can be found in Table 3.
|Security assurance||Highest (EAL7)||Medium to High|
|Applicable use cases||Limited range||Wide range|
|Pros||Isolation preserved with a high level of security No modifications on field devices required||Flexible to incorporate other techniques for attack detection and neutralization Allow bidirectional data exchange No modification on field devices required Scalable|
|Cons||Only allow unidirectional data flow from SCADA systems to other systems Little flexibility||More complex design required to maintain security Actual design strongly dependent on the SCADA protocols in use|
The detect-and-respond strategy proposed in this paper presents a number of advantages for securing legacy SCADA systems, including scalability and usability for a wide range of smart grid scenarios. The proposed framework is also generally applicable to different SCADA protocols and systems, while a concrete instantiation on Siemens Sinaut 8FW protocol is presented in this paper. While the data diode strategy offers the highest level of security guarantee, it can only be applied to a restricted number of use cases wherein unidirectional data exchange suffices. In contrast, the detect-and-respond strategy is a more flexible approach which can be applied in almost all scenarios but generally offer a lower level of security guarantee and is more complex to design.
-  R. Amoah and E. Camtepe, S. amd Foo. Securing DNP3 broadcast communications in SCADA systems. IEEE Transactions on Industrial Informatics, 12(4):1474–1485, July 2016.
-  C. L. Bowen, T. K. Buennemeyer, and R. W. Thomas. Next generation SCADA security: Best practices and client puzzles. In Proceedings of the 6th Annual IEEE SMC Information Assurance Workshop, June 2005.
-  S. Bratus, A Hansen, and A. Shubina. LZfuzz: A fast compression-based fuzzer for poorly documented protocols. Darmouth Computer Science Technical Report TR2008-634, September 2008.
-  A. C-F. Chan, J. W. Wong, J. Zhou, and J. C. M. Teo. Scalable two-factor authentication using historical data. In proc. ESORICS’16, Springer-Verlag LNCS vol. 9878, pages 91–110, September 2016.
-  M. B. de Freita, R. T. Cruz, and P. Simoes. SDN-enabled virtual data diode. In proc. SECPRE’18, CyberICPS’18, Springer-Verlag LNCS vol. 11387, pages 102–118, January 2019.
-  A. Hahn. Cyber security of the smart grid: Attack exposure analysis, detection algorithms, and testbed evaluation. Iowa State University Graduate Theses and Dissertations, 2013.
-  Md. M. Hasan and H. T. Mouftah. Optimization of trust node assignment for securing routes in smart grid SCADA networks. IEEE Systems Journal, 13(2):1505–1513, September 2018.
Y. He, J. Mendis, and J. Wei.
Real-time detection of false data injection attacks in smart grid: A deep learning-based intelligent mechanism.IEEE Transactions on Smart Grid, 8(5):2505–2516, May 2017.
-  E. Heine, H. Khurana, and T. Yardley. Exploring convergence for SCADA networks. In proc. ISGT’11, January 2011.
-  C. Herder, M-D. M. Yu, F. Koushanfar, and S. Devadas. Physical unclonable functions and applications: A tutorial. Proceedings of the IEEE, 102(8):1126–1141, August 2014.
-  A. Humayed, J. Lin, F. Li, and B. Luo. Cyber-physical systems security — a survey. IEEE Internet of Things Journal, 4(6):1802–1831, December 2017.
-  R. Langner. Stuxnet: Dissecting a cyberwarfare weapon. IEEE Security & Privacy, 9(3):49–51, May 2011.
-  H. Lin, A. Slagell, Z. T. Kalbarczyk, P. W. Sauer, and R. K. Iyer. Runtime semantic security analysis to detect and mitigate control-related attacks in power grids. IEEE Transactions on Smart Grid, 9(1):163–178, March 2016.
-  S. McLaughlin, C. Konstantinou, X. Wang, L. Davi, A-R. Sadeghi, and R. Karri. The cybersecurity landscape in industrial control systems. Proceedings of the IEEE, 104(5):1039–1057, March 2016.
-  Mobus. Mobus over serial line — specification and implementation guide v 1.02. Mobus Docummentation, December 2006.
-  G. Nakibly, A. Kirshon, D. Gonikman, and D. Boneh. Persistent ospf attacks. In proc. NDSS’12, February 2012.
-  S. Nazir, S. Patel, and D. Patel. Assessing and augmenting SCADA cyber security: A survey of techniques. Computers & Security, 70:436–454, September 2017.
-  A Nourian and S. Madnick. A systems theoretic approach to the security threats in cyber physical systems applied to Stuxnet. IEEE Transactions on Dependable and Secure Computing, 15(1):2–13, February 2018.
-  H. Okhravi and F. T. Sheldon. Data diodes in support of trustworthy cyber infrastructure. In proc. CSIIRW’10, pages 1–4, April 2010.
-  R. Pappu, B. Recht, J. Taylor, and N. Gershenfeld. Physical one-way functions. Science, 297:2026–2030, 2002.
-  Siemens. Sinaut st-7 station control system — system manual. SINAUT Docummentation, Edition 05/2001, May 2001.
-  K. Tweed. Bulletproofing the grid. IEEE Spectrum, April 2014.
-  A. K. Wright, J. A. Jinast, and J. McCarty. Low-latency cryptographic protection for SCADA communications. In proc. ACNS 2004, June 2004.
-  J-H. Yun, Y. Chang, Kim K-H., and W. Kim. Security validation for data diode with reverse channel. In proc. CRITIS’16, October 2016.