Virtual Control System Network
|Duration||Fall 2017 - Spring 2018|
Welcome to the wiki page for the Virtualization of Industrial Control Systems capstone project at the University of Idaho. Here someone can find all the information you need to know about the project, such as the background, specifications, design choices, team information, and document archive.
- 1 Project Overview
- 2 Design
- 3 Project Learning
- 4 Team Bios
- 5 Documents
The goal of this project is to create a portable system for presentations about security in virtual control systems. Previously this role has been filled by a physical system containing a relay, PLC, gateway, RTAC, and a HMI.
The current physical system has two major drawbacks, flexibility and portability. Because the system is hard-wired with a fixed number of devices it cannot be reconfigured to run different types of simulations and presentations. This also means that as new technology comes out is difficult to implement it into the design. Although the previous system was designed with portability in mind, there is a limit to how portable a system can be while implementing physical devices. The bulk of the device means that it cannot be moved easily or brought on board a plane as a carry-on. This is an issue, as it limits the audiences it can be presented to due to the logistics of transport.
By creating a virtual parallel of the previous model, we can have its full functionality while adding on key features. Because it will no longer be hard-wired together the new network will be reconfigurable with ease, allowing much needed flexibility. This also means that adding new devices and duplication of old devices will be quick and easy, allowing for large-scale complex networks to be created and tested. Because the entire system is virtual, it can be hosted on a remote server and accessed anywhere with an internet connection, making it as portable as a laptop.
Below are listed the project goals of things that will be included in our virtual system
- Relays - Gateways - Firewall - RTAC or similar device - Backend data emulator - Human Machine Interface - Communication channels between devices using industry standard protocols - Documentation to allow the project to be taken up by other teams in the future
|10/25/2017||Project learning primarily completed|
|11/15/2017||Virtual relay prototype|
|11/29/2017||Human machine interface prototype|
|12/6/2017||Basic communication between relay and HMI|
|12/15/2017||Expanded virtual relay prototype|
|1/17/2018||Gateway created and basic networking achieved|
|1/31/2018||PLC prototype implemented|
|2/14/2018||Backend input emulator prototype implemented|
|2/28/2018||Polished networking and simplified setup|
|3/28/2018||Stretch Goals and Polishing|
The infrastructure for this project will be a Linux server hosted externally (during development this will be on an Amazon Web Services hosted server, then during use it will be hosted on a server owned by PNNL for use and further development). We will use Docker containers for each individual component of the industrial control system. These component Docker containers will communication over a Docker Virtual Network using the modbus protocol (a common protocol used in industrial control systems). The infrastructure will be created such that in the future this can be extended to include other common communication protocols such as DNP3.
The relay will be written from scratch in C++. the basic structure of it includes three threads; an input thread, a communication thread, and a control thread. The input thread is where data enters the relay from, it connects to our custom-made data emulator. The input data is then passed over to the control thread. The control thread is the core of the program, and implements user-defined logic on incoming data. Based on this data it will update the control state and push both the input data and control state to the communication thread. The communication thread has two main jobs, outbound and inbound communication. Data and the control state are pushed to the communication thread by the control thread, the communication thread must then package these up as modbus packets and send them to a control device. For inbound communication, the input thread is constantly listening for a control order from the control devices on the network, when one is received it is sent to the control thread so it can be acted upon.
The gateway will be a standard simple gateway implemented using a slightly modified Linux system. Example of this are readily available online, and simple to set up. The gateway sits on the edge of the network to manage communications.
The firewall will exist on the edge of the network to ensure no improper communication enters or exists the network.
This is a control device in industrial control system networks. The control device will implement higher level logic on incoming data, and works to allow harmonious operation of the control system network. It will sometimes preprocess data before sending it to a server to be saved an analyzed. The control device is also a window for human users to interact with the network, converting commands to modbus requests.
Back-end Input Emulator
This will feed data into the relays, and will be implemented as a plug-in. The data this feeds will be based off of real world data, obfuscated to protect privacy. There will be options to play a simple loop of data specified by the user, or to randomized the data even more, for random input to be used in network testing.
Human Machine Interface
The Human Machine Interface (HMI) will be created with a simple base developed using python with flask. Initial iterations of it will poll slave devices (such as relays) for data to display. It will have a simple file system to enable cashing of information such as slave device IP addresses, and to enable other convenience features. In future iterations it will be able to send a interrupt communications to slave devices to force certain actions to be taken (such as manually switching a breaker when doing maintenance or testing).
Implementation details and design iterations will be listed here
Joey is a Computer Science student from Kirkland Washington. He is a member of the University of Idaho Cyber Defense team, and enjoys rock climbing and backpacking in his free time.
Gabe is a man of mystery with years of experience working in professional IT and web development. In his free time he enjoys long bouts with Compilers assignments and martial arts.
Ben works for the University of Idaho as a systems administrator, managing servers used for research. In his free time he enjoys exploring new programming languages (Rust is a favorite of his), and amateur radio.
Ben Merritt (firstname.lastname@example.org)
Gabe Gibler (email@example.com)
Joey Chereck (firstname.lastname@example.org)
Jessica Smith (email@example.com)