Defending Electrical Substations against 0-day Malware through Decoy I/O in Protective Relays Julian L. Rrushi Department of Computer Science Western Washington University Bellingham, Washington 98225–1420 Email: [email protected]

Abstract—Recent cyber attack campaigns, such as those supported by the BlackEnergy and Dragonfly malware, have targeted protective relays over the network. Protective relays are the ultimate attack target as they interface directly with physical lines and equipment in electrical substations. A compromised relay allows the attacker to operate circuit breakers, and thus disrupt the transmission and distribution of power. Malware that implement control theoretical models can cause and also maximize physical permanent damage to the power equipment. We present a defensive deception approach that operates on the protective relays of an electrical substation. We use kernel drivers on a protective relay to create dynamic decoys, which consist of emulated I/O boards and their hardware controllers. A phantom I/O board is operated in conjunction with closely monitored memory buffers that are accessible in user space. We store in those buffers dynamic decoy data associated with the phantom substation equipment and processes that the phantom I/O board appears to interface with. Those data are generated and stored as per the IEC 61850 protocol, and can be retrieved over the MMS and OPC protocols. Our approach mimics a protective relay’s interaction with segments of the electrical substation, which in fact are all decoys. Our approach can detect 0-day malware on protective relays in production, without any prior knowledge of their internal code and data. We performed practical validations against malware samples involved in recent cyber attack campaigns, and discuss the findings in the paper.

I. I NTRODUCTION We present a line of work that aims at disrupting and investigating cyber attacks on electrical substations. Those attacks are typically implemented as self-propagating industrial control system (ICS) malware. A knowledgeable attacker can program ICS malware to cause physical destruction of power grid equipment, or silently conduct cyber espionage to prepare for one. Those are operations that were performed by the BlackEnergy and Dragonfly malware campaigns, respectively. BlackEnergy enabled attackers to access protective relays in electrical substations over the network. Those accesses allowed for operating circuit breakers to cause power outages to several large regions [1]. Dragonfly did not attempt physical alterations of the electrical power grid, however it conducted extensive cyber espionage on every industrial computer it could compromise. The reader is referred to the Symantec’s findings on Dragonfly discussed in [2]. Contribution. The main idea of this work is to project the existence and operation of substation equipment and processes over protective relays in production, i.e. not honeypots. Those

segments of the electrical substation do not exist for real, but are made to appear so to ICS malware. As attacks arrive, our tools intercept those attacks to detail. The main contribution of this paper is a phantom I/O board and associated controller, which enables the defender to deliver that deceptive projection in practice. The phantom I/O board is operated in conjunction with closely monitored memory buffers, which create an attack surface for ICS malware to target. Of course, ICS malware could interact directly with a target I/O board on a compromised protective relay, as most of them do. In that case, our approach can easily intercept the attack as well, as we show later on in this paper. We describe the approach with specific reference to the Windows Embedded Standard, which is one of the most widely deployed operating systems that run on protective relays [3]. Novelty. To the best of our knowledge, this work is the first to explore deception mechanisms that reside on a protective relay in production. The closest related work is the concept of industrial honeypot [4], [5]. Honeypots provide limited defensive deception against sophisticated attacks and skilled attackers, which are to be expected if the attack is state sponsored. Honeypots are characterized by limited or even absence of system and network activity, while protective relays are constantly in action, by reading from sensors, processing data, reporting to operators, and writing to actuators. Industrial process control is a very intense operation. The substation data that are stored on flash or transmitted over the network obey the laws of physics behind the physical processes that take place in an electrical substation. Honeypots do not have the intelligence to reproduce the typical control system activity for the purpose of defensive deception, while allowing the exposed dynamics to evolve consistently in compliance with the laws of physics that govern the physical processes in an electrical substation. Organization. The remaining of this paper is organized as follows. In Section II we describe the main ideas of our approach, as well as its architecture and main techniques. In Section III we describe an evaluation of the effectiveness of our approach in a testbed that resembles an electrical substation. In Section IV we discuss related work on antimalware techniques for field devices such as protective relays and programmable logic controllers (PLCs). Section IV also compares our approach with malware for field devices eth-

ically developed by related academic or industry works. In Section V we summarize our findings, and conclude the paper. II. A PPROACH A. Decoy I/O Virtual equipment with no real counterparts. The IEC 61850 protocol [6] enables a protective relay to create and maintain virtual representations of all physical equipment of an electrical substation. IEC 61850 uses objects and attributes that resemble closely the composition and parameters of each piece of physical equipment. Objects are stored in memory, where they can be operated upon by code. All modifications are then propagated to the physical space. As the parameters of operation of a physical component change, its virtual representation in the memory of the protective relay is updated accordingly based on data provided by sensors. Just like the legitimate code running on a protective relay, ICS malware can recognize and hence access physical equipment and processes, which are its ultimate targets. With IEC 61850, target discovery by ICS malware is straightforward. Before IEC 61850, when protective relays used only bit-oriented protocols such as the distributed network protocol (DNP3) [7], target discovery required more work, but was certainly doable. The main idea behind our approach is to create dynamic decoy objects in the memory of a protective relay by the means of an I/O controller, such as to make those objects appear as virtual substation equipment, but at the same time not associate them with any real counterparts in physical space. We call such decoy virtual equipment an industrial mirage, and illustrate it in Figure 1. More specifically, we create decoy logical nodes for physical equipment and protective relay functions. A logical node is the concrete mechanism by which IEC 61850 virtually represents a real piece of equipment or function. Logical nodes are grouped according to the function that they carry out in the electrical substation. In this work we run decoy logical nodes of the switchgear group, namely virtual circuit breakers (XCBR) and virtual circuit switches (XSWI). We also run decoy logical nodes from the power transformers group, such as YPTR. Decoy logical nodes from the protection functions group, sensors and monitoring group, and metering and measurement group, are run in this work as well. An illustration helps. Figure 1 depicts a power transformer and a circuit breaker, both of which exist and operate in an electrical substation. A protective relay runs protection and control algorithms that work with virtual representations of those two pieces of equipment, as modeled by an YPTR logical node and an XCBR logical node, respectively. All modifications to those YPTR and XCBR logical nodes are propagated to their physical counterparts by the means of a I/O board controller. Digital-to-analog conversion integrated circuits are used to convert the discrete numerical values of logical node attributes into electrical signals, which in turn operate on the physical power transformer and circuit breaker. The parameters that characterize the state of the physical power transformer and circuit breaker are measured

Fig. 1. Industrial mirage of a power transformer and a circuit breaker.

by sensors, which feed the data to the I/O board controller after having converted them from analog to digital. The sensing and actuating operations on the physical power transformer, as well as the explicit YPTR and XCBR logical nodes stored in the memory of the protective relay, make the physical power transformer and circuit breaker clearly visible to ICS malware running on the protective relay. Now, the upper part of Figure 1 shows an emulated I/O board controller that enables protection and control code to operate through decoy YPTR and XCBR logical nodes. The emulated I/O board controller mimics the way YPTR and XCBR logical nodes drive and mirror the physical power transformer and circuit breaker. In reality, these two pieces of equipment do not exist, yet they appear as valid targets to ICS malware. For consistency reasons, decoy protection and control algorithms appear to maintain and use the decoy YPTR and XCBR logical nodes as if they were functional. B. Approach Engineering A decoy I/O interface board is projected in the kernel. A typical protective relay has a main I/O board and one or more I/O interface boards. Since the main I/O board is supposed to be single, it leaves no space for projecting another (decoy) main I/O board. Consequently, we mimic the presence and operation of I/O interface boards. It is also possible that a protective relay may not have I/O interface boards at all, which leaves ample room for decoy I/O interface boards. We project an I/O board on a protective relay by emulating an I/O board controller in the kernel of the operating system. The emulation code is structured as shown in Figure 2. The controller of a real I/O board is a special-purpose microprocessor that operates and manages that I/O board. Since in our case the I/O board

Fig. 2. Driver stack of the phantom I/O board based on components from [9].

is a decoy, there is no real hardware for it, consequently we work solely at the kernel driver stack level. We developed a kernel driver, which mimics the work of a real kernel driver of the kind that operate a real I/O board controller, except for the interaction with the underlying hardware. The driver stack of an I/O board controller, as well as that of any I/O device in general, is an ordered list of device objects, each of which is linked with the driver object of a kernel driver. A device object is a C struct that describes an I/O device and represents it to a driver, whereas a driver object is a C struct that represents the image of a driver in memory [8]. The I/O requests that read data from the I/O control inputs of an I/O board, for example phase current measurements, or write data to its I/O control outputs, for example to trip the circuit breaker, are packaged into data structures called I/O request packets (IRPs) [8]. An IRP is self-contained, in the sense that it contains all the data that are necessary to describe an I/O request. A decoy function driver drives emulation rather than actual HW. IRPs originate from a component of the Windows kernel called I/O manager. As an IRP traverses the driver stack top to bottom, it is processed along the way by the drivers in the driver stack of the I/O board controller. Once the IRP is fully processed by those drivers, and hence reaches the bottom of the driver stack, the driver at that level populates its payload with data from the I/O control inputs of the I/O board if the IRP was a read. If the IRP was a write, the driver at hand

initiates the write operation through the I/O board controller. If the I/O board controller were real, both a read and a write would result in the driver at hand sending a command to the I/O board controller. A specific field in the IRP, which is called major function code, denotes whether the operation is a read or write. The IRP then climbs back up the driver stack until reaching the I/O manager, which in turn responds to the caller, i.e., the code of protection and control algorithms, by passing status and/or substation data. With reference to Figure 2, IRPs are received by a decoy function driver. In general, a function driver is a driver that manages an I/O device or hardware bus. The function driver has the most knowledge of how that I/O device or bus operates, and hence is able to present the interface of that I/O device or bus to the I/O system in the kernel. The device object of the decoy function driver is a function device object (FDO), unlike the device object of the underlying driver, which is a physical device object (PDO) [8]. The decoy function driver, which to some extent functions as an I/O board controller driver, does not send commands to a real I/O board controller, nor does it receive any data from a real I/O board controller. Instead, the decoy function driver drives a defensively deceptive emulation of the I/O board controller, as depicted in Figure 3. The decoy function driver configures a set of pins of the phantom I/O board controller, which appear to serve as data channels connected to the I/O control inputs or to the I/O control outputs of the phantom I/O board. The IRPs that reach the decoy function driver request to read from, or write to, one or more of those pins. This is how sensing and actuating is performed on substation equipment, and is included in the emulation. The decoy function driver is based on a Microsoft sample driver, namely SimGpio, which is provided as part of the Windows Driver Kit (WDK) [9], and is implemented using the kernel-mode driver framework (KMDF) [10]. The decoy function driver manages a general-purpose I/O controller, and adds additional processing such as to mimic the driving of an I/O board controller. The memory buffers associated with the phantom I/O board controller store raw decoy data, which are then modeled as IEC 61850 logical nodes. Mechanics of the emulation. The emulation of an I/O board controller is implemented in a separate kernel module, which is tied closely to the decoy function driver. The mechanics of the emulation are depicted in Figure 3, where an intelligent electronic device (IED) refers to a protective relay. Once the decoy function driver receives an IRP that requests to access the phantom I/O board in reading or writing, it constructs a proper command, which it then sends to the I/O board controller emulation module. The command may instruct the phantom I/O board controller to read a buffer from memory (actuating physical equipment), or to write a buffer to memory (sensing physical equipment). Consequently, we emulated a direct memory access (DMA) controller as well. If the IRP carries an actuating request, the DMA controller emulator fetches the actuator data from the buffer, and makes those data available to the I/O board controller emulator. The I/O board controller emulator works with a phantom I/O

Fig. 3. Defensive I/O board emulation on protective relays.

board, which is all emulated as well. The I/O board controller emulator writes those data to the I/O control outputs of the phantom I/O board, which leads to changing the parameters of the industrial mirage of substation equipment. If the IRP carries a sensing request and hence asks to read the I/O control inputs of the phantom I/O board, the decoy function driver sends a read command to the I/O board controller emulator. The decoy function driver provides also the address of a buffer, where the sensor data are to be stored, along with the read command. The I/O board controller in turn works with the I/O board emulator to read the requested sensor data from the I/O control inputs of the phantom I/O board. The I/O board controller sends the collected sensor data to the DMA controller emulator, which writes them to the requested buffer in the memory of the protective relay. At this point, the sensor data are finally loaded into the attributes of IEC 61850 logical nodes. C. Symmetrical Decoy Data Traversals Sensor data and actuator commands are targeted in flight. Shortly after initiating physical damage to their targets, several ICS malware samples involved in cyber attack campaigns, as well as ICS malware developed by academia for research purposes, intercept and hence modify the data that describe the operational status of industrial processes

& equipment. These are the data that are displayed on the human-machine interface (HMI) machine for human operators to see and possibly act upon. As a result of the altered data, human operators are deceived into assessing that the digitally controlled physical system is running correctly and safely, while in reality its industrial processes and equipment experience physical disruption. The attacker’s goal is to delay the operators’ responses to halt the physical destruction caused by ICS malware, until it is too late. ICS malware may intercept and modify, or simply suppress, actuator commands as well, before they reach the I/O board controller. Suppression is as dangerous as alteration. For example, a circuit breaker that is not tripped when needed may result in physical destruction of substation equipment. Putting symmetrical decoy data in flight. Symmetrical decoy data are synthetic sensor measurements or actuator commands that originate at a source, travel in protective relay’s memory along paths that are similar to those traversed by real data, and then possibly reach a destination. The concept is illustrated in Figure 4. If a piece of synthetic data leaves its source with one value, and then upon arrival at the destination it is discovered that the piece of synthetic data itself or a derivative piece of data thereof has an inconsistent value, the conclusion is that the piece of synthetic data has been modified in flight. If synthetic data or derivatives alike never arrive at

also use the decoy I/O board controller to generate synthetic sensor measurements such as to portray physical process dynamics that urge an intervention by the decoy protection and control application. The synthetic data can drive IEC 61850 logical nodes in the protection functions group, for example directional comparison (PDIR), distance protection (PDIS), and directional overpower (PDOP). The driving of those IEC 61850 logical nodes should result in specific actuator commands being issued by the decoy protection and control application towards the decoy I/O board controller. Knowledge of both the synthetic sensor measurements and the logic of the decoy protection and control application allows us to determine the specific actuator commands that the application should be issuing. If an actuator command that arrives at the decoy I/O board controller is not one that we were expecting, or does not arrive at all, we can conclude that the actuator command was modified or suppressed while in flight, respectively. Fig. 4. Symmetrical decoy data traveling over the attack surface.

III. VALIDATION

their destination, then the conclusion is that those data have been suppressed. The trajectories of synthetic data traverse the protective relay’s execution environment, where ICS malware can intercept them as well as real sensor measurements and actuator commands. This is referred to as attack surface in Figure 4 and is marked by chevrons. The phantom I/O board controller provides synthetic sensor measurements to a decoy protection and control application, which resembles its real counterparts in actual production on the protective relay. The synthetic sensor measurements come from the I/O control inputs of a phantom I/O board. Knowing the logic of the decoy protection and control application allows us to determine the status data that the application will send to human operators. Those data in fact only appear to be sent to the human operators, because in reality they are not. The decoy protection and control application sends the status data over a decoy network interface card (DNIC), which we have explored in previous work. The reader is referred to [11] for the details of the architecture and implementation of a DNIC. Once the status data in question reach the miniport driver of a DNIC, i.e. the lowest driver in its driver stack, we check that they match the synthetic sensor measurements that originated in the decoy I/O board controller. It is the DNIC that generates synthetic actuator commands, which it delivers to the decoy protection and control application. Those commands appear to have been sent by human operators over the network. Again, since we know the logic of the decoy protection and control application, we can determine the specific actual commands that the application will apply to a mirage of physical equipment. The decoy protection and control application sends those commands to the decoy I/O board controller. We check that these data are received, in which case we further check that they match the synthetic actuator commands that originated in the DNIC. We can

A realistic testbed. We created a computer environment that is similar to that of a real-world electrical substation. The protective relays in the testbed were all real. Their main characteristics are summarized in Table I. More specifically, the SEL-487E-3 is a protective relay that can monitor and protect a power transformer from electrical faults. It runs intelligent algorithms to detect various types of faults, and can take action in a timely manner by operating electrical circuit breakers and disconnect switches. The SEL-421-4 can perform industrial automation functions. It includes 32 programmable elements for local control, remote control, automation latching, and protection latching. A SEL-421-4 can also conduct various functions to protect overhead electrical transmission lines and underground cables. The SEL-3355 conducts multiple substation functions too. It has an integrated HMI, with a local display port. In this work, the SEL-3355 was used as a real-time automation controller. The SEL-3355 polls the SEL-487E-3 and SEL-421-4 to collect substation data from them. The network communications between these ICSs take place over the IEC 61850 protocol. IEC 61850 is a virtual protocol, and thus cannot be used alone for concrete network communications. It needs an actual carrier protocol. Consequently, IEC 61850 is typically mapped to a protocol stack comprised of the Manufacturing Messaging Specification (MMS) [12], TCP/IP, and Ethernet. MMS was designed specifically for transferring in real time physical process data and supervisory commands. MMS has object models and services that can easily accommodate those of the IEC 61850 standard. Testbed included OPC. We integrated an engineering server into the testbed. The engineering server hosted an Object Linking and Embedding (OLE) for Process Control (OPC) protocol server [13], which in turn ran an IEC 61850 protocol driver to get substation data from the protective relays. The IEC 61850 protocol driver subsequently stored those substation data in the OPC server as data items. We

TABLE I T HE PRINCIPAL TESTBED MACHINES AND THEIR MAIN INDUSTRIAL COMMUNICATION PROTOCOLS . Machine SEL-3555 SEL-487E-3 SEL-421-4 General-purpose Windows server General-purpose Windows client General-purpose Windows machine

ICS function Automation controller, HMI visualization, data concentrator Transformer protection relay Protection, automation, and control system OPC server OPC client Development and testing

added an OPC client machine to the testbed as well. The OPC client application had a graphical user interface for a human operator to enter commands using keyboard and mouse. All the machines in the testbed were connected on a local area network, which was physically and logically isolated from any other networks due to safety concerns. We validated this work against ICS malware samples involved in the Dragonfly cyber espionage campaign. There are many versions of those ICS malware. We obtained those malware samples from public research malware repositories and used them in our experiments. Remote sensor measurement extraction. The various versions of the Havex ICS plugin are of particular interest to this work, since they all use OPC. We ran the ICS malware samples on the OPC client machine one at a time, and observed whether or not our approach would detect each sample. All ICS malware samples that we ran managed to discover the engineering server. They connected to the OPC server, and collected over OPC the substation data originating in the protective relays over IEC 61850. Some of the OPC data items, which were accessed by the ICS malware, were connections to the I/O control inputs of a phantom I/O board and hence were coupled with attributes of decoy IEC 61850 logical nodes. Locally to the targeted protective relay, the requests to read decoy sensor measurements resulted in the I/O manager generating IRPs. Those IRPs were subsequently sent to the decoy function driver depicted in Figure 2, which intercepted the attack. A sample of data seen by the decoy I/O board controller is plotted in Figure 5. Remote actuator command injection. BlackEnergy used a keylogger module to intercept keystrokes. It intercepted VPN credentials on compromised machines in the enterprise network of a target utility company, and subsequently used those credentials to access substation networks over a VPN. All this enabled attackers to run rogue SCADA client software on the compromised machines, through which they sent remote commands onto an electrical substation similarly to how human operators do [1]. We replayed the BlackEnergy attacks and thus sent remote commands over the network to the protective relays in our research testbed. The remote commands tripped circuit breakers. Although in the BlackEnergy case study an attacker and a legitimate operator intervene on an electrical substation in similar ways, in this work there is a key difference between the two. In prior work we designed and developed a filter driver, which we integrated into the driver stack of the monitor that

ICS protocol IEC 61850 IEC 61850 IEC 61850 OPC, IEC 61850 OPC OPC, IEC 61850

Fig. 5. A data sample traversing the driver stack of the decoy I/O board controller during an active sensor measurement extraction.

is attached to the machine used by the legitimate operator. The filter driver removes any decoy I/O entries, before they are displayed on the monitor for the human operator to see. Consequently, a human operator does not see the industrial mirages in our research testbed, unlike the network intruder who sees all equipment, real and decoy. Some of the circuit breakers tripped by the remote commands were industrial mirages. Eventually the actuating requests reached the decoy I/O board controller, asking to access I/O control outputs of the phantom I/O board, which led to immediate detection. The data encountered by the decoy I/O board controller are somewhat similar to those plotted in Figure 5, except for the number of requests being fewer, and the data sizes being generally much smaller. The plot is not given due to room limitation. Local attacks. We emulated the data interception phase of an ICS malware attack on a protective relay, as well as direct readings of sensors along with injections of commands bound for its actuators. The test code modified an actuating command on the fly shortly after it was issued by a decoy protection and control application. The attack was detected as the actuating command that arrived at the decoy I/O board controller did not match the actuating command that the application was driven to issue. In another test, the test code captured an actuating command, and zeroed it out in the buffer without ever releasing

Fig. 6. A sample of time overhead over time.

it. This other attack was detected because the decoy I/O board controller was expecting the actuating command, which never arrived. Same results were obtained when the actuating command originated in the DNIC before being modified on the fly or entirely suppressed. Same results were also obtained when sensor measurements were manipulated or denied. Direct interactions with sensors and/or actuators resulted in the decoy I/O board controller receiving requests that our approach had not generated itself, leading to detection. No false positives. Because of the filtering of decoy entries, human operators cannot operate on, or interact with, industrial mirages. Overhead. When the protective relay is not under attack, the execution overhead fluctuates between 100 and at most 300 picoseconds. Most of it is due to putting symmetrical decoy data in flight. When under attack, the execution overhead increases to under 1.5 nanoseconds due to the large volume of I/O requests and replies that the decoy I/O code has to process. A sample of overhead measurements is given in Figure 6. The data pertain to a time window that begins with no attack, then continues with a sensor measurement extraction, then continues further with no attack, and then continues further with an actuating command injection, and finally ends with no attack. These execution overheads are insignificant for protective relays. IV. R ELATED W ORK Anti-malware techniques for field devices. The Memory Heat Map (MHM) proposed by Yoon et al. is a machine learning approach that discovers memory patterns in the operating system of a real-time embedded machine. The authors indicated that multiple attack scenarios, which included kernel rootkits and shellcode, had memory usages that deviated from normal patterns. MHM is based on the premise that real-time embedded applications are of a predictable nature [14]. IEDs may not quite match that profile. Various protection functions

are only exercised when the electrical substation requires a safety intervention. Those events make computations on an IED quite intense. Their occurrence and the memory usage they cause are unpredictable. IEDs that use IEC 61850 may have complex configurations, which create highly diverse memory usages. A human operator may also interact with an IED, which makes memory usage exhibit unpredictable patterns. Zimmer et al. use checkpoints based on timing bounds, which are preliminarily set on code sections of legitimate applications on real-time systems, to detect the exploitation phase. The authors’ work focuses on code injection exploits, and is proposed as an alternative to address-space layout randomization (ASLR) and canary approaches such as StackGuard, which the authors deem to be ineffective on realtime systems [15]. Nevertheless, data injection exploits, such as those based on return-oriented programming (ROP), are able to use existing application code and thus comply with checkpoints and their timing bounds. The authors’ work relies on code instrumentation and time validation checks, both of which add runtime overhead that breaks the timing of Sampled Values and possibly the timing of SCADA in electrical substations. The limits on application recovery time range from 800 ms for SCADA to 400 µs for Sampled Values, while the limits on communications recovery time range from 400 ms for SCADA to nearly 0 for Sampled Values [16], [6]. These are too tight of a time constraint to easily accommodate additional instructions in the code of protection and control algorithms on IEDs. Violations of the timing requirements create unsafe conditions, as they disturb the physics of substation equipment and hence result in physical damage. Power usage monitoring is another technique proposed to detect ICS malware. The idea is to characterize the power consumption of normal applications, and then look for fluctuations. This technique is based on the premise that ICS malware will have a power consumption that breaks preestablished patterns [17]. The power consumption capability would need to be integrated into the hardware of a control system and thus requires hardware modifications. An IED, however, can be highly dynamic and variable in the operations that it runs, therefore its power consumption may vary in an unpredictable way. For example, an IED consumes a largerthan-usual amount of power when responding to the adverse effects of a tree that has fallen on the power lines, and very little power when it only scans sensors for new data. An abrupt spike in power consumption may be caused by ICS malware that has just started or resumed its execution on the IED, or the IED taking corrective actions to protect the electrical substation from the anomalies caused by the fallen tree. Power consumption alone cannot tell. Academic ICS malware vs. decoy I/O. Several academic ICS malware are discussed in open literature. Garcia et al. designed Harvey as a PLC rootkit. Harvey performs a man-inthe-middle interception of sensor measurements and actuator commands. Harvey simulates internally the power system

and thus is aware of its physics. Harvey does so for two reasons. Firstly, to change actuator commands such as to maximize the physical damage to the power system. Secondly, to change sensor measurements so that human operators receive data that they would expect to see based on the history of their interaction with the power system [18]. PLC-Blaster by Spenneberg et al. is a PLC worm that communicates with a command and control server and also searches for targets over the network. PLC-Blaster can modify I/O and render a compromised PLC dysfunctional by violating its cycle time limit [19]. Our approach can detect Harvey and PLC-Blaster through symmetric data traversals. Any alterations of sensor data and/or actuator commands result in mismatching hashes. PLC ghost by Abbasi and Hashemi uses a pin control attack on a PLC to take over the control of a physical process [20]. The attack works by altering a set of registers that determine the behavior of the I/O interface. PLC ghost is detectable by our approach since a pin control attack causes direct interaction with a target controller, which in this case is a decoy. Our approach can also detect the Aurora attack [21], which attempts to open a circuit breaker and then close it out of synchronism. Synchronism in this context refers to coordinating parameters of a power generator such as frequency, voltage, and phase rotation, with the current state of the electrical power grid. The phantom I/O board allocates an output that is mapped to a decoy XCBR logical node, and hence forming a decoy circuit breaker. Any access to the decoy circuit breaker leads to the detection of the malicious code. V. C ONCLUSION Decoy I/O has potential to effectively detect 0-day ICS malware on protective relays in production. On one hand, ICS malware need to access the I/O control inputs and outputs of an I/O board, as that is the cyber way of discovering and physically manipulating an electrical substation. On the other hand, in this work we engineered a phantom I/O board and associated controller that showed potential to make it quite challenging for malware to discern decoy I/O from real I/O. Our approach injects a large amount of uncertainty into the target selection process of ICS malware. None of the ICS malware samples involved in recent cyber attack campaigns that we tested against our approach were able to operate undetected. Furthermore, the inner workings of ICS malware developed for academic or industrial research purposes fall into the traps of decoy I/O. In conclusion, decoy I/O is a usable security tool due to its safety measures with respect to the application and communications recovery time, as well as separation from real code and data on a protective relay. ACKNOWLEDGMENTS This research is sponsored by the Air Force Office of Scientific Research and the U.S. Air Force Academy Center for Cyberspace Research under agreement number FA7000-16-20002. The U.S. Government is authorized to reproduce and distribute reprints for Government purposes notwithstanding any copyright notation thereon.

The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Air Force, Department of Defense, or the U.S. Government. R EFERENCES [1] R. M. Lee, M. J. Assante, and T. Conway, ”Analysis of the Cyber Attack on the Ukrainian Power Grid”, defense use case white paper, March 2016, Available online at https://ics.sans.org/media/E-ISAC SANS Ukraine DUC 5.pdf [2] Symantec, ”Dragonfly: Cyberespionage Attacks Against Energy Suppliers”, July 2014, Available online at https://www.symantec. com/content/en/us/enterprise/media/security response/whitepapers/ Dragonfly Threat Against Western Energy Suppliers.pdf [3] J. Harrell, ”Reliability Achieved With Windows Embedded Standard on SEL Tough Computers”, Schweitzer Engineering application note, AN2010-08, 2011. [4] D. I. Buza, F. Juhasz, G. Miru, M. Felegyhazi, and T. Holczer, ”CryPLH: Protecting Smart Energy Systems from Targeted Attacks with a PLC Honeypot”, Smart Grid Security, vol. 8448, pp. 181–192, August 2014. [5] L. Rist, J. Vestergaard, D. Haslinger, A. De Pasquale, and J. Smith, ”CONPOT ICS/SCADA Honeypot”, Available online at http://conpot. org [6] International Electrotechnical Commission, ”IEC 61850: Communication Networks and Systems in Substations”, part 1 through 9, 2004. [7] DNP Technical Committee, ”Distributed Network Protocol”, Available online at https://www.dnp.org [8] M. E. Russinovich, D. A. Solomon, and A. Ionescu, ”Windows Internals, Part 2”, 6th edition, Microsoft Press, September 2012. [9] Microsoft Windows Driver Kit Team, ”Driver samples for use with Microsoft Visual Studio and the Windows Driver Kit”, Available online at https://github.com/Microsoft/Windows-driver-samples [10] P. Orwick and G. Smith, ”Developing Drivers with the Windows Driver Foundation”, 1st edition, Microsoft Press, May 2007. [11] J. Rrushi, ”NIC displays to thwart malware attacks mounted from within the OS”, Journal of Computers and Security, vol. 61, issue C, pp. 59-71, August 2016. [12] International Organization for Standardization, Technical Committee 184, ”Manufacturing Message Specification”, Available online at https://www.iso.org [13] J. Lange, F. Iwanitz, and T. Burke, ”OPC - From Data Access to Unified Architecture”, 4th edition, VDE VERLAG GMBH, 2010. [14] M. K. Yoon, S. Mohan, J. Choi, J. E. Kim, and L. Sha, ”Memory Heat Map: Anomaly Detection in Real-Time Systems using Memory Behavior”, Design Automation Conference, San Francisco, CA, USA, June 2015. [15] C. Zimmer, B. Bhat, F. Mueller, and S. Mohan, ”Time-based Intrusion Detection in Cyber-Physical Systems”, In ACM/IEEE International Conference on Cyber-Physical Systems, pp. 109–118, Stockholm, Sweden, April 2010. [16] R. Hunt, and B. Popescu, ”Comparison of PRP and HSR Networks for Protection and Control Applications”, Western Protective Relay Conference, Spokane, WA, October 2015. [17] PFP security, ”Analyzing Power Consumption to Detect Malware”, SCADA Security Scientific Symposium, Miami, FL, USA, January 2017. [18] L. Garcia, F. Brasser, M. H. Cintuglu, A. R. Sadeghi, O. Mohammed, and S. A. Zonouz, ”Hey, my malware knows physics! Attacking PLCs with physical model aware rootkit”, Annual Network & Distributed System Security Symposium, San Diego, CA, USA, February 2017. [19] R. Spenneberg, M. Brggemann, and H. Schwartke, ”PLC-Blaster: A Worm Living Solely in the PLC”, Black Hat, Las Vegas, Nevada, USA, July 2016. [20] A. Abbasi, and M. Hashemi, ”Ghost in the PLC: Designing an Undetectable Programmable Logic Controller Rootkit via Pin Control Attack”, in Black Hat USA, 2016. [21] M. Zeller, ”Myth or Reality - Does the Aurora Vulnerability Pose a Risk to My Generator?”, 64th Annual Conference for Protective Relay Engineers, College Station, Texas, April 2011.