Device discovery and identification in industrial networks

1.1 Motivation

The Act on Federal Office for Information Security (BSI Act – BSIG) explicitly mentions the use of attack detection systems in the Section 8a (1a) BSIG.^[1]

Therefore, operators of Critical Infrastructures are interested in testing such systems in their networks, as they are obliged to take appropriate organizational and technical precautions to prevent disruptions to the availability, integrity, authenticity and confidentiality of their information technology systems, components or processes. An attack detection system represents an effective measure for (early) detection of cyber-attacks and, in particular, supports damage reduction and damage prevention.^[2]

The German Federal Office for Information Security (BSI) works together with operators of process plants as well as discrete manufacturing facilities in order to test intrusion detection systems (IDS), which can be part of an attack detection system, at the operator’s site. This gives BSI the opportunity to record a collection of network traffic from production plants that is as heterogeneous as possible concerning used protocols, device types, and manufactures.

Interested parties (Operators) were acquired through a newsletter at the Alliance for Cybersecurity^[3] and numerous technical presentations.

While operators gain insight into several IDS, the BSI gains a broad overview of industrial networks. One goal is to improve the methods to discover and identify devices in industrial networks in order to provide support to the open source tool suite Malcolm ^[4] for network monitoring system in industrial control systems. In this context, the recording of the network traffic represents the starting point for further investigations. This paper highlights what needs to be considered in these recordings to serve as a basis for device discovery and identification. Also, it describes where and how those network data can be recorded.

1.2 Architecture and structure

To achieve the basis for device discovery and identification, corresponding network data is necessary. A prototypical implementation (see Section 6) has been done and is subject to current work. A generic architecture of the implementation is depicted in Figure 1 and shows the following main components:

Figure 1:

Generic architecture for device detection and identification.

Observation Domain

• Refers to the specific locations within a network where packets are monitored and captured, forming a set of observation points from which packet data are collected for further analysis.

Metering and Feature Extraction

• Aggregates the packet flows delivered by the observation points and extracts key features suitable for further processing.

Device Discovery

• Takes the extracted features and generates a device model from this information, describing the discovered device objects along with some topological information.

Device Identification

• Provides additional information helping to determine the identity of the device objects.

Device Inventory

• Database collecting and holding the device information.

This paper discusses the individual building blocks of the architecture shown in Figure 1. Section 2 provides an overview of the various aspects that must be considered while capturing network data. Section 3 focuses on the topic of feature extraction. Device discovery and identification are discussed in Sections 4 and 5, respectively. Finally, this paper presents the testing and evaluation environment established for device discovery and identification in this project. The experiences encountered during testing are also summarized in Section 6.

2.1 Capture of packet data

Device Discovery and Device Identification in context of this paper deal with the passive observation of packet data as the raw data source. This chapter describes various approaches of packet data capture, i.e. the collection of packet data from the network. This topic is well elaborated because it is an important topic within network monitoring.

Multiple methods exist for packet capture, with three major approaches:

Hubs

• A hub is a networking device that repeats a packet on every interface except the interface that transmitted the packet. All hosts connected to a hub see each other’s traffic. As a result, hubs are technological outdated due to speed and collision constraints. Nevertheless, a sensor plugged into an open hub port will see every packet transmitted between other hosts sharing the same hub.

SPAN Ports

• A SPAN (Switched Port ANalyzer) port is a designated switch port (may also be found on routers, firewalls or access points). SPAN is an efficient high performance traffic monitoring system to duplicate network traffic to one or more specified ports, usually to export packets to a dedicated monitoring solution. The band width of the output ports limits the amount of captured data. Three types of SPANs have to be distinguished:

  1. Local SPAN: Mirrors traffic from one or more interfaces on the switch to one or more interfaces on the same switch

  2. RSPAN: Remote SPAN is an extension of SPAN and allows to monitor traffic from source ports distributed over multiple switches

  3. ERSPAN: Encapsulated Remote SPAN brings generic routing encapsulation (GRE) for all captured traffic and allows it to be extended across layer 3 domains.

Taps

• A tap (test access point) is a networking device specifically designed for monitoring applications. Taps are used to create permanent access ports for passive monitoring on a single line. This is a packet capture solution especially on large or busy networks and it is the most expensive way to do it, but it introduces no performance penalty since it is dedicated hardware. In contrast to the SPAN port a tap works in Layer 1 (the signal level) and therefore forwards faulty packets too.

2.2 Observation domain

The network structure, as well as the location and type of observation points within the network determine which part of the network traffic can be captured:

A SPAN port depending on the configuration of the switch - may observe all the traffic (or all the traffic belonging to a certain VLAN) passing through the switch. If a VLAN extends over multiple switches an observation point per switch/per VLAN is needed for full packet capture. Such a solution requires compatible SPAN-capability on all switches which a running the VLAN. Mixture of star-topology and line-topology as found on many OT networks may require special handling (see also Subsection 2.3).

A Tap observes the traffic on a single line (one or both directions). For a more comprehensive coverage multiple taps or combinations of taps and SPAN ports are used.

2.3 The position of observation points

The optimal placement of observation points within a network depends on the specific objectives and goals of the analysis. If the aim is to provide input data for cyber attack detection it may be sufficient to observe the traffic on central points on gateways where traffic is ingressing/egressing certain network areas. However, if the aim is to discover and identify as much network devices as possible the observation of the complete network traffic is needed (full packet capture, FPC). This may require mirror ports on all respective switches and even additional taps. Multiple observation points also require an infrastructure to collect and merge different mirror streams to draw a complete picture and distribute data to corresponding applications. This can be achieved by a packet broker (PB).

2.4 Storage and replay of packet data

The processing of packet data may take place in real-time or the packets may be stored for later processing. The most common data storage format is the PCAP format,^[5] which is compatible with many analysis tools.

The processing of stored packet data requires the ability to handle the used file formats and in particular a set of separate files if the complete data is stored in several files.

2.5 Preservation of temporal relations

The analysis of temporal relations between network packets requires special considerations. OT protocols providing for real time operations (i.e. PROFINET [1]) expect prioritised processing on network switches. This priority handling has to be observed in the packet broker infrastructure.

If such traffic is stored to PCAP files the time stamps in the PCAP file originate from the PCAP writing entity, which may be far away from the network where the temporal behavior is required. This leads to a distinction between the observation point (switch, tap) and the storage point. Therefore, the PCAP file and its timestamps not always reflect the temporal relations in the original traffic.

In situations where the capturing and analyzing of network traffic are separated, additional difficulties may arise. Specifically, when traffic is first stored and then replayed for analysis later (e.g. using a tool like tcpreplay), the replay may reflect to traffic at the storage point and not the observation point.

3.1 Packet features/header parameters

Packet features are derived directly from single packets and typically represent implementation choices concerning the implementation of the communication stack. The reason for this is that the respective protocol standards (e.g. the RFCs describing TCP, UDP, ARP, ICMP) are not as precise as the reader may expect. There are some degrees of freedom for the programmer which make implementations distinguishable. As the communication stack is part of the operating system, this type of information is suitable for the detection of the type and version of the operation system (OS fingerprinting).

Two examples of tools that can be used for OS fingerprinting are PRADS^[6] and p0f.^[7]

3.2 Flow features

The most common abstraction on top of the packet stream is the flow model from which further abstractions and features are derived. The flow model originates from Netflow developed by Cisco to monitor network traffic passing through switches or routers (today Netflow is standardized as an RFC [2]). This flow model is based on the following 5-tupel of parameters identifying a flow:

1. source and destination IP address

2. source and destination port number

3. protocol (TCP, UDP, ICMP).

When a packet has the same 5-tupel attribute values then additional data are appended to the existing flow record, e.g.

1. Accumulated number of bytes and packets

2. TCP flags.

Such an abstraction concept may also be applied to layer 2 communication using e.g.

1. source and destination MAC address

2. network protocol (IPv4, IPv6, PN-RT, etc.).

A more abstract view considers only flows which are TCP connections. In this case a connection starts with a three-way-handshake (SYN, SYN-ACK, ACK) and terminates, when a RST or FIN has been observed.

An examination of concrete implementations is now warranted to provide practical examples that illustrate the theoretical concepts discussed earlier:

Netflow uses the flow approach for TCP, UDP and ICMP flows. A flow starts when a new (unseen so far) 5-tupel is observed. For connection oriented protocols a flow ends when flags like RST or FIN are observed or when no data have been received within a timeout interval (called idle timeout) (i.e. 30 s)(value may be configurable) or when a flow has been open for a certain time (called active timeout)(i.e. 15 min)(value may be configurable). In Netflow flows may be handled as unidirectional or bidirectional flows (depending on the tool and may be on the configuration).

Zeek ^[8] flows follow a more connection oriented model. A connection is started when a three-way-handshake has been observed and closed when RST or FIN has been observed. Zeek’s connection records represent bidirectional flows and cover connectionless protocols as well (e.g. UDP, ICMP).

A differentiation can be drawn between protocol and statistical parameters based on flow features. The subsequent subsections enumerate these parameters.

4.1 Interface discovery

As far as this work is based on packet data observed in the network the subject of discovery is an interface transmitting one or more packets. A packet contains both layer 3 and layer 2 information:

For layer 3:

1. Source and destination IP address and port number

2. Transport protocol

3. Application protocol.

For layer 2:

1. Source and destination mac address

2. Network protocol.

4.2 Device discovery

The observed layer 3 and layer 2 interfaces may belong together to the same device (the same communication stack) or the layer 2 interface may belong to a gateway and the layer 3 may belong to a system located in a remote subnet communicating via this gateway. The solution to this problem requires knowledge about the network structure. If it is assumed that the observation point is connected to a VLAN, the observed/discovered layer 2 interfaces are connected to this VLAN. Concerning the layer 3 interface, the local IP address ranges running on the VLAN are required. This allows to distinguish between local and remote layer 3 interfaces. In this manner, it becomes possible to establish a relationship between layer 3 and layer 2 interfaces that belong to the same communication stack. Unfortunately, this information is not sufficient to collect all interfaces belonging to a device. On the other hand, it becomes possible to identify the layer 2 interfaces that belong to a gateway device.

5.1 Database lookup

Static information in passive gathered network traffic can be used to identify device characteristics by a simple lookup in a dataset:

Media Access Control (MAC) address: The MAC address is a unique hardware address assigned to a network adapter that can be obtained by passive network traffic. EUI-48 [3] is the standardized MAC address format that consists of two parts: the first part identifies the hardware manufacturer (OUI – Organizationally Unique Identifier), while the remaining bits are defined individually by the respective manufacturer for each interface. The IEEE Registration Authority (RA) is responsible for assigning and monitoring MAC address blocks. Information regarding current allocations and the respective vendor names can be obtained from IEEE. These datasets contain the contact information of the address block holders, enabling the identification of an unknown MAC address prefix of a network device to a manufacturer. Numerous analysis tools, such as Wireshark^[9] or Malcolm, leverage this knowledge to exhibit the manufacturer of the associated network adapter. Nevertheless, as highlighted by the developers of macDetec^[10] in [4], this approach does not facilitate the mapping to device specifics, such as specific products, due to the vendors’ freedom to allocate addresses within the assigned space. The tool macDetec [4] attempts to address the challenge of identifying devices based on their MAC addresses when the vendor assignment scheme is unknown. It is based on the underlying assumption that companies typically allocate available MAC address blocks to distinct product families and assign these blocks within each family in a sequential manner. To associate unknown MAC addresses with their respective devices, the availability of a pre-existing database containing information on known devices is crucial. Figure 2 from [4] outlines the basic procedure: The figure shows two known MAC addresses that are stored in a database and compares them to an unknown MAC address. The distance between the unknown address and the two known addresses is calculated, with a smaller distance indicating a higher likelihood of correct identification. Based on this analysis, the unidentified device is determined to be more likely to belong to the same product family as Product X, which can be used for the passive identification. Moreover, it is important to acknowledge that, beyond the fundamental assumption of a sequential assignment of MAC addresses to product families, not all product manufacturers necessarily produce the corresponding network adapters in-house, but rather procures these from external companies and subsequently integrates them into their product. This could pose a potential issue in the process of assigning MAC addresses to their respective device manufacturers.

Figure 2:

Device identification based on MAC addresses in macDetec (Figure taken from [4]).

Fingerprinting using Packet features/Header parameters: As discussed in Section 4.1, header parameters of single network packets contain implementation choices made by developers regarding the communication stack. As a result, different implementations may exhibit distinguishable variations in their packet features, which can be used for fingerprinting purposes to identify hosts on a network and determine the operating system they are running. For example, SYN/ACK packet-based identification approach uses e.g. initial Time to Live (TTL) values for IP and varying TCP window sizes to identify hosts on a network and determine their operating system. Tools like p0f^[11] utilize this approach for passive network fingerprinting. Additionally, p0f can identify application software (e.g. Firefox or Safari) through fingerprints extracted from packet headers of HTTP requests and responses. Besides HTTP, other approaches involve extracting fingerprints from application layer protocol packet headers to identify the operating system. For example, the Satori^[12] tool uses fingerprints from protocols like DHCPv4, DCHPv6 or SMB. Both p0f and Satori offer a database mapping fingerprints to the corresponding operating system or application software.

5.2 Data-driven analysis

The prevalent method employed in research for device identification involves the utilization of machine learning techniques. This approach involves the extraction of relevant features from recorded network traffic, followed by the classification step using supervised machine learning methods. The classification process is facilitated by the availability of establishing ground truth data, which serve as the labels for the classification task. A inquiry into current research has indicated that the topic of device identification is most frequently investigated within the context of Internet of Things (IoT) applications [5–9]. As noted by Sivanathan et al. in [7], within the domain of IoT device manufacturing, it is customary for manufacturers to incorporate network interface cards (NICs) provided by external vendors. Therefore, the Organizationally Unique Identifier (OUI) prefix of the device’s MAC address may not contain any meaningful information about the IoT device itself.

In the case of IOT SENTINEL [5], device fingerprints were established using 23 features extracted from the first 12 transmitted packets, with the MAC address serving as the primary identifier. Packet (e.g. IP options), protocol (e.g. binary feature indicating if one of the following application protocols is used: HTTP, DHCP, NTP) and statistical features (e.g. destination IP counter) were used to perform the classification using Random Forest.

IoTSense [9] employs the packet and protocol features similar to IoT SENTINEL, but removes the statistical features, which were considered irrelevant to the device behaviour [9]. Furthermore, the TCP Payload Length, TCP Window Size, and payload entropy features were added. Based on this feature set a variety of classifiers were evaluated, including k-nearest-neighbours, decision trees, and gradient boosting.

The work of Hamad et al. [8] differs significantly from that of IoTSense and IoT SENTINEL due to their utilization of a wider range of statistical features in conjunction with traditional packet (e.g. TTL) and protocol (e.g. port numbers) attributes. They incorporate features such as inter-arrival time (IAT) and frequency values that are obtained via the application of Fast Fourier Transformation (FFT). Based on the high usage of statistical features, different classifiers such as Support Vector Machines, k-nearest neighbor, and Random Forest were employed.

Sivanathan et al. [7] use naïve Bayes and Random Forest classifiers. To synthesize the attributes from the trace data, the raw pcap files were initially transformed into flows on an hourly basis utilizing the Joy^[13] tool, which employs a flow-oriented model akin to IPFIX or Netflow. Subsequently, the following features were extracted to create the fingerprint: packet features encompassing the employed cyber suites, protocol features encompassing DNS and NTP queries, port numbers, and rather statistical features such as flow volume, duration, rate, and sleep time.

In IoTDevID [6], the authors initially extracted all feasible packet header information from the PCAP file resulting in 111 features. Additionally, they incorporated features such as entropy of the packets or the source and destination port class (well-known (0–1023), registered (1023–49,151) and dynamic ports (49,151–65,535)). Following this, a feature selection process was undertaken to decrease the dimensionality of the feature space. Subsequently, various classifiers were evaluated to ascertain the effectiveness of the approach.

The analysed publications highlight the importance of extracting features from network information, where Layer 2 frames or Layer 3 packets often involve information from two devices. Preprocessing the network data to transform it into a device-based representation is an often-used step before applying machine learning algorithms. This step often involves filtering the network data based on the outgoing network data of a device, typically identified by its MAC or IP address.