Efficient Passive ICS Device Discovery and Identification by MAC Address Correlation
Matthias Niedermaier, Thomas Hanka, Sven Plaga, Alexander von Bodisco,, Dominik Merli
TL;DR
This paper introduces a lightweight passive network monitoring method that uses MAC address correlation to identify industrial devices, achieving high discovery and identification rates without active scanning.
Contribution
It presents a novel passive device discovery technique based on MAC address correlation, outperforming existing tools in industrial network environments.
Findings
Achieved 100% host discovery rate in testbed.
More than 66% device/vendor identification accuracy.
Outperformed existing passive scanning tools.
Abstract
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…
| IEEE RA | IEEE | EUI-48 | Comp./organ. |
|---|---|---|---|
| assignment | assigned | block | identifier |
| Company ID (CID) | 24 | 0 | yes (CID) |
| Large (MA-L) | 24 | 224 | yes (OUI) |
| Medium (MA-M) | 28 | 220 | no |
| Small (MA-S) | 36 | 212 | yes (OUI-36 only) |
| Vendor | Product | No. | MAC | IP | No. | MAC | IP | Distance |
|---|---|---|---|---|---|---|---|---|
| Rack 1 | Rack 2 | hex | ||||||
| Siemens | CPU 1211C | 00 | 28:63:36:C6:C7:D4 | 192.168.0.10 | 12 | 28:63:36:C6:CC:67 | 192.168.0.110 | 0x000493 |
| Siemens | KP 300 | 01 | 00:1C:06:35:C0:7C | 192.168.0.11 | 13 | 00:1C:06:35:C0:7B | 192.168.0.111 | 0x000001 |
| Phoenix | ILC 151 | 02 | 00:A0:45:9D:40:74 | 192.168.0.20 | 14 | 00:A0:45:9D:42:54 | 192.168.0.120 | 0x0001E0 |
| ABB | PM554-T | 03 | 00:24:59:0A:4C:B7 | 192.168.0.21 | 15 | 00:24:59:0A:58:B0 | 192.168.0.121 | 0x000BF9 |
| Crouzet | em4 B26-2GS | 04 | 84:AC:FB:00:05:E0 | 192.168.0.22 | 16 | 84:AC:FB:00:05:E6 | 192.168.0.122 | 0x000006 |
| Siemens | LOGO! 24RCE | 05 | E0:DC:A0:1C:35:85 | 192.168.0.23 | 17 | E0:DC:A0:1C:35:4F | 192.168.0.123 | 0x000036 |
| Wago | 750-889 | 06 | 00:30:DE:0C:AA:68 | 192.168.0.30 | 18 | 00:30:DE:0C:AA:6C | 192.168.0.130 | 0x000004 |
| Wago | 750-8100 | 07 | 00:30:DE:41:B9:F0 | 192.168.0.31 | 19 | 00:30:DE:41:B9:E6 | 192.168.0.131 | 0x00000A |
| Wago | 750-880 | 08 | 00:30:DE:0C:AE:84 | 192.168.0.32 | 20 | 00:30:DE:0C:AE:68 | 192.168.0.132 | 0x00001C |
| Schneider | TM221CE16T | 09 | 00:80:F4:0E:58:89 | 192.168.0.50 | 21 | 00:80:F4:0E:59:BC | 192.168.0.150 | 0x000133 |
| Schneider | HMISTU855 | 10 | 00:01:23:2D:BA:A3 | 192.168.0.51 | 22 | 00:01:23:2D:BD:7B | 192.168.0.151 | 0x0002D8 |
| Moxa | NP5110 | 11 | 00:90:E8:2A:E5:34 | 192.168.0.70 | 23 | 00:90:E8:56:78:5D | 192.168.0.170 | 0x2B9329 |
| Vendor | Products | Devices | Known Vuln. |
|---|---|---|---|
| MOXA Technologies | Networking equipment | 5242 | 80 |
| Lantronix | Networking equipment | 2126 | 6 |
| Allied Telesis | Networking equipment | 950 | 9 |
| Siemens | Automation equipment | 75 | 242 |
| WAGO Kontakttechnik | Automation equipment | 49 | 5 |
| Star Micronics | (Receipt) printer | 20 | 1 |
| Schneider Electric | Automation equipment | 14 | 113 |
| Phoenix Contacts | Automation equipment | 11 | 6 |
| ABB | Automation equipment | 6 | 18 |
| Hirschmann Industries | Networking equipment | 3 | 8 |
| Crouzet | Automation equipment | 3 | 0 |
| Total: | 8499 | 488 |
| Device | Distance | Ident. | Device | Distance | Ident. |
|---|---|---|---|---|---|
| 00 | 0x19CE87 | ✧ | 12 | 0x19D31A | ✧ |
| 01 | 0x089F19 | ✓ | 13 | 0x089F18 | ✓ |
| 02 | 0x0FE94D | ✧ | 14 | 0x0FE76D | ✧ |
| 03 | 0x00049C | ✓ | 15 | 0x00075D | ✓ |
| 04 | 0x000481 | ✓ | 16 | 0x000487 | ✓ |
| 05 | 0x117EDC | ✓ | 17 | 0x117EA6 | ✓ |
| 06 | 0x00A214 | ✓ | 18 | 0x00A218 | ✓ |
| 07 | 0x001789 | ✧ | 19 | 0x00177F | ✧ |
| 08 | 0x00A630 | ✧ | 20 | 0x00A614 | ✧ |
| 09 | 0x000102 | ✓ | 21 | 0x000235 | ✓ |
| 10 | 0x033E07 | ✓ | 22 | 0x0340DF | ✓ |
| 11 | 0x0001AC | ✓ | 23 | 0x00003D | ✓ |
| ✓ Correct identification | ❍ Only vendor identified | ||||
| ✧ Correct vendor, wrong device | ✗ No identification | ||||
| Device | Ident. | ||||||||||||||||||||||||
| Scanner | 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | Rate |
| zgrab | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | ✓ | ✗ | 25.00% |
| PLCScan | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | ✓ | ✓ | ✗ | 25.00% |
| Nmap | ✓ | ❍ | ✓ | ❍ | ❍ | ❍ | ❍ | ✓ | ✓ | ✓ | ❍ | ❍ | ✓ | ❍ | ✓ | ❍ | ❍ | ❍ | ❍ | ✓ | ✓ | ✓ | ❍ | ❍ | 41.67% |
| SinFp | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | 00.00% |
| p0f | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | 00.00% |
| Netdiscover | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | ❍ | 00.00% |
| Our tool | ✧ | ✓ | ✧ | ✓ | ✓ | ✓ | ✓ | ✧ | ✧ | ✓ | ✓ | ✓ | ✧ | ✓ | ✧ | ✓ | ✓ | ✓ | ✓ | ✧ | ✧ | ✓ | ✓ | ✓ | 66.67% |
| ✓ Correct identification ❍ Only vendor identified ✧ Correct vendor, wrong device ✗ No identification | |||||||||||||||||||||||||
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
Efficient Passive ICS Device Discovery and Identification by MAC Address Correlation
Matthias Niedermaier
Hochschule Augsburg \AndThomas Hanka
Hochschule Augsburg \AndSven Plaga
Fraunhofer AISEC \AndAlexander von Bodisco
Hochschule Augsburg \AndDominik Merli
Hochschule Augsburg
Abstract
Owing to a growing number of attacks, the assessment of Industrial Control Systems 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 ICS testbed, we reached a host discovery rate of 100% at an identification rate of more than 66%, outperforming the results of existing tools.
K****eywords industrial control systems, vulnerability scanner, programmable logic controllers, security assessment
©Efficient Passive ICS Device Discovery and Identification by MAC Address Correlation – First published in the Electronic Workshops in Computing series at 5th International Symposium for ICS & SCADA Cyber Security Research 2018 (ICS-CSR 2018) DOI: 10.14236/ewic/ICS2018.3
1 Introduction
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 [1] and described as automation pyramid illustrated in Figure 1 [2]. At the operational level of an industrial network, there are often Enterprise Resource Planning (ERP) and Manufacturing Execution System (MES) layers.
Depending on the level of integration, ICS also employs Supervisory Control and Data Acquisition (SCADA) or Distributed Control Systems, Programmable Logic Controllers, sensors, and actuators. Compared to other domains, the individual components of ICS 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 [3], 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 [4]. As availability is considered the most important IT security protection goal, active scanning methods should be generally avoided [5].
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 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.
2 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 [6] is one of the most commonly used tools. Basically, it is an application-analyzing 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. The SYN/ACK packet-based identification takes advantage of different initial Time to Live (TTL) values for Internet Protocol (IP) and varying Transmission Control Protocol (TCP) window sizes for TCP. For these values, NetworkMiner uses the database of the p0f [7] tool. Since different OSs also employ different implementations for Dynamic Host Configuration Protocol (DHCP), identification is also possible to inspect these packets. Here, the device fingerprints from the FingerBank [8] project are utilized. A similiar approach to identifiy devices by their MAC address is introcued by Martin et al. [9].
SinFP [10] 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 [4].
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.
3 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.
3.1 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.
Information related to the current allocations, including the names of the respective vendors, can be obtained directly from IEEE in different file formats [12]. 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.
3.2 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 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 [13]). 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 [14]).
- •
Routing protocols, which optimize the selection of proper routes for router communication.
4 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 time-consuming task, time estimation for a complete network device discovery was identified to be important.
4.1 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.
4.2 Interarrival Time of Packets
Estimating the time for complete device discovery coverage, the interarrival time was found to be an important key figure.
[TABLE]
Generally, 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 is composed of constituent measurements () shown by Equation 2.
[TABLE]
Equation 3 calculates the maximum time to get a packet of one device.
[TABLE]
Finally, the expected time for a complete network device discovery is calculated (see Equation 4) by using the maximum interarrival time of all devices within the monitored network segment.
[TABLE]
5 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.
5.1 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 [13].
5.2 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.
5.3 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.
6 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.
6.1 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 [15]. 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.
6.2 Interarrival Time of ARP Packets
First, 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 for the 24 devices. In 70% of the cases, an ARP packet shows up every 16–37 seconds (), not exceeding the boundary of one minute () at the worst cases. With this data, 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. This communication generates constant traffic, which could lead to a homogeneous plot. There are four Human Media Interfaces, the Siemens KP 300 [01,13] and the Schneider HMISTU855 [10,22], which communicate with the controllers Siemens CPU 1211C [00,12] and Schneider TM22ICE16T [09,22]. Because of the constant communication between them, there are more ARP packets of these devices in the pcap.
6.3 MAC Address Database
The initial device database (see Table 3) was built using data from Censys [16], Shodan [17], 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.
6.4 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 ICS. 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 [18]. 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 [19], 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.
6.5 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.
6.6 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.
6.7 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) [20], which supports the following SCADA protocols: BACnet, DNP3, Niagara Fox, Modbus, and SimaticS7. PLCScan (Git version 014480c) [21] is one of the first active scanners for industrial networks. Furthermore, the active scan of nmap (Version 7.60) [22] 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 PLC, 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 [23, 24]. Our framework was able to discover all devices in the testbed by their vendor, and about 66% of the products were correctly identified.
6.8 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.
6.8.1 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.
6.8.2 Database Quality
To identify devices by their MAC address, there must be a similarly known device in the local database. Hence, the number of entries in the known MAC address database is significant for the quality of device identification. This could be improved by community contributions.
6.8.3 MAC Randomization for Connections
In order to make it difficult to identify devices, it is possible to randomly choose MAC addresses for every new connection. This could lead to a false positive identification of a device. However, for stationary devices, especially in industrial networks like PLC, it is uncommon to randomize the MAC address.
6.8.4 Vendor Assignment Process
Vendors sometimes assign the same MAC address to multiple devices, maybe by mistake or intentionally to save money. This is not a major problem if the devices are shipped to different parts of the world. In the case of MAC-based identification, this could lead to false identifications if different products have the same MAC.
6.8.5 Static ARP Table
In a static ARP table, the MAC addresses of some or all network participants have fixed entries. It is used in static environments, e.g. to prevent Man-in-the-Middle (MitM) attacks by ARP poisoning, to use a network diode, or to reduce the broadcast traffic [25]. In this case, the ARP broadcasts used to identify the devices will not be sent, and thus, no identification is possible.
6.8.6 Firmware/Software Version
The firmware and software versions are not detected by the MAC-based identification of a device. Consequently, the vulnerability allocation is done without considering the software version. However, in many ICS, the devices are still in the delivery software state and are not patched. This information could be used to roughly estimate the firmware version of the device, which is sufficient for an initial assessment.
7 Conclusion
This paper has introduced a new method for passive scanning of critical infrastructures and provided a functional PoC. With a MAC-based discovery and identification of ICS components, a safe passive scan within ICS is possible. We have shown the feasibility of the method with a validation resulting in a total discovery rate of 100% and an identification quote of more than 66%. In comparison with existing tools, the MAC address correlation approach performed well. The minimal integration effort and the extensibility of our framework have advantages over classical scan methods and deep packet inspection.
Further, we plan to publish the code of our framework and are open for contribution to the databases. The material includes the source code of the framework, network captures, and additional information about the testbed.
With a detailed recognition of the transitions between products during the MAC address assignment, an even more detailed identification could be achieved. Therefore, some details from the vendors or a larger database of each vendor are necessary due to the vendor-specific assignment process. Additionally, the users of our approach can add known devices from an industrial plant with which similar devices in other plants could be identified.
Acknowledgement
The work on MAC-based device discovery and identification is part of the RiskViz [26] research project, funded by the German Federal Ministry of Education and Research (BMBF). We would also like to thank Georg Sigl (Fraunhofer AISEC) for his valuable feedback.
The reference list from the paper itself. Each links out to its DOI / PubMed record.
- 1[1] International Electrotechnical Commission et al. IEC 62264-1 Enterprise-control system integration–Part 1: Models and terminology. IEC, Genf , 2003.
- 2[2] Ingmar Kellner and Ludger Fiege. Viewpoints in Complex Event Processing: Industrial Experience Report. In Proceedings of the Third ACM International Conference on Distributed Event-Based Systems , DEBS ’09, pages 9:1–9:8. ACM, 2009.
- 3[3] Bonnie Zhu, Anthony Joseph, and Shankar Sastry. A Taxonomy of Cyber Attacks on SCADA Systems. In Internet of things (i Things/CPS Com), 2011 international conference on and 4th international conference on cyber, physical and social computing , pages 380–388. IEEE, 2011.
- 4[4] Adam Wedgbury and Kevin Jones. Automated Asset Discovery in Industrial Control Systems: Exploring the Problem. In Proceedings of the 3rd International Symposium for ICS & SCADA Cyber Security Research , ICS-CSR ’15, pages 73–83. BCS Learning & Development Ltd., 2015.
- 5[5] Matthias Niedermaier, Jan-Ole Malchow, Florian Fischer, Daniel Marzin, Dominik Merli, Volker Roth, and Alexander von Bodisco. You Snooze, You Lose: Measuring PLC Cycle Times under Attacks. In 12th USENIX Workshop on Offensive Technologies (WOOT 18) .
- 6[6] Erik Hjelmvik. Passive Network Security Analysis with Network Miner. IN) Secure , (18):1–100, 2008.
- 7[7] p 0f v 3, 2018. Online: http://lcamtuf.coredump.cx/p 0f 3/ - Accessed: 11.03.2018.
- 8[8] Olivier Bilodeau, David La Porte, and Eric Kollman. Finger Bank, 2018. Online: https://fingerbank.org/ - Accessed: 11.03.2018.