Towards a Cyber Defense Framework for SCADA Systems Based on PowerConsumption Monitoring ⇤

Jarilyn M. Hernandez⇤

Lane Dept. of ComputerScience and Electrical

EngineeringWest Virginia Universityjhernan7@mix.wvu.edu

Qian Chen, Chelsea Calhoun,and Summer Sykes

Department of Engineering:Computer Science TechnologySavannah State Universitychenq@savannahstate.edu

Je↵rey A. NicholsCyber and InformationSecurity Research Group

Oak Ridge NationalLaboratory

nicholsja2@ornl.gov

AbstractSupervisory control and data acquisition (SCADA) sys-tems are industrial automation systems that remotelymonitor and control critical infrastructures. SCADAsystems are major targets for espionage and sabotageattackers. Current commercial o↵-the-shelf security so-lutions are insu�cient in protecting SCADA systemsagainst sophisticated cyber-attacks. Furthermore, thesebreaches are not detected in real-time or fast enough toprevent further damages. To address this challenge wepresent a feasibility study that proves monitoring powerconsumption of SCADA devices is an e↵ective approachto detect cyber-attacks. We built a testbed containinga Programmable Logic Controller (PLC) that was in-strumented to record its power usage. Three SCADA-specific cyber-attacks were simulated and we report thepower consumption of the PLC under these normal andanomalous scenarios. We show that it is possible to dis-tinguish the PLC power utilization between these sce-narios. In route to this result we found and describevulnerabilities in the DF-1 protocol.

1. IntroductionSCADA (Supervisory Control and Data Acquisition)

systems refer to control systems that are used to moni-tor and control enterprise-wide operations of large-scaleand distributed critical infrastructures. For example,SCADA systems are widely used to monitor electricalassets (i.e., substations and transformer), telecommuni-cation facilities (i.e., switches and transmitters), waterand waste equipment (i.e., water pumps and valves) andoil and gas pipelines (i.e., gas pumps and valves). Usu-ally SCADA systems contain a set of devices such as sen-sors, actuators, programmable logic controllers (PLCs),remote terminal units (RTUs), human machine inter-

⇤This manuscript has been authored by UT-Battelle, LLC under Con-

tract No. DE-AC05-00OR22725 with the U.S. Department of Energy.The United States Government retains and the publisher, by acceptingthe article for publication, acknowledges that the United States Gov-ernment retains a non-exclusive, paid-up, irrevocable, world-wide licenseto publish or reproduce the published form of this manuscript, or al-low others to do so, for United States Government purposes. TheDepartment of Energy will provide public access to these results offederally sponsored research in accordance with the DOE Public Ac-cess Plan (http://energy.gov/downloads/doe-public-access-plan). Researchsponsored by the Laboratory Directed Research and Development Programof Oak Ridge National Laboratory, managed by UT-Battelle, LLC, for theU. S. Department of Energy.⇤Also affiliated with the Cyber and Information Security Research Group

at Oak Ridge National Laboratory

faces (HMIs), and master terminal units (MTUs).Attackers can compromise SCADA systems by ex-

ploiting vulnerabilities residing in security policies, soft-ware, communication channels, wireless channels, andsocial engineering. Recently, SCADA systems havebecome a target for cyber-attacks, according to a re-cent report from the Organization of American States(OAS) [1] , due to their potential impacts on properties,economies, and human lives. The annual threat reportfrom Dell shows that cyber-attacks against SCADA sys-tems increased from 91,676 to 163,228 between January2012 to January 2013 and increased to 675,186 at theend of January 2014 [2].

Specific, recent examples producing widespread dam-age include:

• In 2000, a disgruntled employee compromised theMaroochy Shire (Queensland computerized wastemanagement system) causing millions of gallonsof sewage spill into waterways, local parks andrivers [3].

• In 2010, a worm called Stuxnet [4] was detectedin Iranian uranium enrichment facilities. Thisworm increased the operating speed of the Ira-nian IR-1 centrifuge from 1,064 Hz to 1,410 Hzfor fifteen minutes before returning to its normalrunning frequency [5, 6]. This incident temporar-ily derailed Iran’s nuclear program by destroyingroughly 1,000 centrifuges.

• In 2013, a cyber-espionage group known as “Drag-onfly” used phishing sites and Trojans to compro-mise more than 1,000 energy supplier organiza-tions in Europe and North America [7].

In this paper, we demonstrate a new approach tomonitor and analyze the power consumption of aSCADA device (e.g., PLC) in order to detect SCADA-specific cyber-attacks. Our primary goal is to provethat there are detectable di↵erences in the power pro-files between normal behavior and behavior when undercyber-attacks. We describe a SCADA testbed that en-abled us to monitor and collect the power consumptionof a PLC under normal operations, command injectionattacks, denial of service attacks, and replay attacks.

The rest of this paper is organized as follows. Sec-tion 2 presents a literature review on detection tech-

2915

Proceedings of the 50th Hawaii International Conference on System Sciences | 2017

URI: http://hdl.handle.net/10125/41508ISBN: 978-0-9981331-0-2CC-BY-NC-ND

niques for identifying SCADA-specific cyber-attacks.Section 3 describes the experimental design (hardwareand software configuration). Section 4 introduces theapproach to collect PLC power consumption data. Sec-tion 5 validates our proposed approach by analyzingpower consumption data under various scenarios. Fi-nally, we present our conclusions and suggestions forfuture work in Section 6.

2. Related WorkThe SCADA-specific cyber-attacks introduced in Sec-

tion 1 show that traditional prevention mechanisms suchas firewalls and anti-virus software are not enough toprotect SCADA systems against sophisticated cyber-attacks. Researchers therefore are focusing on specifictechniques to defend SCADA systems in depth. For ex-ample, Chen et al. [8, 9] adopted the idea of autonomiccomputing and created self-protecting systems that canestimate known attacks before they impact devices inthe network. If an attack bypasses an Intrusion De-tection System (IDS), a second line of defense providespatterns of known attacks to an Intrusion Response Sys-tem (IRS). A controller in the IRS evaluates candidateprotection mechanisms considering pre-defined criteriaand then selects the optimal protection mechanisms toregulate system behavior back to normal. Unknown at-tack patterns were investigated by an online-learningmodule and were sent to the IRS similar to the knownattack scenario. As the result, the self-protecting sys-tems were validated to protect SCADA systems againstboth known and unknown attacks in near real-time withlittle or no human intervention.Rule-based signature techniques are commonly used

to detect SCADA-specific cyber-attacks. Particularly,this technique is often adopted to detect those cyber-attacks that interrupt, fabricate, intercept or modifycommunication messages between the HMI and PLC. H.Bao et al. [10] proposed a behavior rule-based method-ology monitoring devices in the smart grid for insiderthreat detection. Results showed that this approachcould detect abnormal behaviors in pervasive smart gridapplications. However, the number of rules for detect-ing polymorphic and metamorphic malware can be ex-tremely large. Thus, a more e�cient approach must bedeveloped to speedup the detection and enhance accu-racy.The objective of this research paper is to prove the

concept that cyber-attacks can be detected by usingpower usage profiles. Similar power-based cyber-attackdetection techniques have emerged for detecting cyber-attacks in other domains (or computing systems) by col-lecting power profiles. For example, smartphones within-band power collection [11], medical devices with ACpower [12], and software defined radio [13].J.Ho↵man et al. [11] tried to detect smartphone mal-

ware by analyzing the power consumption of the device.However, this approach failed due to the noise caused byunpredictable users and environment interactions. Em-pirical tests with both artificial and real-world malwareindicated that the additional power consumed by suchapps was too small to be detectable with the mean error-

rates of state-of-the-art measurement tools.A similar approach was tested on an embedded med-

ical device and a compounder by S. Clark et. al. [12].Supervised machine learning techniques (i.e., 3-nearestneighbor, multilayer perceptron, and random forest)were used to model permissible behavior and detect de-viations. Experimental results showed that the threetechniques provide high detection rates, between 93.6%and 94.4%, for detecting di↵erent types of malware.

A power fingerprinting approach was presented byC. Gonzalez et al. [13]. This approach relied on ex-tracting distinctive power consumption signatures andthen used pattern recognition techniques to determine ifthey matched expected behaviors. Preliminary resultsshowed the feasibility of this approach. This researchwas expanded, and this method was used by the PFPfirm1, which provides a commercial product that detectsanomalies on a device by analyzing its power consump-tion.

Our work is di↵erent from C. Gonzalez et al. [13]. Theprimary di↵erence is that we detect cyber-attacks bycollecting and analyzing the internal DC power utiliza-tion of the compromised devices. Moreover, we monitorall the rails supplying power to the PLC, whereas theyonly monitored power utilization of the central proces-sor. In our previous work [14], we examined whethermalware (particularly rootkits) generates a detectablesignal in the power consumption of a general-purposecomputer. Unsupervised machine learning techniqueswere used to analyze CPU and motherboard powerdata measured from the power supply for detecting theAlureon rootkit with a high detection rate.

In this paper, we monitor internal DC power of a PLCfor identifying di↵erent power profiles when the SCADAsystems were operated normally and maliciously. Ourwork was based on the hypothesis that cyber-attackswould require more of the device’s resources whichwould be reflected in power usage. To the best of ourknowledge, this is the first work to collect DC power ofSCADA devices for identifying cyber-attacks.

3. Experimental DesignIn this section, we first introduce the SCADA testbed

used for launching experiments and simulating cyber-attacks. After that, we demonstrate the approach tomonitor PLC power consumption with detailed stepsfor hardware configuration. We also discuss the DF-1protocol, a communication protocol for exchanging mes-sages between the HMI and PLC, and present thedata frame structure of DF-1 messages. We discoveredseveral vulnerabilities in the DF-1 protocol, exploitedthese vulnerabilities, and successfully compromised theSCADA testbed system by command injection attacks,replay attacks and denial of service (DoS) attacks.

3.1 SCADA Testbed Hardware ConfigurationThe SCADA testbed consisted of two PCs and an

Allen Bradley SLC 5/03 7 slot PLC which was hostedin a Allen Bradley CM-184 PLC Trainer. The Trainer,

1http://www.pfpcybersecurity.com/

2916

designed for educational purposes, provided a panel ofswitches and LED lights wired with relays for interact-ing with the PLC. One PC was used to establish a com-munication with the PLC via HMI software. The HMIsoftware was used to program, monitor, and control thePLC. The second PC was used to save the data col-lected by a Data Acquisition System (DAQ). Only fourslots of the PLC were used in our experiments. A de-scription of each slot is shown in Table 1. Operationalcommands and responses were communicated betweenthe HMI application and the PLC through an RS232cable. The main components of the SCADA testbedare shown in Figure 3.

Table 1: PLC 7-Slot descriptionSlot # Description

1 8K memory SLC-5/03 controller2 Input interface (8 switches)3 Output interface (8 LED lights)4 Input and output interface

(1 switch and 1 LED light)5-7 Unused

To monitor the power consumption of the PLC, weprobed the power supply unit (PSU) on the PLC printedcircuit board (PCB). We found four power rails in total.Two +5V rails and one +24V rail are from the back-plane of the PLC. The other +24V rail is an externalpower supply for the output switches. Note that onlyone of the +5V rails and one +24V rail were requiredto supply the analog I/O modules of the PLC. Basedon the power consumption data we monitored for thetwo +5V rails, we determined the +5V rail used by theCPU board. We plot the figures of power consumptiondata for this +5V rail and the +24V rail power suppliedby the backplane of the PLC in Section 5.We used a 16-bit multifunction data acquisition

(DAQ) device [15] to collect digital power consumptiondata of these four rails in real-time. The DAQ providespower data with timestamps, is able to sample at a rateof 250KHz, and can monitor up to 16 channels. TheDAQ was attached to the PLC’s power supply througha DC current sensor board (described later) which pro-vided both voltage and current data. For these exper-iments, we only monitored the three PCB voltage rails(both of the +5V rails and one of the +24V rails). Theother +24V rail was on a di↵erent ground and confusedthe results when we included it.The main challenge we encountered while monitoring

the current consumption of the PLC was that the sen-sors we used in [14] were not sensitive enough to obtainclear current signals in the mA range. To address thischallenge, a di↵erent breakout board (INA169 analogDC current sensor) was used. The INA169 sensor [16] isa“high-side current monitor”, which means that a shuntresistor is placed on the positive power rail and mea-sures the voltage drop across that resistor. This sensorthus provides both voltage and current data. Figure 1shows the analog DC current sensor that was used toobtain the current consumption, while Figure 2 shows

the hardware configuration that was used for our exper-iments.

Figure 1: INA169analog DC currentsensor

Figure 2: Hard-ware configuration

3.2 DF-1 ProtocolThe DF-1 protocol is an asynchronous byte-oriented

protocol used to communicate between the HMI andthe PLC via the RS232 link [17]. Figure 3 shows ourcomplete SCADA testbed. Legitimate users can con-trol the SCADA testbed by sending commands to thePLC through the HMI. RSLogix 500 [18] was the HMIapplication we used for interacting with the PLC.

Figure 3: SCADA testbed

The data in the messages sent between the HMI andthe PLC were DF-1 protocol hex data in full duplex.As a consequence, commands sent from the HMI tothe PLC were transmitted as hex bytes in the data-link layer. To simulate cyber-attacks on the SCADAtestbed, reverse engineering was performed on the hexbyte frames. Figure 4 shows a single data-link layercommand message frame of the DF-1 full duplex pro-tocol that was transmitted from the HMI to the PLC,Table 2 shows a description for each field of this mes-sage. See [17] for more details on the DF-1 protocol.

Our test PLC had a physical key on the front forswitching between Program, Run, and Remote modes.We assumed this would provide a hard interlock pre-venting switching modes.

The DF-1 protocol contains commands for switchingmodes. An example of a malicious code that could beused by an attacker to change the PLC Run mode toProgram mode is 0x 10 02 01 00 0f 00 01 00 80 0110 03 8f 29. An explanation of the message frame can

2917

also be found in Table 2. Note that the highlighted0x01 character after “FNC” (0x80) is the optional Modefield. Here 0x01 means changing the current mode tothe Program mode; 0x06 would place the PLC into Runmode.

Figure 4: DF1 Full duplex data-link layer mes-sage frame

Table 2: Meaning of DF-1 full duplex data-linklayer message frame

Field/Symbol Meaning/Content Example Packet

DLE STX

Sender symbolseparating the multimulti-drop headerfrom data 0x10 0x02

DSTDestination nodefor the message 0x01

SRCSource node for themessage 0x00

CMD Command Code 0x0fSTS Status Code 0x00

TNStransaction number(2 bytes) 0x01 0x00

FNC Function Code 0x80

ADDRAddress of memorylocation (2 bytes) 0x10 0x03

SizeNumber of bytesto be transferred NA

DataData valuestransferred by themessage NA

DLE ETX CRCSender symbolterminating a 0x10 0x03 0x8fmessage 0x29

CRCcheck characters(2 bytes) 0x8f 0x29

3.3 Vulnerabilities of SCADA SystemsThe forms of attacks against SCADA systems are dif-

ferent than those for general PCs. Vulnerabilities resid-ing in the HMI computer, communication channels be-tween the HMI and PLC, and software can be exploitedto compromise SCADA systems. Forms of SCADA at-tacks include:

• Communication Vulnerabilities: Messages sent bythe DF-1 protocol are not encrypted or protected.Hex byte messages can be easily monitored andfabricated. Examples of types of communicationvulnerabilities are:

– Sni�ng : A Serial Protocol Analyzer toolcan be used to monitor and capture un-encrypted communications transmitted be-tween the HMI and the PLC.

– Command Injection: Attackers send mali-cious commands to change PLC operations.As an example, changing the PLC Run mode

to Program Mode can be easily achieved bysending the message shown in Figure 4.

– Response Injection: Attackers modify the re-ply messages sent from the PLC to the HMI.By monitoring normal response messages, at-tackers could modify the bytes in order todeceive the HMI as to the PLC’s true statusand vice versa.

– Replay : Attackers send repeated commandsto the PLC in order to control the sys-tem. Attackers first sni↵ legitimate com-mands that were sent from the HMI to thePLC, then record these commands and re-send them to the PLC in a malicious way.This can be to confuse or disable the device.

• Spoofing: Introducing software on the controllingPC that mimics the HMI software.

• Denial of Service: An attacker sends various com-mands via the RS232 link exhausting the PLC’sCPU resources.

For our testbed system, as a Response Injection-typeattack, we composed a Python script that masqueradedas the RSLogix 500 to the PLC with the objective to in-terject itself in between. As a consequence, the responsemessages from the PLC were captured by the Pythonscript rather than being sent directly to the HMI. Thisdemonstrated a successful Man-in-the-Middle (MITM)insertion that would allow the HMI and PLC to be ma-nipulated independently.

4. Data CollectionTo collect precise data, a measurement computing

data acquisition system (DAQ) was used. The DAQdevice collected analog power consumption data withthe help of INA169 sensors, and converted analog datato digital data which was sent to the data collectionPC running the TraceDAQ Pro application via a USBcable. TracerDAQ Pro is an out-of-the box virtual in-strument that displays and analyzes data and generalsignals with a customized sampling time [19]. This toolran on a separate PC from the one running the HMIsoftware in order to provide reliability during the ex-perimentation process. Data was saved as a CSV file.The sampling time for collecting the power consumptiondata for these experiments was one second.

We first collect power consumption data under twonormal scenarios. The first normal scenario had oneclosed switch lighting one LED light. The second nor-mal scenario had one closed switch lighting all eightLED lights. This was a sanity check that demonstratedthat our power measurement system functioned cor-rectly and could measure the di↵erence in power be-tween these two normal scenarios.

The three attack scenarios we tested are commandinjection attacks, replay attacks and denial of serviceattacks, which were introduced in Section 3.3. Forcommand injection we remotely changed the operationof the PLC to switch from run mode to program

2918

mode. This would allow the PLC to be unknowinglyreprogrammed by an attacker with enough knowledgeof the PLC. For the denial of service attack we senta large amount of communication packets to exhaustthe PLC’s resources. For the replay attack, sequencesof legitimate commands were captured, modified andrepeated to the PLC. Python scripts were writtento simulate these cyber-attacks on the experimentalmachine.

5. Experimental ResultsAs part of the data pre-processing, the voltage and

current for each of the monitored rails were multipliedto obtain the power consumption of the PLC. The nextstep was to compare normal behavior with the abnormalbehavior.Our primary goal was to prove that there is a de-

tectable di↵erence in the power profile between normalbehavior, termed normal, and behavior when under at-tacks, termed abnormal. To do this, we plotted thenormal data against the abnormal behavior.

5.1 Analysis for the +5V and +24V RailsSeveral comparisons were made as part of our data

analysis. The first scenario tested was to verify thepower consumption of the PLC when one light wasturned on versus when all eight lights of the PLCTrainer were on.From the rails that were monitored, the +24V rail

and one of the +5V rails were the ones that showed anincrease in the power usage when all the lights of thePLC Trainer were cycled. Figure 5 shows a comparisonof the PLC’s power usage for one light versus when allthe lights of the PLC were on for the +24V rail, whileFigure 6 shows the same comparison for one of the +5Vrails.

Figure 5: Comparing PLC’S power usage whenall lights were turned on vs. when one light wasturned on for the +24V rail

As expected, the power usage of the PLC increaseswhen all eight lights were turned on in comparison towhen only one light was turned on. Note that the +24Vrail monitored is being used by the PLC and is not sup-plying voltage to the lights themselves. We designedthis scenario as a confirmation of our system to measure

Figure 6: Comparing PLC’S power usage whenall lights were turned on vs. when one light wasturned on for one of the +5V rails

the di↵erence when a larger amount of power (switch-ing more lights) was obviously occurring. Even in thisnascent phase, this type of comparison could be usedas a second-party verification system for a monitoredSCADA system to assure it is switching as it was de-signed.

For the cyber-attack scenarios, we compared normalpower usage of the PLC (one light of the PLC wasturned on) with the power usage when cyber-attackswere simulated. The command injection attack changesthe mode of the PLC from running mode to programmode. In other words, emulating malicious users at-tempting to disable a PLC, our Python scripts would,over a ten second cycle, change the mode from run modeto program mode after two seconds, then pause for eightseconds before switching back. Therefore, the PLC wasin the program mode and was waiting for new com-mands. We did not send new commands, but kept thePLC waiting for eight seconds and then changed thePLC mode back to the running mode, in which modethe PLC performed normally again. This was repeatedand power data was collected. Figure 7 and Figure 8show a comparison of the PLC’s power usage when onelight was turned on versus the command injection at-tack for the +24V and +5V rails.

Figure 7: Comparing PLC’S power usage whenone light was turned on vs. command injectionattack for the +24V rail

As we can see from the figures, when the PLC oper-ated normally, in which case all eight lights were flash-

2919

Figure 8: Comparing PLC’S power usage whenone light was turned on vs. command injectionattack for the +5V rail

ing, the power consumption of the +24V rail was be-tween 3 to 3.5 milliwatts. When the PLC mode waschanged to the program mode, the power consumptiondropped to 1 milliwatts, which was even lower than thepower consumption of the normal scenario when onelight was turned on. Similar patterns can be found inFigure 8. This experiment validated that the power con-sumption feature can be adopted to easily distinguishnormal scenarios and command-injection attacks.We also simulated a Denial of Service (DoS) attack

and collected power consumption data of the PLC.In this scenario, malicious users kept sending a largeamount of diagnostic node requests to read a block ofstatus information from the RAM of PLC. The PLCwas therefore busy with receiving messages and reply-ing with status information. Since the PLC processoronly allows up to 4,096 inputs and outputs and theinstruction memory capacity is only 8K, the PLC re-sources were exhausted immediately after DoS attackswere launched, thus DoS attacks prevented legitimateusage of the PLC. Figure 9 and Figure 10 show a com-parison of the PLC’s power usage when one light wasturned on versus +24 and +5 rails power usages whenthe PLC was under the DoS attack.

Figure 9: Comparing PLC’S power usage whenone light was turned on vs. DoS for the +24Vrail

From the figures we can see that the PLC power con-sumption was much higher than the normal scenario.Although we can distinguish the power profiles of DoS

Figure 10: Comparing PLC’S power usage whenone light was turned on vs. DoS for the +5Vrail

attacks and one light on, when comparing the DoS datawith another normal case when all lights turned on, thedi↵erences are not pronounced.

Finally, we emulated the replay attack. In this sce-nario, malicious users sni�ng normal commands sentfrom the HMI to the PLC and resent them to the PLCto retrieve useful information. As shown in Figure 11and Figure 12, replay attack power consumption data ismuch higher than the normal case with one light turnedon.

Figure 11: Comparing PLC’S power usage whenone light was turned on vs. replay attack for the+24V rail

Therefore, we can easily distinguish replay attacksfrom the normal scenario. Note that we did not comparevarious attack benchmarks but comparing each attackbenchmark with the normal benchmark since this pa-per aims to prove that there is a detectable di↵erencebetween SCADA normal and abnormal operations. Inthe future, we will compare attack data and use un-supervised techniques to identify and classify attacksregarding to the PLC power consumption.

6. ConclusionThis paper presents how we developed a SCADA

testbed with the objective to detect cyber-attacks bymonitoring and analyzing the power consumption of aPLC. The power consumption of the PLC was mon-itored under three attack scenarios: command injec-

2920

Figure 12: Comparing PLC’S power usage whenone light was turned on vs. replay attack for the+5V rail

tion, DoS, and replay. Results shown that these cyber-attacks leave a detectable signal on the power consump-tion of a PLC.For the cases that were di�cult to distinguish, we plan

to apply new techniques, which we have successfully ap-plied on general-purpose computers to detect minutechanges in power signals caused by malware. We arealso planning to apply unsupervised machine learningtechniques to discern these signals. Machine learningcan take advantage of the the repetitive nature of PLCs(i.e., they generally perform a few tasks repeatedly) innormal operation. Furthermore,we will also attempt tocharacterize the types of cyber-attacks using machinelearning techniques.

7. References[1] “Report on Cybersecurity and Critical

Infrastructure in the Americas.” Retrieved inSeptember 2016 from http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/reports/critical-infrastructures-west-hemisphere.pdf.

[2] “Dell Security Annual Threat Report 2015.”Retrieved in September 2016 fromhttps://software.dell.com/docs/2015-dell-security-annual-threat-report-white-paper-15657.pdf.

[3] B. Miller and D. Rowe, “A survey SCADA of andCritical Infrastructure Incidents,” in Proceedingsof the 1st Annual Conference on Research inInformation Technology, RIIT ’12, (New York,NY, USA), pp. 51–56, ACM, 2012.

[4] J. Norman, “The First Malware to Spy on andSubvert Industrial Systems,” 2010.

[5] D. H. J. M. Aleksandr Matrosov,Eugene Rodionov, “Stuxnet Under theMicroscope,” Epistemics in Science, Engineeringand Technology (ESET), 2011.

[6] H. Stark, “Mossad’s Miracle Weapon: StuxnetVirus Opens New Era of Cyber War,” 2011.Retrieved in August 2016 fromhttp://www.spiegel.de/international/world/mossad-s-miracle-weapon-stuxnet-virus-opens-new-era-of-cyber-war-a-778912.html.

[7] R. V. Nell Nelson, “The Impact of Dragonfly

Malware on Industrial Control Systems,” SANSInstitute, 2016.

[8] Q. Chen and S. Abdelwahed, “A Model-BasedApproach to Self-Protection in SCADA Systems,”in 9th International Workshop on FeedbackComputing, USENIX Association, June 2014.

[9] Q. Chen, S. Abdelwahed, and A. Erradi, “AModel-Based Validated Autonomic Approach toSelf-Protect Computing Systems,” Internet ofThings Journal, IEEE, vol. 1, pp. 446–460, Oct2014.

[10] H. Bao, R. Lu, B. Li, and R. Deng, “BLITHE:Behavior Rule-Based Insider Threat Detection forSmart Grid,” IEEE Internet of Things Journal,vol. 3, no. 2, pp. 190–205, 2016.

[11] J. Ho↵mann, S. Neumann, and T. Holz, “MobileMalware Detection Based on Energy Fingerprints:A Dead End?,” in Research in Attacks, Intrusions,and Defenses, Springer, 2013.

[12] S. S. Clark, B. Ransford, A. Rahmati, S. Guineau,J. Sorber, W. Xu, K. Fu, A. Rahmati,M. Salajegheh, D. Holcomb, et al., “Wattsupdoc:Power Side Channels to Nonintrusively DiscoverUntargeted Malware on Embedded MedicalDevices,” in HealthTech, 2013.

[13] C. R. A. Gonzalez and J. H. Reed, “PowerFingerprinting in SDR and CR IntegrityAssessment,” in Military CommunicationsConference, 2009. MILCOM 2009. IEEE, pp. 1–7,2009.

[14] J. M. Hernandez, R. Bridges, J. Nichols,S. Prowell, and K. Goseva-Popstojanova,“Towards a Malware Detection Framework Basedon Power Consumption Monitoring,” 2016.Retrieved in September 2016http://www.ieee-security.org/TC/SP2016/poster-abstracts/46-poster abstract.pdf.

[15] “USB-1608g Series 16-bit High-SpeedMultifunction DAQ Devices.” Retrieved in August2016 from http://www.mccdaq.com/usb-data-acquisition/USB-1608G-Series.aspx.

[16] “INA169 Analog DC Current Sensor Breakout -60v 5a Max.” Retrieved in September 2016 fromhttps://www.adafruit.com/product/1164.

[17] Allen-Bradley, “DF-1 Protocol and Command SetReference Manual.” Retrieved in August 2016fromhttp://docplayer.net/224339-Allen-bradley-df1-protocol-and-command-set-reference-manual.html.

[18] “Rockwell Software RSLogix 500.” Retrieved inSeptember 2016 fromhttp://www.rockwellautomation.com/rockwellsoftware/products/rslogix500.page.

[19] “TracerDAQ Pro.” Retrieved in August 2016 fromhttp://www.mccdaq.com/daq-software/tracerdaq-pro.aspx.

2921