{'fraction_non_alphanumeric': 0.02840469933529139, 'fraction_numerical': 0.00970010820837842, 'mean_word_length': 5.077266322217003, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Efficient Passive ICS Device Discovery and Identification by MAC Address Correlation

Owing to a growing number of attacks, the assessment of Industrial Control Systems (ICSs) has gained in importance. An integral part of an assessment is the creation of a detailed inventory of all connected devices, enabling vulnerability evaluations. For this purpose, scans of networks are crucial. Active scanning, which generates irregular traffic, is a method to get an overview of connected and active devices. Since such additional traffic may lead to an unexpected behavior of devices, active scanning methods should be avoided in critical infrastructure networks. In such cases, passive network monitoring offers an alternative, which is often used in conjunction with complex deep-packet inspection techniques. There are very few publications on lightweight passive scanning methodologies for industrial networks. In this paper, we propose a lightweight passive network monitoring technique using an efficient Media Access Control (MAC) address-based identification of industrial devices. Based on an incomplete set of known MAC address to device associations, the presented method can guess correct device and vendor information. Proving the feasibility of the method, an implementation is also introduced and evaluated regarding its efficiency. The feasibility of predicting a specific device/vendor combination is demonstrated by having similar devices in the database. In our ICSi testbed, we reached a host discovery rate of 100% at an identification rate of more than 66%, outperforming the results of existing tools.


INTRODUCTION
Industrial Control System (ICS) is the common umbrella term for the various devices used in industrial infrastructures. These generally consist of sensors, actuators, and embedded computers which are interconnected via network. The basic hierarchical scheme is standardized by IEC 62264 [Commission et al. (2003)] and described as automation pyramid illustrated in Figure 1 [Kellner and Fiege (2009) (SCADA) or Distributed Control Systems (DCSs), Programmable Logic Controllers (PLCs), sensors, and actuators. Compared to other domains, the individual components of ICSs tend to have a long lifetime, and cycles need to be processed in real time within certain time constraints.
Considering IT security protection goals, the established Confidentiality, Integrity and Availability (CIA) model is inverted [Zhu et al. (2011)], resulting Availability as the most important asset. In the past, most ICS components were designed to operate in an isolated network. Therefore, security was considered neglectable and development focused on functionality and on functional safety. The increasing use of Internet-based technologies as baseline for the Industrial Internet of Things (IIoT), however, has enhanced the significance of security issues. To observe the security situation of a network, security assessments are performed. These include different aspects, like situation analysis, risk identification and vulnerability scanning. The baseline for these actions is the discovery and identification of all devices present in the network. Technically, this is implemented either by active or passive scanning.
Active scanning broadcasts additional packets into a network environment and monitors the resulting traffic. Depending on strict timing constraints, the injection of additional network traffic might lead to an unexpected behavior of the connected devices within industrial infrastructures. A standard network scan could lead to a Denial of Service (DoS), or result in defective devices or an incorrect behavior of the processes [Wedgbury and Jones (2015)]. As availability is considered the most important IT security protection goal, active scanning methods should be generally avoided [Niedermaier et al. (n.d.)].
Passive scanning involves observing and capturing the packets transmitted within a certain period. This scanning scheme requires a device connected to the network to capture the network traffic. The capturing devices can be configured, limiting the captured traffic to certain packets of interest. Compared to active scans, passive scanning schemes still have to deal with a larger amount of data. Hence, it requires a higher effort in extracting relevant information, thereby increasing processing time and the demands for computational power. Considering the IT security protection goal availability, these additional efforts are compensated as passive scanning schemes can also be integrated in fragile infrastructures without impairing regular communication.
In this paper, we introduce an efficient and passive scanning and device identification scheme suitable for industrial Ethernet-based networks. On its baseline, it uses a Media Access Control (MAC) address correlation method, enabling the discovery of ICS components by analysis of their Address Resolution Protocol (ARP) broadcast packets using minimal configuration and integration effort. Without impairing the protection goal availability, the presented method is suitable for an integration to security assessment schemes of fragile or critical infrastructure networks.
The main contributions of the presented work are as follows: • We propose a passive scanning technique that can identify ICS components without impairing the integrity of critical infrastructures.
• We show the feasibility of our method and provide a publicly available implementation of a Proof of Concept (PoC).
• The used network captures from our testbed are made available to the public for further investigation.
The paper is organized in the following manner: State-of-the-art network scanners with a focus on passive fingerprinting are summarized in Section 2. Section 3 introduces the fundamentals of the MAC addressing scheme which are crucial for further comprehension. In Section 4, the challenges of MAC-based device discovery and identification are introduced. Section 5 presents the developed methodology. In Section 6, a PoC implementation and testbed evaluations are presented. Finally, a conclusion and outlook is provided in Section 7.

PASSIVE NETWORK SCANNING
This section provides a survey of currently available passive network scanners. Since the topic of device identification plays an important role, publicly accessible data sources are also listed.
NetworkMiner [Hjelmvik (2008)] is one of the most commonly used tools. Basically, it is an applicationanalyzing network to identify hosts. Using the combination of different fingerprinting methods and tools, NetworkMiner can determine the Operating System (OS) that runs on a host, enabling vulnerability detection. Since the protocol stack implementations are different for each OS, the respective protocol header construction and length also differ. Protocol (DHCP), identification is also possible to inspect these packets. Here, the device fingerprints from the FingerBank [Bilodeau et al. (2018)] project are utilized.
SinFP [Auffret (2010)] is a tool that supports active and passive OS fingerprinting. The implementation of the two concepts increases the accuracy in situations when packets are altered by mechanisms such as packet normalization or stateful packet inspection. In these cases, SinFP sends several TCP probe frames to trigger different responses. After the collection of all responses, the content of each packet is analyzed using an approach similar to p0f. Additionally, SinFP supports a pure passive fingerprinting mode. In this configuration, only captured packets are analyzed which are obtained either from the network or a file. Like the other tools, a database containing signatures and patterns is used to identify the detected devices.
After the capture of the input data for further analysis, different capture techniques are feasible. A common approach involves using a mirror port provided by a switch or a network Terminal Access Point (TAP).
In an ICS environment, however, port mirroring is not as effective as it would be in a conventional environment. This effect is caused by a huge number of small groups of devices interconnected by simple switches [Wedgbury and Jones (2015)].
Compared to the investigated solutions, the proposed method has some major advantages. First, a high identification rate of industrial components compared to existing tools is reached. Furthermore, an unused network port is sufficient for this scheme, because no special network switch feature or monitoring port is necessary. Moreover, no additional network traffic is generated in fragile ICS networks. Finally, a low effort in database maintenance compared to deep packet inspection is sufficient.

MEDIA ACCESS CONTROL ADDRESSING
This section introduces the fundamentals of MAC network device addressing, which is implemented in the data-link layer of the ISO/OSI reference model. These are utilized for device identification by the proposed method, which will be further described in the subsequent sections.

MAC Address Structure
The MAC address is a unique hardware address assigned to each network adapter. Nowadays, all known access methods with a MAC layer (IEEE 802.1), such as Ethernet, Wi-Fi, and Bluetooth, use the same MAC address format with a 48-bit MAC address as shown in Figure 2. The two least significant bits of the MAC address determine the type of the address: The Individual/Group address I/G bit indicates whether the frame is transmitted as unicast (0) or multicast (1). While a unicast frame will be sent to one specific device, a multicast frame is forwarded to a group of devices. An address consisting of 48 ones (FF:FF:FF:FF:FF:FF) is a broadcast address where all devices are addressed. The Universally/Locally Administered U/L bit is used to tell if the MAC address was taken from a fixed configuration (0) or dynamically chosen by the OS (1).
The following address types can be observed when captured network traffic is examined. If I/G is 0, then it is an individual address (Unicast Address) for a network adapter. In contrast, if I/G is 1, then the destination address is for a group of stations (Group address/Multicast address). A universal, globally unique, and unchangeable MAC address is used if U/L is set to 0, otherwise (U/L = 1), it is locally changeable.
The assignment of MAC address blocks is allocated and tracked by the Institute of Electrical and Electronics Engineers (IEEE) Registration Authority (RA). These are available in three different sizes, namely fixed length, MA-L (large), MA-M (medium), and MA-S (small), to meet the needs of vendors. The relation of the fixed portion of a MAC address to the corresponding number of possible MAC addresses is provided in Table 1.  (2018)]. These files containing the currently allocated address blocks are associated with the contact information of their holders. This allows the mapping of an unknown MAC address prefix of a network device to a manufacturer. Unfortunately, this approach does not allow any correlation with devices, since the vendor is allowed to freely assign addresses within the allocated space.

Broadcast Messages
In the data-link layer, broadcasting is the transmission of certain packets to all devices within a broadcast domain. A broadcast domain comprises hubs, switches, and bridges which can be divided by Virtual Local Area Networks (VLANs) or routers operating on the third layer. Broadcasting is used to accomplish different tasks of different protocols including: • ARP, which is used if a network peer wants to communicate with another local device on a higher layer protocol. To learn the MAC address of the communication peer, an ARP request is sent to the Ethernet broadcast address which is forwarded by all network switches. The results containing the respective MAC addresses are cached in ARP tables of the participating devices (RFC 826 [Plummer (1982)]). Since these requests are essential for successful communication, all active MAC addresses are cyclically propagated on the network.
• DHCP, which allows the network configuration to be assigned to clients by a server (RFC 2131 [Droms (1997)]).
• Routing protocols, which optimize the selection of proper routes for router communication.

DEVICE IDENTIFICATION CHALLENGES
For the proposed MAC-based security assessment, two challenges were identified. First, the approach has to determine devices from their MAC addresses even if the vendor's assignment scheme remains unknown. Since passive scanning could be a timeconsuming task, time estimation for a complete network device discovery was identified to be important.

MAC Address Vendor Assignment
Each of the devices is programmed with a unique MAC address taken from the IEEE-assigned address blocks. Parts of the available blocks are often used sequentially for various products from a company. For example, regarding MA-L ranges, Figure 3 illustrates such a possible block-wise assignment of different product types. Product types X, Y, and Z are separated in a sequential and continuous block, which are often spread across the full range. Since this information is unknown, MAC addresses have to be collected. A correlation of yet unknown devices has to be determined from that source either by direct lookup or a proper approximation scheme.

Interarrival Time of Packets
Estimating the time for complete device discovery coverage, the interarrival time t arrival was found to be an important key figure.
Generally, t arrival is defined as the elapsed time between the arrival of two consecutive packets containing the same information. It is calculated in the manner shown by Equation 1. The mean interarrival time t arrival is composed of constituent measurements (measure) shown by Equation 2.
Equation 3 calculates the maximum time to get a packet of one device.
Finally, the expected time for a complete network device discovery t coverage is calculated (see Equation 4) by using the maximum interarrival time of all devices within the monitored network segment.

USING MAC ADDRESSES FOR DEVICE DISCOVERY AND IDENTIFICATION
This section introduces the methodology developed for the MAC address-based security assessments.
Essentially, it builds up on capturing MAC broadcasts. The MAC addresses are extracted from these captures and fed to an address-identification process. These are mapped to known vulnerabilities of the identified devices.

Passive Scan Utilizing ARP Broadcast Messages
In an industrial network, there are mostly static routes with fixed network configurations. Consequently, DHCP and routing protocol broadcasts are rare. In contrast, ARP requests are performed in cases where no MAC address is cached for a certain device. The ARP cache contains a four-column table containing the protocol type, the protocol address of the sender, the hardware address of the sender, and the entry time. The expiration time for the entries is not specified by the relevant RFC 826 [Plummer (1982)].

MAC Address Correlation
To successfully correlate unknown MAC addresses to devices, a prebuilt data-pool of known devices is essential.  Figure 4 illustrates the developed device identification scheme. In this example, there are two initially known MAC addresses stored in the data-pool. Both addresses are close to a MAC address of an unknown device. The illustrated distance value is calculated from the difference between the addresses. A smaller distance increases the chance of a correct device identification. In the present case, the unidentified device is more likely to be the same product family as "Product X." This correlation is used for the passive identification of ICS components.

Mapping of Vulnerabilities
With the determined device correlation, the identification of known vulnerabilities is feasible. Figure 5 shows the relation of the vulnerability mapping. With information concerning the vendor and product name, the corresponding Common Platform Enumeration (CPE) is searched using pattern recognition. The relationship between CPE and Common Vulnerabilities and Exposures (CVE) allows the assignment of vulnerabilities to a device.

FRAMEWORK AND EVALUATION
To evaluate the feasibility of the presented method, the outlined methodology is implemented in a framework. After determining its efficiency, an industrial testbed was created where the framework was further evaluated.

Testbed Setup / Preliminary Investigations
To facilitate an examination of the MAC address distribution, the testbed contains two racks, each of which has an identical set of 12 devices. The components of the rack-mounted testbed are listed in Table 2 [Niedermaier et al. (2018)]. The last column denotes the distance, which is the absolute value calculated from the subtraction of the MAC addresses of devices of the same type. Except for those from Moxa, the devices were bought at the same time. Therefore, the distances between the MAC addresses are mostly small. Further inspection of the Moxa devices revealed different production dates and higher values for the distance.

Interarrival Time of ARP Packets
First, t arrival between consecutive ARP broadcasts for each of the connected devices is determined. For this task, MAC addresses are extracted from the ARP broadcasts captured from a 12-hour packet capture (pcap).
The results of this experiment consist of 3559310 packets, where 220988 (6.21%) are ARP packets. Figure 6 illustrates the calculated t arrival for the 24 devices. In 70% of the cases, an ARP packet shows up every 16-37 seconds (t arrival ), not exceeding the boundary of one minute (t arrivalmax ) at the worst cases. With this data, t coverage of this network is about one minute. The total number of ARP packets varies from about 1200 to 2700 over the measurement time of 12 hours. In the testbed, a continuous SCADA monitoring process is implemented, which queries the status of all devices every second.

MAC Address Database
The initial device database (see Table 3) was built using data from Censys [Durumeric et al. (2015a)], Shodan [Matherly (2009)], Google image and marketplace search, as well as previous scans from our research group. This database is locally stored and the baseline for the identification methodology is provided in Section 5.2. Figure 7 illustrates the distribution of known devices in the local database over the complete MA-L range of the corresponding vendor, with more than 500 entries. Some vendors have more than one MA-L range, resulting in more company identifiers. The dataset plots of Moxa and Allied Telesis are bundled across the lower MAC address range of the complete MA-L space. This indicates that the examined manufactures have yet not exceeded their assigned address space. Moreover, the available database entries suggest a linear assignment process.
The results for Lantronix devices indicate a different assignment process. The MAC addresses are spread over the full MA-L space, while the majority of addresses are concentrated at the upper range. This indicates a kind of randomization, as there are no larger connected groups of addresses. However, the entries in our dataset show a possible sequential block-wise assignment, which could also be a sign that our dataset is not large enough to include many devices of the same range. Eventually, it is not possible to make a final statement on the MAC distribution policy applied by Lantronics.

Proof of Concept Framework
The Proof of Concept (PoC) framework is written in Python 3 and implements automatic evaluation of MAC-based discovery and identification of ICSs. It takes a pcap file or input, or captures live traffic, analyzes it, and creates a security report on the detected network devices. The pseudo program structure of the framework is shown in Figure 8.
At startup, the local MAC databases (see Section 6.3) are imported. These are extensible Comma-Separated Values (CSV) files that store devices with their product name and MAC address. Current vulnerabilities are fetched automatically from cve details [Browse Vulnerabilities By Date (2018)]. In the next step, the IEEE MAC vendor lists, which are publicly available on the Internet, are downloaded and parsed. Subsequently, logged or live network traffic is analyzed using the pcapy tool [CORE Security (2018)], which provides access to the pcap packet capture library.  The MAC addresses of the devices found in the capture are now compared with the local database of known devices. If a MAC address of a device from the network capture is at a predefined distance from a MAC address of a known device, it is possible that these devices are the same product. Based on this information, the CVE database is used to map possible vulnerabilities to the devices.

Network Integration
The network integration for this method is easier than most of the available passive network monitoring tools, because no mirror port or network TAP is necessary. Basically, all broadcast messages containing MAC addresses are sufficient for device discovery. Figure 9 shows the integration possibility of the proposed framework in an existing network. To ensure a feedback-free passive scan, a unidirectional network diode can be placed between the switch and the scan device. For each broadcast domain, only one monitoring connection is needed.

Validation of the Proposed Scheme
To validate the method and the framework, a testbed assembled with the components of Table 2 is utilized. By probing real hardware, the methodology introduced in Section 5 and the PoC implementation are verified. The used database comprises 8499 known devices excluding the devices from the testbed which are blacklisted for the validation. The network traffic used to validate the accuracy is the same 12 hours pcap as that used for interarrival time calculation (see Figure 6). Table 4 shows the results of the validation categorized into four possible results.
Correct identification (✓): As illustrated in Section 5.2, a small distance to a known device indicates a correct identification. A distance of 0x000000 indicates that the device was clearly identified. This happens if an already identified device should be identified again, e.g. in a previous scan or in a continuous monitoring process.
Correct vendor, wrong device (✧): In a false positive identification, the identified device does not match the real one. With an increasing distance between the MAC of the captured device and the entries in the database, the likelihood of a correct identification decreases.
Only vendor identified (❍): Furthermore, it is possible that there is no match, e.g. if there is no device in the MA-L address space, leading to a distance higher than 0xFFFFFF. It is mostly still feasible to identify the vendor looking up the MAC vendor list(s).

No identification (✗):
If there is no known device in the address space and no entry in the vendor lists, no identification is possible. In total, the validation leads to a discovery rate of 100% with a correct identification rate of 66.67%, demonstrating the feasibility of our method and software. These results could be improved with a larger device database.

Comparison with Other Tools
We used three active and three passive network scanner tools, and compared their results with our framework. A popular active scanner used in the Censys project is ZGrab (Git version 6c81ce4) [Durumeric et al. (2015b)], which supports the following SCADA protocols: BACnet, DNP3, Niagara Fox, Modbus, and SimaticS7. PLCScan (Git version 014480c) [PLCScan the Internet (2018)] is one of the first active scanners for industrial networks. Furthermore, the active scan of nmap (Version 7.60) [Lyon (2009)] with Nmap Scripting Engine (NSE) scripts for BACnet, Ethernet/IP, Modbus, Nigara Fox, Omron, PcWorx, ProConOS, and SimaticS7 is used. For the passive scan, Netdiscover (Version 0.3), SinFp(Version 1.22), and p0f (Version 3.09b), introduced in Section 2, are used.
To get comparable results, all tools are evaluated in the same testbed as introduced in Section 6. The results of the comparison are shown in Table 5. The identification rate of the active scanners depends on the implementation of the protocol used in SCADA environments. If the protocol is available for the scanner, then it mostly discovers and identifies the device. ZGrab and PLCScan have found fewer PLCs, because there are fewer protocols implemented than Nmap with additional NSE scripts. Similar to our tool, Netdiscover uses the IEEE OUI vendor list and was able to detect the vendors of the devices but not the specific product. SinFp and p0f could not identify any ICS device correctly in our testbed. They only showed office components such as the server used for the evaluation. Similar results of the existing fingerprinting tools were achieved by others in the past [Caselli et al. (2013)] [Hahn and Govindarasu (2011)]. Our framework was able to discover all devices in the testbed by their vendor, and about 66% of the products were correctly identified.

Discussion of Limitations
The proposed MAC-based device identification has some limitations regarding the rate of discovery and identification. Some of these limitations, however, do not apply to industrial networks due to their structure and specific use of the connected devices.

MAC Address Spoofing
IT devices often allow specifying a MAC address of a network interface. For example, a network administrator wants to clone a device. Nevertheless, this is mostly not possible for ICS devices, because vendors do not provide this feature. Of course, attackers could bring in new devices into a network by sending ARP requests with spoofed MAC addresses. However, attackers cannot spoof ARP requests of existing devices without physical access or access to the switching hardware. Therefore, MAC address spoofing has only minor relevance for the proposed scheme.