What has long been commonplace in office IT is still rarely used in the manufacturing environment: The use of a security control center that provides an up-to-date overview of the status of information security. In industry in particular, however, appropriately adapted solutions could make a significant contribution to secure production. This is precisely the aim of the 'Visual Security Control Center' sub-project within IUNO. In other words, the aim is to record data streams in production in real time and, based on this, to display relevant data on the current status of information security in a holistic and clear manner. Deviations in production become immediately visible and the participants in a production network are transparent and clearly identifiable. Companies are therefore able to intervene quickly and efficiently in the process at any time before the production process comes to a standstill.

With the current state of technology, however, the collection, analysis and transmission of required safety-relevant data with different communication partners in a production network is often very complex. To address this problem, the IUNO partners are developing tools that are able to collect the relevant data and detect any attacks. At the same time, a visualization component is being developed that displays and evaluates the 'real-time' status based on the tested tools.

Recognize anomalies

Figure 1: The architecture of the error detection system developed in IUNO.

© Volkswagen

An error detection method developed in IUNO serves as a tool for detecting deviations at protocol level. The aim of the method is to identify misbehavior on the basis of data that is extracted and parsed from the network. So-called network taps are to be integrated into existing communication paths and prevent intervention in the network without retroactive effects (collection in Fig. 1). This means that even if the anomaly detection tools fail, there can be no adverse effects on ongoing production operations.

In the first step of processing, the data extracted there must be parsed, i.e. broken down into a format that can be processed. One challenge here is the fact that numerous different protocol types have become established in the industry today. To be able to process information, a protocol-specific parsing method must be developed. In this project, both common protocol types - such as Ethernet, ARP, IPv4, TCP and UDP - and industry-specific protocols, such as Profinet IO/CM, Modbus and OPC UA, were implemented as part of this application. In addition, two test systems were implemented that have Modbus and Profinet communication.

In simple terms, the data extracted from the protocols contains an address and a corresponding value. The address, which is made up of several components, is more complex to process. In Modbus, for example, the address part consists of the IP address, the port, the slave ID and the number of the selected register, whereas the address part in Profinet consists of the MAC address, the frame ID, the slot and the sub-slot. Up to this point, the addresses that can be clearly assigned to an actuator or sensor and the respective data or values are known.

However, the associated devices and their functions are still unknown. This information cannot usually be derived directly from the network traffic and requires additional sources of information, such as configuration files from the respective control software (preparation step 2). The interpretation of Modbus messages in OpenPLC controllers, an open source approach for standardizing industrial controllers, is carried out with the help of the OpenPLC Modbus configuration file, the OpenPLC assignment instructions and the operating program (ST file) of the system. The Profinet data packets in Simatic installations can be interpreted in two ways: Firstly, it is possible to parse the required information from the context manager protocol, which is based on DCE/RPC and UDP. The prerequisite for this is that the data is actually transferred (e.g. when the system is restarted). On the other hand, the value assignments can be derived directly from the configuration file of the controller, as the values are assigned in identical sequence via the context manager. With the additional information obtained in this way, all devices, their addresses and the respective values from the network traffic can be monitored.

In order to be able to use the information extracted from the data packets, the next step - processing - requires a method that models the initial state or normal operation of the system. The calculated values of the model are to be compared with the data packets sent in the network and thus allow statements to be made about irregularities or malfunctions. The behavior of a system is defined by the program code of the controllers, which is why it makes sense to simulate the programs executed there to create the models. The output values of the simulations then serve as reference values.

The programming languages used in the test environments are OpenPLC using Structured Text (specified in IEC 61131) on the one hand and Step7 using SCL (specified in Simatic S7-SCL) on the other. To enable the simulations, it is necessary to develop an intermediate language that converts Structured Text and SCL into an executable program. A parser, interpreter and, if necessary, a compiler must be developed for this language. The programs to be simulated are then transferred into the intermediate language via translation routines. The latter consists of algebraic operators, assignments and an If-Then-Else construct, whereby the programs can be mapped with little effort. The corresponding programs are executed in the interpreter if they are addressed via corresponding input values in the network traffic. All output values of the simulations are additionally marked with a prefix 'SOLL_' in order to compare them with the ACTUAL values of the data stream in the further course.

In the detection phase or during evaluation, it is possible to compare target values or monitor state transitions. For setpoint comparisons, a condition must be defined according to the following scheme:

Anomaly name (trigger list) { condition list }

The trigger list is evaluated by the intermediate language at the end of the simulation phase. If a value in the trigger list has changed compared to the previous evaluation, the condition list is processed. If one or more conditions apply, a message is generated. State transitions are defined according to the following scheme:

Transition Name (trigger list) { ConditionOld -> ConditionNew, ... }

Permitted state changes are defined for state transition monitoring. Here too, the conditions are evaluated as soon as a variable in the trigger list changes. However, no message is generated if 'ConditionOld' applies both before and after the change or if 'ConditionOld' applies before the change and 'ConditionNew' applies afterwards. In all other cases, a warning message is generated. All messages can either be output to the operator or transferred to a database. A control station can read the required information from the database.

Finally, the visualization component aims to display relevant data on the current status of information security in a comprehensive and clear manner. This means that deviations in production are immediately visible and can be corrected. The graphical web interface has a wide range of functions to meet individual requirements and is also flexible in its design. In particular, great importance was attached to creating a responsive design, which guarantees the design character and the associated functions on a wide range of end devices such as smartphones, tablets or control station monitors.

For ease of use, the interface is optimized for touch operation in addition to classic operation. So-called dashboards can be created individually for different areas or users and have a modular structure. A configuration view can be activated for this purpose, in which different diagram types (e.g. heat maps, bar charts, pie charts) can be added to three predefined areas using drag & drop. Preconfigured elements from the three areas of security, network and devices are already available. After exiting the configuration view, the elements can be resized and swapped with other elements to generate any dashboard view. Removing the elements is just as easy by dragging them into a predefined area, similar to Android interfaces.

The practical implementation of the security control center

Figure 2: A robot assists the worker during assembly - the visual security control station was implemented and tested at Volkswagen using this demo application.

© Volkswagen

The visual security control station will be demonstrated within the framework of IUNO in the form of an excerpt from engine production. The partners will use a demonstrator to show how brackets can be fitted to a cylinder crankcase in flow production for onward transportation in production. In this scenario, a robot developed at Volkswagen for human-robot cooperation works closely with an employee. The intelligent assistant picks up a part from the parts store, transports it to a waiting position and waits there for the worker. As soon as the employee is ready to assemble the cylinder crankcase, he gives the robot a signal. The robot then brings the bracket as close as possible to the cylinder crankcase, as shown in Figure 2. The worker screws the part to the housing and then signals the robot again. This completes the process. The robot then returns to the parts store and picks up the next part to assemble the brackets for further cylinder crankcases.

If there are any deviations in the production process, the control station is able to recognize incorrect commands or external intruders in the company network. In the test environment, this is done using a series of exemplary attacks. Despite the many automated processes, humans have a key role to play. Ultimately, it will be their task to correctly interpret the messages and alarms from the detection tools in the control center so that they can quickly intervene in the process.

Authors:
Ricardo Hormann is a project manager in the Shopfloor IT department at Volkswagen;
Stephan Teuber is a project manager in information security at Volkswagen.

The IUNO project

IUNO is a publicly funded research project of the Federal Ministry of Education and Research (BMBF). 14 industrial companies and seven research institutions are pursuing a common goal: securing the production of tomorrow against external attacks, in particular espionage, sabotage and manipulation. A total of four demonstrators are being developed in the project, each led by an industrial partner. In detail, the following sub-aspects and use cases are involved:

• secure data / technology data marketplace(IUNO research project - Part 1: The technology marketplace)
• Secure processes / customized production
• secure services / remote maintenance of production systems
• secure networking / visual security control center

IUNO on roadshow

Anyone wishing to find out more about the Visual Security Control Center will have the opportunity to do so at the IUNO Roadshow. Specialist presentations and the demonstrators developed in IUNO will illustrate in a practical way how the transferable solutions can be successfully integrated into companies. Participation in the events is free of charge. The upcoming dates:

• June 13, 2018: Bosch Rexroth, Lohr: Secure services - remote maintenance of production systems
• June 26, 2018: Volkswagen, Wolfsburg: Secure networking - visual security control station
• 13 September 2018: Homag, Schopfloch: Secure processes - customized production
• September 27, 2018: IUNO, Berlin: Secure Industry 4.0 - Tools and Methods (closing event with the entire consortium)

More information and the registration link can be found online.