Figure 1: Industrial IoT applications are usually distributed across four layers. Docker-based concepts are a good choice for achieving end-to-end data integration in terms of software. Docker containers can be used in a network and can communicate with each other via application-related APIs (Application Programming Interfaces).

© Source: SSV

Applications based on edge data integration generally do not require any special hardware. In many cases, a Linux or Windows-based runtime environment with a USB and Ethernet LAN interface is sufficient. Older, but still very widespread OT interfaces such as RS232, RS485 or CAN are integrated on a USB basis if required. The situation is similar with special wireless interfaces.

Based on these minimum requirements, countless IT systems are theoretically suitable for use as edge gateways in automation. However, special environmental conditions at the installation site - vibrations, high temperatures, dust, voltage fluctuations and other disturbance variables - limit the choice of hardware somewhat.

Platform-independent through virtualization

Figure 2: A container engine with an integrated container runtime environment turns a computer module into a Docker host on which applications can be executed as individual Docker containers. In contrast to other virtualization technologies, a container does not contain its own operating system. Instead, the respective host operating system is used. The individual Docker containers are therefore relatively compact.

© Source: SSV

In the IT world, hardware or system virtualization has become established for applications that actually only require a CPU, memory and simple standard interfaces. Over the years, various virtualization techniques for creating virtual operating environments have been developed and introduced to the market. Processor virtualization with the help of a virtual machine manager (VMM) is widely used. Here, a bootable operating system is combined with the required applications in an image and executed on hardware under the control of the VMM. The more powerful this hardware is, the more images can be executed in parallel on the processor. However, as each image has its own operating system, the resource requirements are quite high. This problem was solved by the development of Docker container-based "platform virtualization". This means that there is only a single host operating system on a piece of hardware, which is shared by all applications. The individual applications are integrated into task-related (Docker container) images together with all the components required for operation and run virtually in parallel on the respective host platform. The Docker containers on a host can even communicate with each other via the Docker network (see Figure 2).

However, the provider of Docker-capable hardware for automation applications should create the corresponding prerequisites for the respective product by pre-installing a container engine with an integrated container runtime environment (container runtime) suitable for the operating system (Linux or Windows) and processor architecture (AMD/Intel, Arm) ex works or by offering the corresponding support for subsequent installation in the field. This extension turns the module in question into a Docker host. On such Docker host hardware, the user can add the required functions as edge gateway applications themselves, run them and also remove them again at any time. From a cybersecurity perspective, however, this creates vulnerabilities that definitely require a suitable solution.

Digital twin with Bluetooth data

Example: BLE-to-MQTT Docker

Figure 3: Data integration applications can be implemented using an edge gateway docker and relatively inexpensive Bluetooth Low Energy (BLE) IoT sensors to generate a high-quality data image of the respective automation landscape for higher-level IT applications. Since such a docker is integrated into various networks, the respective cybersecurity aspects must be taken into account.

© Source: SSV

In functional terms, an edge gateway docker connects an OT network with an IT network, for example. Both networks are usually IP-based and can be connected to the Docker host hardware via Ethernet. For security reasons, however, the Docker host should have two independent LAN interfaces, each of which is assigned its own MAC address. This allows a clear physical separation of the trust boundaries to be created (see example in Figure 3), as well as effective rights management and the necessary protective measures. In the illustration, the edge gateway example application is also connected to various BLE functional units via the OT network. They fulfill the following functions:

Beacon device: BLE-based sensor for recording measurement data on machine and system components. Such a sensor forms a data endpoint with a 2.4 GHz Bluetooth radio interface. In the simplest case, such a functional unit only sends sensor data via broadcast, i.e. to everyone who is within radio range and listening. In this GAP-based operating mode (GAP = Generic Access Profile, a special BLE service according to the Bluetooth standard), a beacon device periodically carries out measurements with the available sensors and sends the measurement data as BLE advertising data packets. In addition to GAP, a beacon device can also be used for GATT functions (GATT = Generic Attribute Profile, another standard-compliant BLE service). This creates a client-server connection for bidirectional data exchange between the device as a peripheral and a central device, for example to transmit updates to a device.

Figure 4: When developing an edge gateway docker, Part 4-1 of DIN EN IEC 62433 provides the guidance needed to design a LAN interface threat model, for example, to weight the identified threats using CVSS (Common Vulnerability Scoring System) and to provide, implement and comprehensively test suitable countermeasures as part of the development process.

© Source: SSV

Beacon Agent: Simple interface and data converter. On one side, an agent has a 2.4 GHz BLE radio interface for the connection to the beacon devices within radio range. The opposite side forms an Ethernet LAN interface to the OT network. It serves as an MQTT client connection to the edge docker. In terms of data, the beacon agent converts the received BLE advertising broadcasts with the measured values of the devices into JSON objects and transmits them to the edge gateway docker via MQTT. However, the Beacon Agent also serves to extend the BLE radio range. Thanks to an integrated multicast DNS function, an edge docker application automatically finds all beacon agents in an OT network.

The edge gateway docker must first pre-process all device measurement data received from the beacon agents in order to filter out multiple transmissions and authenticate the individual data sources. The relevant sensor data is then merged into a valuable data set with the corresponding time context and transmitted to the responsible digital twin via the IT network.

Standard-compliant security considerations

As the entire Docker technology is now a de facto standard that has been used millions of times in information technology for years for the delivery, maintenance and further development of application software, Docker-based edge gateway applications also create an interesting new field of activity for IT software developers. A smart factory application that is to be used directly at the OT level and communicates with the IT environment or even a cloud via Ethernet LAN can be developed completely hardware-independently using Docker containers and deployed on devices from various manufacturers with the corresponding container engine. Docker technology could therefore lead to a paradigm shift in automation technology, as the potential for a new software market segment of considerable size lies dormant here, into which more and more providers from outside the industry are already entering. However, this also gives rise to further security problems.

The author: Klaus-Dieter Walter is CEO of SSV Software Systems.

© SSV Software Systems

Docker technology was definitely not developed with cybersecurity aspects in mind. Instead, the aim was obviously to create a component-based - i.e. highly modular - solution for particularly easy-to-maintain information technology applications that can be easily replaced via an external registry if required. As IT software developers generally see an administrator as being responsible for security, it is important to ensure that networked automation applications do not become even less secure than they already are through the use of Docker containers.

One possible solution to this problem is to apply a standard such as DIN EN IEC 62443 on IT security for industrial automation systems. As an edge docker is a communication-capable automation component, the IEC 62443-4-1 part (life cycle requirements for secure product development) is particularly suitable. It specifies the requirements for the "secure development process" for industrial systems that are used in the OT environment. The entire life cycle is considered, i.e. the IT security requirements from design, secure implementation, verification, validation and mandatory patch management through to decommissioning and proper disposal.