SSV Software Systems
Transparent and secure connection points
Connections between OT and IT networks require suitable methods and processes to create the necessary usage transparency. Furthermore, potential attack attempts should be detected at an early stage, prevented immediately and any recurrence ruled out.
The number of possible OT/IT connections is relatively static in most applications. New connections are created by configuration changes within the OT environment, such as the reinstallation of an OT module or an ICS (Industrial Control System). In this respect, the following two measures can be used to optimize the cyber-secure operation of the connection points.
1. initial data traffic analysis
An additional Ethernet switch with a SPAN or mirror port is connected to the physical connection between the OT and IT networks (SPAN = Switch Port Analyzer). Such a special port is used to mirror the network traffic between other LAN switch ports for monitoring tasks, i.e. after appropriate pre-configuration, for example, one port each in the direction of the OT and IT network (see image). The output data from this mirror port is forwarded to a suitable data logger, for example to a network sensor for intrusion detection systems (IDS). Such network sensors offer a wide range of configuration options and can therefore be adapted to the individual task.
| Field name | Field description | Example: cid |
|---|---|---|
| cid | Connection identifier. Unique ID of the respective session data. | 1 |
| cstime | Connection start time. Time at which the connection is established or the first data packet of a session (e.g. Unix Time Stamp format). | 1699529071 |
| cstime | Connection end time. Time at which the connection is terminated or the last data packet of the session. | 1699529123 |
| proto | IP payload identifier. Protocol identifier, e.g. TCP = 6. See the "Assigned Internet Protocol Numbers" of the IANA. | 6 |
| saddr | Source IP address. IPv4 address of the system that starts the session by sending the first data packet (source system for establishing a connection). | 192.168.0.1 |
| sport | Source port number. TCP or UDP port number of the source system | 55202 |
| spkts | Source-to-destination packet count. Number of IP packets transmitted from the source system to the destination system within the entire session. | 1 |
| sbytes | Source-to-destination byte count. Number of bytes transferred from the source system to the target system within the entire session. | 44 |
| daddr | Destination IP address. IPv4 address of the system with which the session is requested (i.e. the target system with regard to establishing a connection via the first data packet from the source system). | 192.168.0.126 |
| dport | Destination port number. TCP or UDP port number of the service on the target system to which a connection is to be established or whose services are to be used. | 7777 |
| dpkts | Destination-to-source packet count. Number of IP packets transmitted from the destination system to the source system within the entire session. | 6 |
| dbytes | Destination-to-source byte count. Number of bytes transferred from the destination system to the source system within the entire session. | 264 |
Log data with the respective connection data of the typical dialogs between as many OT and IT applications as possible is required for the initial data traffic analysis. However, such connection logs or transaction logs do not contain every single Ethernet LAN or IP data packet of a connection, but only representative key figures of the individual TCP or UDP sessions - each session practically generates a single data element. In other words, a TCP session between a web browser and a web server, in which several tens of megabytes of data were transferred in both directions due to multimedia content, generates between 50 and 250 bytes of data, depending on the log data format selected (see example in the table). In order to be able to generate such compact session logs, however, the network sensor requires special capabilities, such as those found in the open source software Netfilter (Conntrack) or in the Zeek Network Security Monitor. Suitable data formats for log data storage are CSV data structures (comma-separated values) or JSON objects, which can be stored directly in a NoSQL database. The widely used PCAP (Packet Capture) format is less suitable with regard to the subsequent data analysis and efficient use of the data for subsequent attack detection.
In the subsequent data analysis by an IT expert with additional expertise in the common automation protocols - Modbus, Profinet, OPC UA - it must be possible to clearly determine the data patterns of the typical dialogs between all OT and IT applications. If the data analysis reveals that special UDP-based service protocols such as Apple, Bonjour or UPnP are also searching for corresponding devices via the OT/IT connection point in the OT network, the firewall of the relevant connection process should first be configured accordingly. In practice, several iteration loops of data collection and data analysis are required before sufficient sample data and data analysis results are available for each OT/IT application dialog.
Attack detection
For cyber-secure operation, all OT/IT connections should take place via defined and documented processes (above). Each connection process also includes an initial data traffic analysis to determine the typical data patterns of the communication dialogues and to optimize the firewall rules if necessary (bottom). The resulting data is also suitable for detecting attacks.
© SSVA solid and comprehensive knowledge base about the details of possible attacks, which can be used effectively in practice to prevent successful attacks, is still a major challenge due to its complexity. The German Federal Office for Information Security therefore recommends that all organizations that can be assigned to the critical infrastructure use the MITRE ATT&CK-ICS matrix in the document Orientation guide for the use of attack detection systems (BSI-OZA). In this case, "ATT&CK" stands for "Adversarial Tactics, Techniques and Common Knowledge" (see web tip). It contains a linked matrix overview of TTPs - techniques, tactics and procedures - with twelve columns, each of which represents a specific tactic. Specific sub-techniques with individual alphanumeric identifiers are then assigned to each of the attacker's sub-targets. For example, if you click on "Module Firmware" (ID = T0839) in the "Persistence" column, a comprehensive explanation of how an attacker could permanently anchor a malicious firmware in the ICS attack target appears. If you want to or have to deal more intensively with attack detection in your own OT, it is helpful to take a closer look at the MITRE ATT&CK-ICS matrix. Organizations that fall under the new version of the IT Security Act "IT-SiG 2.0" have been practically legally obliged to do so since 1 May of this year.
Relatively independent of possible attack details, a clean OT/IT network separation (see the connection process in the image) within the organization-wide network infrastructure provides an effective control point for communication data-based OT cyber attack detection. As a result of the initial data traffic analysis, there is also a transparency-creating (log) data model with sample data for normal OT/IT communication. Furthermore, it can be assumed that the configuration of the connection process firewall prevents all unnecessary network traffic. In other words, practically everything that is not necessary for the dialogs between OT and IT applications. In this respect, the next step would be to select the technical options for attack detection and integrate them into your own connection process. The most important building blocks to choose from would be
Anomaly detection: this involves monitoring all data traffic at the OT/IT connection point - preferably in real time - using a suitable machine learning algorithm to identify and report patterns that deviate from normal OT/IT communication based on the communication data. The data structures and results of the data traffic analysis can be used for the required ML configuration and training phase.
IDS or IPS: An intrusion detection system (IDS) is a software function that scans the data traffic of a communication connection for known attack patterns in order to report suspicious activities. The traffic data can be compared with the fingerprints of known attacks in real time or with a time delay by evaluating log files. If a defensive measure is automatically initiated when an attack is detected - for example, blocking a port in a firewall - this is referred to as an intrusion prevention system (IPS).
SIEM system: A SIEM system (Security Information and Event Management) is usually a centralized, organization-wide security solution in which as much correlating sensor data as possible from different measuring points is combined to form an overall picture or context and meaningful alarm messages are generated. They signal potential security threats and help to identify and rectify vulnerabilities in good time.
SOC : 24/7 round-the-clock monitoring 365 days a year by a team of IT experts as a central security instance is generally referred to as a Security Operation Center (SOC). The depth of tasks depends on the respective organization and the individual objectives. In addition to monitoring and defending against IT security incidents, the SOC's tasks often also include prevention and compliance management measures.















