Team82 Logo Claroty

Team82 Research

Threat Modeling Industrial Environments Using A Virtual Factory (Part 1)

Tomer Goldschmidt
/ February 29th, 2024

Executive Summary

Many of the vulnerabilities and attacks Team82 writes about and presents all over the world at conferences may seem somewhat abstract. We talk about critical vulnerabilities in industrial equipment and connected cyber-physical systems, but in reality, it’s difficult to visualize the consequences of, for example, injecting an engineering workstation with code that is downloaded to a programmable logic controller (PLC) that disrupts or shuts down an industrial process. 

We decided to throw back the curtain and help you visualize an attack against a factory floor through the use of a virtual environment called Factory/IO. We won’t be disclosing a new vulnerability or attack against operational technology. Instead, we’ll build a virtual factory inside this environment, and demonstrate a general layout and implementation of typical components, such PLCs, sensors, actuators, and an HMI as well to oversee this plant.

Building such a playground can allow us to not only simulate real world representation of a factory, but illustrate the dependencies between these systems, and also provide us a controlled environment to test different threat models and methodologies in an industrial setting. 

In part one, we’ll:

In part 2 of this series, we showcase different attack techniques on OT technologies. This information should be especially useful for IT cybersecurity staff who are new to OT. Using this type of modeling and scenario helps visualize where risk may need to be managed and how actual exploits can interrupt or disrupt processes managed by OT equipment and impact the bottom line.

Here is a high-level representation of some of the components we will use in our simulated factory environment, the protocols over which they communicate, and a display of the dependencies between these components.

Before we begin, let’s define some basic terms:

  • Programmable Logic Controller (PLC): A rugged computer that processes customized programming for particular industrial tasks. 

  • Engineering Workstation (EWS): An application—generally Windows-based—used to program and deploy automation logic to PLCs

  • HMI (Human Machine Interface): A user interface that a person can use to monitor and control industrial processes by visualizing data, tracking production processes, and monitor programming changes to devices

  • CIP (Common Industrial Protocol): This protocol, developed by Rockwell Automation, is used to organize and represent data on the OT network, as well as manage connections and messaging.

Factory Simulation Acts as Threat Modeling Testbed 

Factory/IO produces 3D factory simulations, and is generally used as a PLC training platform, the company says in its documentation. Users can build a virtual factory using its drag-and-drop interface with parts commonly found in typical industrial applications. 

Dragging a conveyor belt into our factory within Factory/IO.

Using Factory/IO, we built a simple assembly line segment that transfers pallets with merchandise through our factory. Our assembly line consists of a series of conveyor belts and a turntable that rotates according to sensors that recognize the presence of pallets in their sight. The assembly line is carefully orchestrated by the different states of the sensors. Each sensor is positioned in a way that indicates the position of a pallet on the assembly line.

A screenshot of our completed factory assembled in Factory/IO.

Connecting and Programming our PLC

The next stage for our factory assembly is the wiring of the sensors and actuators to the PLC. The PLC we intend to use is the 1756-L71 CPU of the ControlLogix series from Rockwell Automation. 

The 1756-L71 ControlLogix PLC.

In order to make our virtual factory as close to reality as possible, we synchronized the virtual PLC inside the Factory/IO software to a physical PLC. To do so we need to go to the File → Drivers screen and configure the EtherNet/CIP driver that will communicate with our physical PLC. Configuring this connection will allow the real PLC to be in charge of our factory machinery by controlling the wired sensors and actuators that we placed inside our simulated factory.

A screenshot of the Drivers view in the Factory/IO application. In this view, we configure the inputs and outputs with our virtual sensors and actuators

In order to program the PLC, we use our engineering workstation and open the RSLogix5000 (older version of Studio5000) software package to start building our automation logic using the structured text language.

We start our PLC programming by declaring the tags we are going to use in the automation script. Tags are similar to variables that hold data; they are used in industrial processes to represent a certain value of the underlying process. For example a tag can represent a temperature measurement inside a boiler and will be of the type integer. 

In our factory, we have several components that are represented by tags inside our PLC program.

For instance, the on/off state of a diffuse sensor will be represented by a boolean tag of a single bit which holds true/false values and indicates the presence of a physical object in front of the sensor.

Inside the RSLogix5000 software, we define the different components represented by IO artifacts inside the program. We can also create aliases to have more meaningful names to use inside our structured text program.

A screenshot of the engineering workstation declaring the controller tags being used.

Next we would like to write the actual code/program for our assembly line. Usually, PLCs support a wide range of programming languages/interfaces, including ladder-diagrams and structured text. We chose to write a simple program using ST; this program will be quite simple. It will sequentially bring merchandise pallets to the turntable, which turns 90 degrees, and send the merchandise further on the conveyor belt.

A screenshot of the programming view on the engineering workstation.

After writing the program, we compile and download our project to the PLC. By doing so we modify the logic stored inside the PLC, which modifies its behavior. Now the PLC controls the physical components in our factory, which start transferring merchandise on our assembly line.

The functioning assembly line when connected to the working PLC.

Setting Up an HMI to Oversee our Virtual Factory

With our PLC programmed, we next need a Human-Machine Interface (HMI) to bridge between the physical machinery on the plant floor and the human operators who have responsibility over the industrial process. This component connects to PLCs and displays their current status in a user interface. In the HMI, we can see alerts indicating different safety concerns, the status of different components, and other views critical to the proper operation of our process. The HMI is critical because it allows safe and efficient operation, and the ability to monitor and control a physical process.

To create our HMI screens, we chose to use Inductive Automation’s Ignition framework. Ignition enables engineers to create any type of monitoring panel they choose, giving them full control over its design, logic, sources, inputs, and outputs. Using their HMI screen, engineers are able to view and monitor the physical process on their production floor.

In our factory, we will create a panel that counts the number of pallets going through our assembly line. We will start by downloading the Ignition suite locally and setting up a local account.

A screenshot of the ignition framework software installation page.

After downloading the framework, we start the Ignition gateway software by opening the management panel using a browser and accessing http://localhost:8088. This gives us access to Ignition’s control server, allowing us to start configuring our HMI project.

First, we connect Ignition to the PLC over CIP on port 44818.

A screenshot of the configuration of our specific PLC connection.

Ignition has many drivers that communicate with different PLCs; in our case, a CIP driver connects to our PLC. Meanwhile a local OPC UA server (managed by the Ignition gateway software) externalizes an interface to our PLC. This OPC UA server will be used later by our HMI. Read more about OPC UA in our OPC UA Deep Dive Series.

Designing an HMI Panel

Next we download the Ignition designer application from the local Ignition web interface. This will help us design the UI for the HMI and create event-driven scripts to display our factory’s status.

A screenshot of the download page of the designer application.

Using the designer application, we can start building our HMI view, which will contain a gauge counting the number of pallets moving in our assembly line. To implement this, we create a memory tag that holds the amount value of pallets in our factory.

The editor interface showing the view we created; the counter memory tag is Highlighted on the bottom left corner.

We want this tag to be incremented each time the second_dif_sensor is on. To implement this feature we create a simple python script that is invoked each time a sensor value change event occurs.

Scripting view for the diffusion sensor “Value Changed“ event.

After saving our project we can open the HMI perspective from the web browser and monitor the industrial process in our virtual factory.

Completing Our Industrial Playground

Our factory has come together and operates as expected, all the components have been set. Now we can start thinking about what could go wrong in such a factory. As illustrated below, our physical components are connected to the PLC using the CIP protocol connection maintained by Factory/IO's own drivers. The PLC is set up by downloading the logic for operation from the EWS using the RSLogix5000 software; this is done also over CIP communication. Finally, the Ignition CIP client communicates with the PLC and externalizes an OPC UA server to supply live feed of the PLC state for monitoring on the HMI.

In part two of this series, we will explain and demonstrate some practical and theoretical attacks against factories that defenders should understand and manage risk around. This will be particularly valuable for IT security staff newly responsible for OT, a trend picking up traction within enterprises where cyber-physical systems are prevalent.

Stay in the know

Get the Team82 Newsletter

Recent Vulnerability Disclosures

Claroty
LinkedIn Twitter YouTube Facebook