Whitelisting for Characterizing and Monitoring Process Control Communication

Abstract

In recent years, industrial control systems (ICS) used in critical infrastructures have come under the spotlight as a powerful target to potentially harm broader segments of society. Although there is a growing body of anomaly detection approaches in this field, the homogeneous network traffic narrative that is supposed to justify their potential success is poorly proven. At the same time, more and more machine learning (ML) schemes have been developed for this purpose neglecting though that ML is not the ideal approach for various profound detection aspects in operational technology (OT) networks. In this paper, we present and evaluate a communication whitelisting approach for anomaly detection in OT networks and point out advantages of this allegedly ancient monitoring method compared to machine learning. For this, we introduce measures to express the variability of network traffic and use them to quantify the communication dynamics of traffic for different OT infrastructures and network layers. We show that due to the static network communication in the OT domain the detection capability is sufficiently high without whitelist explosion or runtime concerns.

A Specific Whitelist’s Generation for Snort

As a prerequisite to follow the description, an exemplary Snort rule is shown in Fig. 7.

Fig. 7.

Example of a Snort rule

Device-orientated Rules. Device-oriented Snort rules are created from the address information of the general rules of this class. Since only IP-based network traffic can be specified by Snort rules, all MAC addresses have to be removed from the applied address sets. A set of addresses A filtered by IP addresses is called $A' = \{a | a \in A \cap \mathtt {A_{IP}}\}$. The mapping of the general rule $r_{U}$ is done using the set $A(D)' = \{a_{1}, ..., a_{i}\}$ as follows:

As Snort operates in blacklist mode, the exclamation mark as negation operator is used which causes the rule to trigger an alert whenever a device with an unknown IP address acts as a sender. The keyword any specifies the complete value range of the respective header element (destination IP addresses, and source/destination ports). Accordingly, the mapping of a rule $r \in R_{K}$ with a source address $a \in A(D)'$ and the corresponding address set $A_{dst}(a)'$ is done accordingly to (1) in case $A_{dst}(a)' \ne \emptyset$, otherwise to (2):

Communication-orientated Rules. To map general communication-oriented rules, Snort header elements and Snort options are used. Since only rules for the specification of IP-based communication can be mapped here as well, further notations of the sets used for the mapping are given first. We denote the set of address tuples $A_{C}(D)$ filtered by IP addresses as $A_{C}(D)'$, the set of messages determined for an address tuple ${a_{C}}'$ as $M({a_{C}}')$, and the aggregated sets from these as $T({a_{C}}')$, $P({a_{C}}')$, and $U({a_{C}}')$, respectively. For a definition of allowed transport-oriented protocols, the protocol field of the Snort header is used. Since the application of the negation operator is not provided for this element and also no list can be used, the mapping is done by several Snort rules if necessary. To this end, the set of transport protocols to be mapped $T_M = \{t | t \in T_{S} \setminus T({a_{C}}')\}$ is determined, where $T_{S} = \{ip, icmp, tcp, udp\}$ corresponds to the set of protocols that can be used in the header. A Snort rule is created for each $t \in T_{M}$:

The generation of Snort rules for the specification of legal application-oriented protocols is basically done by mapping the set $P({a_{C}}')$ to the protocol header element as well as the fields source_ports and dest_ports. The first step here is to create a set that contains all port numbers in combination with the transport protocol. It specifies the set of legitimate application protocols:

$$\begin{aligned} P_{S}(P({a_{C}}')) = \{(t, P) |&t \in t(p_{C} \in P({a_{C}}')) \cap \{tcp, udp\}, \\&P = \bigcup \limits _{p_{C} \in P({a_{C}}'): t(p_{C}) = t} p(p_{C})\} \end{aligned}$$

However, a Snort rule can only be created from this set if there is a distinct client-server relationship between the communication partners regarding the packets to be specified by the rule. If the corresponding services are hosted by the destination component the mapping is as follows:

If the services are provided by the source device the values of the source_ports and dest_ports header fields are swapped. To determine the server component of a specific service the following strategies with descending priority are used:

• 1. Message types: For typical client-server-oriented services, the observed message types provides immediate information about the device role. For example, in the case of DNS, when a request message is detected, the sender is considered as a client and the target device as a server.

• 2. Connection establishment: In case of TCP-oriented services, an observed connection establishment can be used for the assignment, whereby for the first (or third) packet of the three-way handshake the sender is considered as the client and the destination as the server.

• 3. Heuristic: The heuristic role determination is based on the subgraph resulting from the communication graph filtered by the protocol used to transmit the messages used for service provision. If a service is used by multiple clients the server can be identified by the associated node in the graph with the highest node degree (indegree and outdegree).

Since the differntiation of message types relies on the protocol-specific decoding of packet payload data, there is no generalized way to map message types specified by general rules to a set of Snort rules. We present two exemplary ways.

Preprocessor Usage: Some existing preprocessors already allow explicit logging of packets with specific message types being transmitted. For Modbus packets, for example, the option modbus_func (Modbus function code) is available for this purpose. Since negation and the specification of multiple values are also not provided when using this option, a rule must be created for each non-permitted Modbus message type. For example, packets sent from $a_{src}$ to $a_{dst}$ to request coils status are logged by the following rule:

Use of Payload Detection Options: Snort can be extended by further preprocessors for the detection of message types of arbitrary protocols. However, since the proposed method is primarily intended to support existing unmodified tools, the development of any extensions is omitted. Because the message type is often encoded in the first bytes of the payload, another way to detect different message types is to use options for payload investigation, such as content and byte_test, which selectively examine byte values for one given pattern. Another possibility is provided by the pcre option which can be used to specify a set of patterns of illegitimate message types by means of a regular expression, thus requiring only one rule to be created per PDU-specific communication relation. If, for example, all read requests from $a_{src}$ to $a_{dst}$ should be logged, the following rule can be used as an alternative to four different rules using the modbus_func option: