Industrial Control Systems (ICS) can be defined as any systems used to monitor and control industrial processes, such as the ones in power plants or water treatment facilities. They are typically composed in several sub-networks, with each having its own purpose. The corporate network is where the business part of the company resides, the control network is where the Master Terminal Unit, responsible for the monitoring and control, is located and the field network includes the Programmable Logic Controllers (PLC) connected to actuators and sensors which interact with the physical world.
Figure 1: ICS Architecture
Historically, ICS were isolated and proprietary systems but nowadays they evolved to highly interconnected systems relying on IP-based networking components. This transition led to the discovery of many vulnerabilities in the ICS networks. ICS network protocols were originally proprietary, so the only security they provided was through obscurity. They had no security mechanisms such as authentication or encryption. Even though, they have been adapted to IP technologies, it is still the case.
Two-level Intrusion Detection System
Because of their nature, ICS network have constraints complicating the way to secure them. As an example, they require extreme availability so patching and updating equipment is hard, to the extent that many ICS employ outdated hardware and software. This is one of the reasons, why network-based intrusion detection system (IDS) has been privileged solution by researchers as it does not require modification on endhosts(e.g PLCs).
In the original paper, we proposed a Two-level Intrusion Detection System. Our IDS leverages the whitelisting approach, which consists of having a list allowed communications, and Software Defined-Networking (SDN), a net-working paradigm where the routing decision are taken by a centralized unit called the controller instead of being taken by network devices.
Figure 2: First level redirection
First Level: Whitelisting
Our first level is composed of two whitelists:
A flow whitelist, where the entries are the allowed communications in the ICS networks and
Modbus whitelist is a popular protocol used in ICS. It has a client-server architecture, where the client sends commands to the server so that it perform specifications. In our Modbus whitelist, the entries are the commands that can be used. When using whitelisting, a common challenge is how to build th whitelist. The two preferred approach are either manually, using the knowledge of the operator or automatically by getting a representative sample of the communications occurring in the network. With both approaches, there is a risk that legitimate flows or commands are missing in the whitelists. The second level is there to cope with this problem.
To ensure a strict control on the communication and a better efficiency, our IDS requires that the whitelists are stored on the switches that are directly connected to the endhosts. It allows to share the workload across the network and security tasks are performed closer to the endhosts.
In our solution, we propose to use P4 switches. P4 is an high level language allowing to program protocol-independent packet processor. P4 programmers write programs telling switches how to parse packets and what to with them. We implemented a P4 program to process Modbus packet that runs on switches connected to endhosts. The programs implements the whitelists and is used by the switches to determine if a packet can be forwarded to the hosts or not. The packet with characteristics (flow or Modbus command) which are not part of the whitelists are redirected to the second level for further inspection. Figure 2 shows the how the rst level operates.
Second level: Security Engine
The second level is a middlebox running the network monitoring tool Bro and an interface to communicate with the SDN controller. We named it the Security Engine (SE). Upon receiving packets from the first level, the SE will inspect the packets to decide if it belongs to a malicious flow. If the flow is deemed as legitimate, it will be added to the whitelists via the SDN controller. Otherwise, every packet from that flow will have to be inspected first by the SE before being forwarded to the original destination. The SE favors detection over prevention like any IDS, so when it detects that something is shy, it will only raise an alert but when there are clear indications that an attack is occurring, it will instructs the SDN controller to block the flows.
Depending on the type of applications running in the network, the SE can be configured to either disable addition of new entries in the whitelists or add new entries only after a certain amount of unsuspicious packets have been observed for a flow. This is useful as different applications have different requirements. For example, some hosts use HTTP for configuration and it would make sense to never whitelist those flow since they do not have strict constraints on the delay, so they would not be highly impacted by the redirection to the SE.
In our work, we presented a two-level architecture, it has the advantage compared to other approach of sharing the workload across the networks. The SE only inspect traffic caused by unnatural event. The goal of this document was to give a brief overview of the work we have done and presented. For the readers interested in the experiment we have done and the results, or those who want more details.
Gorby Kabasele Ndonda is a research assistant at INGI department at the Université Catholique de Louvain (UCLouvain), Belgium.
He is currently pursuing a PhD at UCLouvain with Professor Ramin Sadre. His research topics include Software Defined-Networks (SDN) and Industrial Control System security. He has also been working on the evaluation of Network-based Intrusion Detection Systems.