Paper ID #21229

Design and Development of a Supervisory Control and Data Acquisition (SCADA)Laboratory

Dr. Faruk Yildiz, Sam Houston State University

Faruk Yildiz is currently an Associate Professor of Engineering Technology at Sam Houston State Uni-versity. His primary teaching areas are in Electronics, Computer Aided Design (CAD), and AlternativeEnergy Systems. Research interests include: low power energy harvesting systems, renewable energytechnologies and education.

James Holekamp, Sam Houston State UniversityDr. Reg Recayi Pecen, Sam Houston State University

Dr. Reg Pecen is currently a Quanta Endowed Professor of the Department of Engineering Technologyat Sam Houston State University in Huntsville, Texas. Dr. Pecen was formerly a professor and programchairs of Electrical Engineering Technology and Graduate (MS and Doctoral) Programs in the Depart-ment of Technology at the University of Northern Iowa (UNI). Dr. Pecen served as 2nd President andProfessor at North American University in Houston, TX from July 2012 through December 2016. He alsoserved as a Chair of Energy Conservation and Conversion Division at American Society of EngineeringEducation (ASEE). Dr. Pecen holds a B.S in EE and an M.S. in Controls and Computer Engineering fromthe Istanbul Technical University, an M.S. in EE from the University of Colorado at Boulder, and a Ph.D.in Electrical Engineering from the University of Wyoming (UW, 1997). He served as a graduate assistantand faculty at UW, and South Dakota State University. He served on UNI Energy and Environment Coun-cil, College Diversity Committee, University Diversity Advisory Board, and Graduate College DiversityTask Force Committees. His research interests, grants, and more than 50 publications are in the areasof AC/DC Power System Interactions, distributed energy systems, power quality, and grid-connected re-newable energy applications including solar and wind power systems. He is a senior member of IEEE,member of ASEE, Tau Beta Pi National Engineering Honor Society, and ATMAE. Dr. Pecen was recog-nized as an Honored Teacher/Researcher in ”Who’s Who among America’s Teachers” in 2004-2009. Dr.Pecen is a recipient of 2010 Diversity Matters Award at the University of Northern Iowa for his effortson promoting diversity and international education at UNI. He is also a recipient of 2011 UNI C.A.R.ESustainability Award for the recognition of applied research and development of renewable energy appli-cations at UNI and Iowa in general. Dr. Pecen established solar electric boat R & D center at UNI wheredozens of students were given opportunities to design solar powered boats. UNI solar electric boat teamwith Dr. Pecen’s supervision won two times a third place overall in World Championship on solar elec-tric boating, an international competition promoting clean transportation technologies in US waters. Hewas recognized as an Advisor of the Year Award nominee among 8 other UNI faculty members in 2010-2011 academic year Leadership Award Ceremony. Dr. Pecen received a Milestone Award for outstandingmentoring of graduate students at UNI, and recognition from UNI Graduate College for acknowledgingthe milestone that has been achieved in successfully chairing ten or more graduate student culminatingprojects, theses, or dissertations, in 2011 and 2005.

He was also nominated for 2004 UNI Book and Supply Outstanding Teaching Award, March 2004, andnominated for 2006, and 2007 Russ Nielson Service Awards, UNI. Dr. Pecen is an Engineering Tech-nology Editor of American Journal of Undergraduate Research (AJUR). He has been serving as a re-viewer on the IEEE Transactions on Electronics Packaging Manufacturing since 2001. Dr. Pecen hasserved on ASEE Engineering Technology Division (ETD) in Annual ASEE Conferences as a reviewer,session moderator, and co-moderator since 2002. He served as a Chair-Elect on ASEE ECC Divisionin 2011. He also served as a program chair on ASEE ECCD in 2010. He is also serving on advisoryboards of International Sustainable World Project Olympiad (isweep.org) and International HydrogenEnergy Congress. Dr. Pecen received a certificate of appreciation from IEEE Power Electronics Soci-ety in recognition of valuable contributions to the Solar Splash as 2011 and 2012 Event Coordinator.Dr. Pecen was formerly a board member of Iowa Alliance for Wind Innovation and Novel Development(www.iawind.org/board.php) and also represented UNI at Iowa Wind Energy Association (IWEA). Dr.

c©American Society for Engineering Education, 2018

Paper ID #21229

Pecen taught Building Operator Certificate (BOC) classes for the Midwest Energy Efficiency Alliance(MEEA) since 2007 at Iowa, Kansas, Michigan, Illinois, Minnesota, and Missouri as well as the SPEERin Texas and Oklahoma to promote energy efficiency in industrial and commercial environments.

Dr. Pecen was recognized by State of Iowa Senate on June 22, 2012 for his excellent service and con-tribution to state of Iowa for development of clean and renewable energy and promoting diversity andinternational education since 1998.

Dr. Umit Karabiyik, Sam Houston State University

Umit Karabiyik is an Assistant Professor in the Department of Computer Science at Sam Houston Univer-sity, in Huntsville, TX. Dr. Karabiyik completed his Ph.D. and M.S. degrees at Florida State Universityin 2015 and 2010 respectively. His research interests mainly lie in the area of Digital Forensics and Cy-bersecurity ranging from developing tools for forensic investigations to creating new models for forensicdata analysis in various environments. He also has broad research interests in Expert Systems, KnowledgeRepresentation, Encrypted File Analysis, Computer and Network Security. Dr. Karabiyik is the creator ofopen source digital forensics tool called Automated Disk Investigation Toolkit (AUDIT). Dr. Karabiyikis a recipient of NIJ Grant on Targeted Data Extraction from Mobile Devices. One of his recent workhas received the ”Best Paper Award” at the IEEE 4th International Symposium on Digital Forensic andSecurity (ISDF). In addition, Dr. Karabiyik is leading the Mobile Forensics and SCADA Forensics Labsat SHSU.

Mr. Keith L. Coogler, Sam Houston State University

Dr. Keith L. Coogler is an instructor of engineering technology at Sam Houston State University. Hereceived a BS in Design & Development and holds a MA in Industrial Education and Ed.D. in HigherEducation from Texas A&M University – Commerce. His primary teaching area is Construction Manage-ment. Research interests include: automation, electronics, alternative energy, and ”green” construction.

Mr. Jeremy Ryan England

c©American Society for Engineering Education, 2018

Design and Development of a Supervisory Control and Data Acquisition (SCADA)

Laboratory

Abstract

Supervisory control and data acquisition (SCADA) is a prevalent control system architecture that

is commonly used for industrial automation. The SCADA systems play an integral role in large-

scale processes for interfacing with transducers and machinery for real time control and data

acquisition. The increasing demand to integrate SCADA systems with remote networks and

Internet of Things (IoT) technologies has raised concerns for information security specialists.

These systems are thought to have notable security vulnerabilities and may be subject to an

increasing number of cyber threats. In this paper/project, several students from Sam Houston State

University design and deploy a SCADA laboratory to better understand these systems and the

inherent security threats that go with them. The details including system infrastructure, challenges

faced during the establishment of the laboratory, student and faculty involvement, laboratory

course objectives, student assessments, and the industry support is covered in the paper.

Introduction

Industrial automation and control systems are critical assets to our nation as they interact with real-

life aspects of our daily life. These systems often run 24/7 to control and monitor critical industrial

and infrastructure processes. The demand to integrate them with the internet has opened them up

for cyber-attacks. The need for skilled expertise in defending these critical assets in the student

world is high [1-3]. Supervisory control and data acquisition (SCADA) is commonly used in

industrial control systems (ICS) to remotely gather data in real time to automate and to control

networked equipment such as programmable logic controllers (PLC). These types of systems are

often seen in frameworks that require industrial automation including power plants, oil and gas

refining, telecommunications, transportation, and water and waste control [4]. While SCADA

systems are widely used throughout industrial automation, such systems are known to have notable

security vulnerabilities and may be subject to an increasing number of cyber threats [5].

According to the Valli [6], there’s a lack of protection for protocols used in SCADA systems.

SCADA systems are used all over the world for highly important operations that if forcibly stopped

could result in major economic destruction or human death. As these systems get larger there’s a

need to expand their currently private local networks that they run on. As the systems grow to

different locations you'll have to break up the network which means you will have multiple

networks that must act identically without being connected. The solution to not break them up is

to connect these networks to the internet which would allow for HMI and other device access in

remote areas. Once connected to the internet however, hackers can get easy access to the system

which as stated before could be catastrophic. The paper is focusing on the ModBUS, and DNP3

protocols and aims to create a framework from which security vulnerabilities and attacks can be

controlled and monitored to understand how to better protect against them. They propose to use

IDS rulesets that try to identify, reduce/stop attacks, and perform extensive logging for later

investigation. If an IDS system was placed on the outside or intersection of the SCADA network,

it could provide the much-needed protection they’re looking for provided they keep it up to date

with all the latest vulnerabilities found. Honeypot, for example, is used to fake the attackers into

thinking they have successfully breached the system so that they will release their malicious code

into it instead of the actual SCADA system; the malicious code can then be studied for better

protection in the future while also protecting the SCADA system from the attack.

There are a variety of resources for SCADA and its security systems. Especially the vulnerabilities

to cyber-attacks of the automation systems when connected to internet are studied. In one for the

studies’ authors made a SCADA lab that mimics real world systems as closely as possible to test

it for vulnerabilities in the cybersecurity area [7]. They found that not much research has been

done on cybersecurity related to SCADA protocols and forensics in an industrial setting. A fake

manufacturing company called “KAT Engineering and Chemicals” was created in the HMI

software with random values for many of the processes. In certain situations, the lab would cause

a theoretical environmental disaster. Blue and red teams would play against each other in the

SCADA lab; one trying to hack into the network and mess processes up while the other team tried

to prevent it and/or figure out where the vulnerabilities where coming from. The lab was designed

to really allow its users to understand and learn about the vulnerabilities in SCADA systems and

was easily scalable up and down depending on its needed use case. Another study, a forensic toolkit

is proposed based on an earlier forensic methodology for SCADA systems proposed by Wu et al

[8]. The toolkit would require hardware like write blockers, firewire PCI Card, and a HD camera,

as well as software like bespoke PLC flashing software, FTK imager, EnCase, Helix, TCPDump,

a Data hashing tool, and a text editor. The toolkit would be used to conduct each phase of the

forensic methodology. Forensic methodology phases included: identification and preparation;

identifying data sources; preservation, prioritizing, and collection; examination and analysis; and

reporting and presentation.

Moreover, another research study is conducted to study indoor SCADA systems with solar panels

[9]. An indoor lab was developed that used solar panels as the input field devices. There aren’t

many if any training materials for learning about SCADA systems especially ones directed at

community college. The training materials used for the project were chosen for their cheap price

and portability. After searching around for materials and software, Schneider Electric was the

company they went with. OPC server had to be used as a middle man between the protocols of the

Allen Bradley products and the SCADA client system they had. Only “free” OPC server they

found was Matrikon and Kepware which had evaluation versions that had two-hour limits. A

training environment was developed to expose students to the various sensors and industry

standard protocols like MODBUS. Learning objectives where to learn the roles of a SCADA

system and how to wire up a PLC to the system, and to various sensors, program the PLCs, identify,

configures, and test communications, troubleshoot, and create HMIs for operating the equipment.

After the course most students felt well versed in what and how a SCADA system works.

Attacks on SCADA systems are becoming more popular with the connection of them to wider

networks like the internet. A forensics analysis needs to be made on how to protect these systems

against attacks, without interfering with the always on nature of most SCADA systems. The

amount of data a SCADA system uses is approximately 400 GB per day. If a monitoring and

logging system is to be placed in the system it needs to be able to handle that amount of data while

also not interrupting the normal flow of the SCADA system. Most SCADA systems run on old

platforms that require legacy support and thus another challenge is finding forensic software that

is up to date but also runs on these really old systems. A lot of data is also volatile and changes

frequently, so the forensics needs to be able to read this data as fast as possible before it changes

to get accurate results. As many other papers mentioned, there is no generic model for SCADA

forensics and one needs to be made and be able to run without interfering with the system [10].

To further evaluate the security of such systems, several students from research team began to

develop a laboratory that would allow students and researchers to conduct assessments for

vulnerabilities in the cyber security of industrial control. In addition to security assessments, the

lab may serve as a learning platform for various Engineering Technology related course work. The

SCADA lab’s intended functionality is to provide for a realistic imitation of an industrial control

SCADA system. For security purposes, the lab can be used to study penetration assessment and

testing, SCADA protocols analysis, vulnerability assessment and testing, and SCADA forensics

research [11]. For Engineering Technology related purposes, the lab is used for course work

including instrumentation & interfacing, automation & control systems, microcontroller

applications, control technology, and process control in a way that can demonstrate the importance

of security.

The purposes of the SCADA laboratory is to provide for a realistic imitation of an industrial control

SCADA system that can be used to study real-life cases such as penetration assessment and testing,

SCADA protocols analysis, vulnerability assessment and testing, and the SCADA forensics

research. This laboratory is intendent to be used for both Digital and Cyber Forensic Engineering

Technology, and Engineering Technology programs (Electronics Technology and Electronics &

Computer Engineering Technology). The laboratory will serve for undergraduate computer

science and engineering technology courses as well as research projects in the areas of

instrumentation & interfacing, robotics technology, automation & control systems, programmable

logic controller (PLC), process control, digital forensics, and cyber security.

Laboratory Design and Development

SCADA systems are used to control dispersed assets where centralized data acquisition is as

important as control [12]. A SCADA system generally consists of the following components. One

or more distributed field sites consisting of remote terminal units and programmable logic

controllers that control actuators and monitor sensors, supervisory computers/servers and human-

machine interface, alarm system, data historian, and a network infrastructure. The network

infrastructure of a SCADA system is not exclusive to a single topology and can be distributed

across a number of networks. To enable cross communication between network topologies,

hardware solutions such as protocol converters can be implemented. Additionally, software such

as open platform communications (OPC) aim to provide interoperability by enabling

communication of real-time data between devices from different manufactures [13]. SCADA

communication protocols often prioritize fast transmission times and low latency. Anecdotally,

this may contribute to the widespread use of legacy protocols and proprietary communications that

is seen throughout the SCADA industry. SCADA systems may also have connectivity to entities

outside of the SCADA network, such as a corporate network. When interconnectivity between

networks is in place, a common practice is to isolate the SCADA network by implementing a

firewall. Lastly, the current 4th generation SCADA architecture is defined by its increasing support

for internet of things technologies as a means of improving interoperability [11].

Using the information above, a lab’s SCADA architecture was carefully designed. For the intended

use case of the lab, it was important to incorporate a wide range of hardware and software into the

SCADA system so that the testing environment could be as diverse as possible. Programmable

logic controllers from different manufacturers including Allen Bradly, Automation Direct,

Schneider, and Eaton were implemented into the system with various transducers and outputs.

Following is a list of the PLCs and their associated inputs and outputs included in the lab:

1. Eaton XC-CPU202 a. Buzzer b. LED Lights

2. Direct Logic 06 Koyo a. Tower Light b. Buzzer c. Rotary Encoder

3. Automation Direct Productivity 3000 a. Humidity Sensor b. Picking Sensor c. LED Light

4. Allen Bradley MicroLogix 1100 a. Photoelectric Proximity Sensor b. LED Light

5. Schneider M221 a. Air Velocity Sensor b. LED Light

Additional hardware was also installed. A protocol converter was included to ensure compatibility

between devices and to provide the ability to enable additional SCADA protocols throughout the

system. Two of the three HMIs installed include dedicated hardware from Allen Bradley and

Weintek. A microcontroller with 802.11 wireless capabilities and a wireless IP camera were also

installed. Following is a list of the remaining hardware included in the lab:

1. Red Lion DSPLE Protocol Converter 2. Weintek EMT3120A 3. Allen Bradley Panel View 600 4. IP Camera 5. ESP8266 Wireless Microcontroller with smoke sensor 6. Firewall 7. 24 port network switch 8. Wireless Access Point 9. 5x Desktop Computers

Software

The main SCADA software in the lab is InduSoft Web Studio by Wonderware. InduSoft operates

as both a supervisory SCADA server (also known as a master terminal unit) and HMI software.

The HMI for InduSoft can be displayed on any compatible Windows machine. An Apache web

server is configured to enable access to the InduSoft HMI screen through a web browser on the

local area network. A separate HTTP server is also configured to host a live stream of the video

feed of the IP camera. Microsoft SQL Server 2008 is deployed as a historian, which records all

PLC events, sensor data, and alarm information when the InduSoft runtime is live. KEPServerEX

is deployed as an OPC server to enable network traffic for the OPC protocol and to provide

communications across vendors with limited compatibility. Encrypted, signed, and unencrypted

variants of the OPC protocol have been deployed in the InduSoft runtime to allow additional

security assessments. A Linux virtual machine is installed and configured to host a MQTT broker,

enabling communication with internet of things (IoT) devices such as our ESP8266 wireless

microcontroller through the MQTT protocol.

Additionally, supplemental software that is not used directly in the main InduSoft runtime of the

SCADA system is included in the lab. The following describes this software. Additional SCADA

software for programming the HMIs with dedicated hardware including Studio 5000 for the Panel

View 600 HMI and EasyBuilder Pro for the Weintek HMI. This software can be used as an

alternative to InduSoft to provide additional HMI development type course work and additional

security assessments or comparisons. A VNC viewer is installed to enable remote viewing of the

Weintek and Panel View HMI screens across the local area network. The ladder logic

programming software for all included PLCs is installed and configured to allow updates to ladder

logic over the network. An optional Modbus protocol simulator is also installed and configured to

generate different forms of Modbus traffic that are not used by the PLCs, such as Modbus IP/RTU

and Modbus ASCII. The core infrastructure of the SCADA lab is shown below (Figure 1).

Figure 1. Lab Network Design

As shown in figure one, the network switch consists of three subnets: SCADA, HMI,

Corporate/External. Additionally, a fourth subnet exists directly through the firewall, which will

be discussed later. The design layout is intended to imitate multiple SCADA architectures, where

data acquisition and control is performed either locally or remotely. The InduSoft and Weintek

HMIs can interface with PLCs using three different methods: Directly through the PLC’s native

communication protocol, through the Red Lion Protocol Converter, or through the OPC server.

Implementations of the three possible communication methods are included in the InduSoft and

Weintek HMI. The SQL database server (historian) is hosted on the corporate/external zone and

communicates directly with InduSoft. A regulatory adhoc script is implemented to read data from

the historian every hour and save the data in the form of .CSV files. If desired, the .CSV files can

then be loaded into a spreadsheet for further interpretation.

InduSoft HMI Screen

The InduSoft HMI screen was developed in combination of programming with tags and VBScript

(Figure 2). The screen was designed to interface with all PLCs in the lab using one or more of the

communication methods provided by the lab’s architecture. Status indicators, continuous and point

level measurement readings, and manual control inputs are displayed throughout the screen.

Utilizing the features provided by InduSoft, the state of the screen is synchronized with an HTML

file in a directory that is hosted on a local HTTP server. This enables remote access and control of

the InduSoft HMI through any web browser on the network.

Figure 2. InduSoft HMI Screen (Partial view)

As requested by students interested in conducting security assessments, an automatic process

control simulation was also incorporated into the screen. The automatic process control simulation

is designed to cycle through the available outputs across all PLCs at consistent and evenly

distributed timings. The significance of providing even and repetitive timings is discussed in more

detail in the security section of the paper. At the end of the automatic process, all input data is sent

to the historian and the cycle repeats. The automatic simulation operates asynchronously, allowing

manual inputs to function while the process is running. Each cycle of the automatic process is

intended to generate network traffic for all available SCADA protocols. Figure 3 shows the photos

of the research laboratory environments.

Figure 3. SCADA lab

Security and Forensics Tools

A wide range of security and forensic tools are installed throughout the system. The Linux

distribution, Kali Linux, which is designed specifically for digital forensics and penetration testing,

has been installed natively on one desktop and in a virtual machine on another desktop. Some

notable security related software that is packaged with Kali Linux include Nmap, Ettercap, and

ZED Attack Proxy. Nmap is a networking mapping utility for network discovery and security

auditing [14]. Ettercap is a tool for man-in-the-middle attacks and can be used for computer

network protocol analysis [15]. ZED Attack Proxy is a web application security scanner [16] that

may provide valuable security information for remote web viewers of SCADA systems. Additional

tools for Microsoft Windows have also been installed. These tools include Wireshark, Microsoft

Baseline Security Analyzer, and Low Orbit Ion Cannon (LOIC). Wireshark is a network protocol

analyzer and a packet sniffer [17]. It is particularly useful in the lab because it is capable of

detecting and filtering network traffic from SCADA protocols such as Modbus and OPC.

Microsoft Baseline Security Analyzer is a simple security assessment tool for identifying missing

updates and common security misconfigurations [18]. This tool can provide significant feedback

for Windows components used in the lab such as Microsoft SQL Server. LOIC is a network stress

testing utility capable of performing denial of service attacks (DoS) in the form of SYN flood and

UDP flood attacks. The effects of such attacks have yielded some interesting results in the lab

which will be detailed in the security section. In the lab’s current configuration, the following

communication protocols are utilized: Modbus/TCP, Common Industrial Protocol (CIP),

CODESYS ARTI, OPC, Message Queuing Telemetry Transport (MQTT), ECOM/UDP. Although

detailing each individual protocol is beyond the scope of this paper [19].

Preliminary Tests and Studies

Early cases of student involvement in regards to SCADA security have yielded several notable

observations. Among the first assessments conducted by student participants include network

stress tests in the form of denial of service attacks and protocol analysis via packet captures. For

both test cases, the automatic process control simulation of the InduSoft runtime was used. Denial

of service attacks were performed against the InduSoft runtime, protocol converter, OPC server,

and all PLCs. Each device was tested against UDP flood and SYN flood (TCP) attacks.

Additionally, packet captures were made for each test in the form of .pcap files so that the results

could be further evaluated. The results indicated that all PLCs in the lab as well as the Red Lion

protocol converter were vulnerable to UDP floods. During the experiment, any targeted hardware

device could be taken offline in a fraction of a second through a UDP flood attack, even if the

targeted device did not utilize UDP for any sort of communication. When performing such attacks,

the InduSoft HMI was capable of indicating that each targeted device was taken offline for all

components excluding the DirectLogic Koyo PLC. Interestingly enough, when the Koyo PLC was

taken offline via UDP flood, the InduSoft HMI would continue to report the enabling and disabling

of outputs on the PLC and the falsely reported events would be documented in the SQL database.

The lab proved to be more resilient against SYN flood attacks. All PLCs appeared to ignore the

SYN requests from the performed SYN floods. Numerous TCP ports were targeted during these

trials. This assessment suggested that the component of the InduSoft runtime that operates as the

master terminal unit of the SCADA system is most vulnerable to SYN flood attacks. During this

attack, no systems were brought offline, but significant latencies were introduced. When the

InduSoft network port associated with supervisory control was targeted by a SYN flood attack, the

timings of the automatic process control simulation were no longer consistent. All functions of the

process were delayed or expedited by a range of ~.1-2 seconds. This inconsistency is apparent in

the timestamps of the events recorded in the data historian. Such inconsistencies introduced by the

attack are also likely to be apparent in the packet capture for the trial.

Protocol analysis assessments were conducted using Wireshark. In the lab’s current configuration,

the following communication protocols are utilized: Modbus/TCP, Common Industrial Protocol

(CIP), CODESYS ARTI, OPC, Message Queuing Telemetry Transport (MQTT), ECOM/UDP.

Efforts were made by students to identify and analyze the packets of each protocol mentioned

above. During the assessment, live sensor data was easily identifiable within the data frames of

the unencrypted protocols. Additionally, comparisons were made using the three variants of OPC

implemented in the lab: unencrypted, signed, signed and encrypted. To further the study, a more

in depth protocol analysis was performed on the observed Modbus network traffic.

Figure 4. Modbus TCP Frame Format

The frame format for a Modbus packet is shown above (Figure 4). Using Wireshark to monitor the

active Modbus traffic from the Schneider M221, Productivity 3000, and protocol converter, it was

observed that the protocol identifier was always 0x0000. Since Modbus is predominately an openly

published and royalty free protocol [14], public functions codes were successfully identified from

all Modbus traffic originating from the protocol converter. However, it was discovered that the

Productivity 3000 exclusively used user defined functions to perform commands that are supported

by public functions codes, such as reading input registers. Furthermore, an unexpected

undocumented and reserved function code was also observed on the Schneider M221 PLC.

Implementation of an HTML Web Viewer

A common feature for SCADA systems includes the ability to remotely view and control an HMI

screen. An important component added to the SCADA lab includes the ability to perform

vulnerability assessments and testing on HTML based remote HMI screens. For this feature to be

possible, an http server is required to host parts of the SCADA system’s core file directory which

may contain sensitive information that is valuable to an attacker. Additionally, if an attacker

manages to circumvent the authorization for remote HMI access, then the attacker would have full

remote control of the HMI screen. To enable vulnerability assessments and evaluations on remote

HMI web viewers, the lab environment was set up to allow all subnets in the network to access the

HMI web viewer and its authentication is limited to weak username and password credentials.

Implementation of HMI Screens

The main SCADA system software in the lab is conducted through InduSoft web studio. While

SCADA protocols are standardized across most major industrial control and automation software

suits, it is important to implement alternative SCADA software solutions into the lab so that

assessments and comparisons can be made between platforms. For a secondary HMI, an Allen

Bradley PanelView Plus 600 was introduced to the lab. The PanelView is a particularly appealing

component for vulnerability assessment and security analysis because it relies on dedicated

hardware running on the Windows Embedded Compact 6.0 operating system. It may be possible

that the unconventional operating system could expose a SCADA system to undocumented

vulnerabilities and exploits. The PanelView HMI is configured with the FactoryTalk View Studio

software and has SCADA features configured for data acquisition and control of an Allen Bradley

Micrologix 1000 PLC through an RS-232 serial connection. The communications configuration

for this HMI application is unique because it allows for assessments of a SCADA system where

the PLC is wired through a serial connection opposed to Ethernet.

Summary of Student Involvement

This project started with the announcement of Enhancing Undergraduate Research Experiences &

Creative Activities (EURECA)’s Faculty and Student Team (FAST) project/grant announcements

where undergraduate students work under one or more faculty supervisors for a summer project.

This internal project provides summer stipend for the students and faculty and very competitive

due to many applications received by the committee to renew. Two students volunteered to be part

of the project and filled out the application. The project was not among those applications were

approved for the summer studies. However, office research and sponsored programs (ORSP)

funded two students to work on the project. Both students were electronics and computer

engineering technology (ECET) majors and then one computer science (CS) major student joined

to team to help on the cyber security part of the project. The project was supervised by an ECET

and CS faculty who are experts in digital forensics and industrial automation & control fields. In

the fall of 2017 two of the students were graduated and three new students are identified to take

over the project for the future expansion of the project. The Table 1 shows the student information

and major fields who contributed to this project. Below are the summary of student participation.

Table 1. Student Information

Name Major Contribution/Length Duty Graduated

A ECET Started the project

Sp, Su, Fa 2017

Hardware/Software,

report presentation,

purchasing, data

collection and analyzing

Fall 2017

B ECET Worked on the

project Sp, Su 2017

Hardware, purchasing,

manual preparation

Summer 2017

C CS Worked on the

project Sp, Su 2017

Software (Cyber-

attacks, digital

forensics), data

collection and analyzing

Summer 2017

D ECET Working on the

project, Sp 2018

Hardware

(implementation,

improvement), Software

Active

E Engineering

Technology

(Electronics)

Working on the

project, Sp 2018

Hardware

(implementation,

improvement), Software

Active

F CS Working on the

project, Fa 2017, Sp

2018

Software (Cyber-

attacks, digital

forensics), data

collection and

analyzing, report

preparation

Active

G ECET Working on the

project, Sp 2018

Hardware

(implementation,

improvement), Software

Active

Relocating the Equipment

The equipment was located in a digital forensics lab and has not been used for a long time due to

lack of student and faculty interest. The relocating process caused some delay in students’ studies

due to contacting and scheduling available times for relocation. During this down time, students

invested time in reading up on SCADA systems and the security concerns that they hold. Soon

enough, it was time for relocation. To ensure the lab was reassembled properly, students

participated in the moving process. Before disassembling the lab for relocation, students made sure

to take lots of pictures and also made a diagram that showed the connections between all the

computers and SCADA hardware. This ensured a proper re-assembly process in the new location.

With the help of two student employees, the lab was then relocated to the second floor of the

computer science building. Fortunately, no equipment was broken and students managed to get

the system up and running on my first attempt.

Investigating the SCADA Lab

The primary goal of the research team here was to investigate the lab so that they could understand

every minute detail of every component and feature the lab had to offer. To accomplish this, each

aspect of the lab from hardware to software had to be thoroughly analyzed. To start, students began

documenting the installed software on each machine. Each computer has its own dedicated folder

that includes any information that found relevant to the SCADA system. This information includes

useful screenshots, installed software, network information, and a general description of the

machine’s role in the SCADA lab. Another component of the investigation was to verify that the

SCADA lab’s implemented features were working correctly. Unfortunately, not everything was

operating as intended according to the original project report. In the lab’s current condition, the

HMI software is failing to communicate to the DirectLogic06 Koyo PLC. However, the Eaton

PLC is incorporated into the SCADA system properly. While troubleshooting the communications

to the DirectLogic06 PLC, team firstly made sure that it was operational by editing its ladder logic

to continuously enable the addresses associated with the green, yellow, and red lights of a

component connected to the outputs of the PLC. The results indicated that the PLC was not

damaged and that the issue must be caused from a misconfiguration in the HMI software.

Unfortunately, when troubleshooting the indusoft HMI SCADA software communication to the

DirectLogic06, the evaluation copy of the software expired and no longer continue to investigation.

But later the company provided a free license to continue research and designing interface.

Network Configuration

Since the lab was intended to simulate the mediocre security practices that are commonly found

throughout the industry, the SCADA lab has a rather minimalistic network configuration. Most

security features within the firewall are disabled and passwords are short and simple. The network

is split into three subnets labeled SCADA, HMI, and EXTERNAL. Isolating the network into 3

different subnets allows the lab to simulate 3 separate remote networks that collectively provide

data and functionalities to the human machine interface of the lab. The computers on the external

subnet are installed with objectively insecure SQL servers that communicate with the indusoft

SCADA. The information in this network traffic is intended to provide revealing information if

someone were to eavesdrop.

Indusoft’s HMI SCADA Software

The HMI and SCADA software is packaged into the software labeled indusoft web studio. The

HMI is configured to simulate a chemical batching process that is intended to utilize the following

protocols -MODBUS, TCP/IP, OPC-DA, OPC-UA, ARTI CODESYS, DNP3, KOYO, and IEC

60870-5-104. These are the protocols that are most commonly used in real SCADA systems. Since

the Eaton and DirectLogic06 PLCs are only capable of utilizing a few of these protocols, the rest

are implemented through simulators. The network traffic generated from these protocols are

intended to be useful for security and forensic analysis.

Future Work for Improvement

In order to modify and enhance the SCADA lab, one of two things must first be done.

Obtain a permanent license key for indusoft web studio etc,

Implement new HMI SCADA software that is compatible with the same protocols and create a new industrial process for the human machine interface.

Installing and configure new hardware (input and output devices with new PLC units)

Improve system organization o Make a manual o Merge software into a single toolkit for ease of use

Better integrate SQL server functionality into the lab

Explore alternative SCADA/HMI software o HTML5 HMI o openSCADA

Add optional secure features for SCADA analysis o Possible secure features:

Local VPN IP Whitelist SCADA encryption Software firewall such as glasswire

Future Work for More Research Challenges

‘Bump in the wire’ security and data acquisition

FPGA based signal processing for data analysis

Reading from PLC memory without stopping operations o Compare checksums of memory in F-ROM to expected checksum periodically o Hex dumps

Ladder logic based data/security logging

Capabilities of buffer overflow attacks on PLCs o Detect suspicious activities associated with such attacks

SCADA remote breaching

Consequences of address resolution protocol spoofing

Consequences of session hijacking

Conclusion

Many jobs require knowledge on industrial automation in some shape or form, and yet workers

with this knowledge are hard to come by. High schools and colleges need to provide industrial

automation classes to transition students into their future jobs. Many surveys taken prove that there

is a high need for industrial automation knowledge, and further surveys indicate that companies

are have a hard time finding people skilled in things like PLC programming, automation, wireless

technology, troubleshooting, etc. and that if the new employees need to be trained its often difficult

to get the employees trained in all the mix of skills they need. Technicians need to understand the

how and why of systems operations and problems instead of just guessing different possible

solutions and seeing if they will work [20].

This project was initially started to promote center for digital forensics studies. The center has

been inactive for a long time due to lack of interest from the faculty and the students until two of

the faculty decided to involve students and activate the center with research projects. Since last

year, seven students worked in the center having major duties to promote and active the center. At

present the center/lab can be used for teaching and research purposes and attract more students

who would like to study industrial control, SCADA security systems, digital forensics etc. Student

feedbacks are very positive in terms of learning and involving in hands on projects. One major

common feedback is improvement on reporting and writing capabilities of the students who

involved in report and manual preparation phases of the project. The development content and lab

resources are being part of instrument & interfacing and automation and control systems courses

mainly. But the resources will be used in more course work needs for both engineering technology

and computer science departments. More students are being interested and want to work in the

SCADA lab/center and proposing new research ideas. This year two of the students applied to

EURECA’s FAST project to get summer funds in order to work in the center.

References

[1] Scheffer, E., Wibberley, D., and Beets, N. “What the future holds for SCADA systems and

process automation”, Elektron, 19(7), July 2002, pp. 40-42. 2.

[2] Velankar, A. and Mehta, A. “Latest trends in SCADA for process automation”, Proc.

National Conference on Industrial Automation and Intelligent Systems 2002, Jan. 2002, pp.

9-11.

[3] Control Engineering salary and career survey, 2013

https://www.controleng.com/single-article/control-engineering-salary-and-career-survey-

2013/cd2a03c44fa44e6f1d273c30dd7fa94c.html

[4] Rouse, Margaret. "SCADA (supervisory Control and Data Acquisition)," WhatIs,

TechTarget, Dec., 12, [Online]. http://www.techtarget.com/contributor/Margaret-Rouse

[5] Irfan Ahmed, Sebastian Obermeier, Martin Naedele, Golden G. Richard III, "SCADA

Systems: Challenges for Forensic Investigators," Computer, vol. 45, no. 12, pp. 44-51, Dec.,

2012, [Online].

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6298895

[6] Valli, C. (2009). “SCADA Forensics with Snort IDS”. Proceedings of WORLDCOMP2009,

Security and Management 2009. (pp. 618-621). Las Vegas, USA: CSREA Press.5

https://www.controleng.com/single-article/control-engineering-salary-and-career-survey-2013/cd2a03c44fa44e6f1d273c30dd7fa94c.htmlhttps://www.controleng.com/single-article/control-engineering-salary-and-career-survey-2013/cd2a03c44fa44e6f1d273c30dd7fa94c.htmlhttp://www.techtarget.com/contributor/Margaret-Rousehttp://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6298895

[7] Johnson, C. W.; Harkness, R. Evangelopoulou, M. “Forensic Attacks Analysis and the Cyber

Security of Safety-Critical Industrial Control Systems”. 34th International System Safety

Conference, Orlanda, FL, USA, 8-12 Aug 2016.

[8] Stirland, J.; Jones, K; Janicke, H; Wu, T. “Developing Cyber Forensics for SCADA

Industrial Control Systems”. Proceedings of the International Conference on Information

Security and Cyber Forensics, Kuala Terengganu, Malaysia, 2014. ISBN: 978-1-941968-01-

7 ©2014 SDIWC.

[9] Akelian, C. J. “Incorporating SCADA modules into Introductory Programmable Logic

Controller Curriculum”. 122nd ASEE Annual Conference & Exposition. June 14-17, 2015

Seattle, WA. © American Society for Engineering Education, 2015.

[10] Taveras, N. P. “Scada Live Forensics: Real Time Data Acquisition Process To Detect,

Prevent Or Evaluate Critical Situations”. 1st Annual International Interdisciplinary

Conference, AIIC 2013, 24-26 April, Azores, Portugal.

[11] Van HoaNguyen, Quoc TuanTran, YvonBesanger. SCADA as a service approach for

interoperability of micro-grid platforms. Elsevier, Sustainable Energy, Grids and Network.

Volume 8, December 2016, Pages 26-36.

https://www.sciencedirect.com/science/article/pii/S235246771630056X?via%3Dihub

[12] Guide to Supervisory Control and Data Acquisition (SCADA) and Industrial Control

Systems Security, Special Publication 800-82.

https://www.dhs.gov/sites/default/files/publications/csd-nist-

guidetosupervisoryanddataccquisition-scadaandindustrialcontrolsystemssecurity-2007.pdf

[13] What is OPC? https://opcfoundation.org/about/what-is-opc/

[14] nmap.org

[15] Ettercap Project, https://ettercap.github.io/ettercap/index.html

[16] OWASP Zed Attack Proxy Project, www.owasp.org/index.php/ZAP

[17] Wireshark Project, www.wireshark.org

[18] Microsoft Baseline Security Analyzer.

https://msdn.microsoft.com/en-us/library/ff647642.aspx

[19] Modbus Application Protocol.

http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf

[20] Hsieh, S. “Skill Sets Needed for Industrial Automation Careers”. ASEE’s 123rd Annual

Conference & Exposition. New Orleans, LA. © American Society for Engineering Education,

2016.

https://www.sciencedirect.com/science/journal/23524677/8/supp/Chttps://www.sciencedirect.com/science/article/pii/S235246771630056X?via%3Dihubhttps://www.dhs.gov/sites/default/files/publications/csd-nist-guidetosupervisoryanddataccquisition-scadaandindustrialcontrolsystemssecurity-2007.pdfhttps://www.dhs.gov/sites/default/files/publications/csd-nist-guidetosupervisoryanddataccquisition-scadaandindustrialcontrolsystemssecurity-2007.pdfhttps://opcfoundation.org/about/what-is-opc/https://ettercap.github.io/ettercap/index.htmlhttp://www.owasp.org/index.php/ZAPhttp://www.wireshark.org/https://msdn.microsoft.com/en-us/library/ff647642.aspxhttp://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf