Introduction
Industrial systems are a category of information systems of their own, with codes and properties that differ from “classic” IT systems. It is well known that the level of maturity of the industrial sector in terms of cybersecurity is generally lagging in comparison with what is done in IT systems. This delay can be explained by several factors, one of which being the historical legacy of industrial systems that sometimes are in place since several decades. This article will focus on one of these historical aspects which can be found in many industrial networks today: which are known as ‘PLC’ or ‘field’ networks. We will first look at the history that led to the existence of these networks, then examine the strengths and weaknesses of the model with respect to current and future cybersecurity needs, to answer the following question: Are field networks adapted to new cyber security needs?
History
Let’s go back in time: we are not going to talk about the different industrial revolutions, but our story begins at the start of the 70s. At the time, there was no Ethernet network, OSI model or even IT. Industrial production systems relied on physical mechanisms using pneumatic or electrical signals. The 1970s saw the arrival of the first principles of automation, and the integration of the first intelligent equipment: the programmable logic controllers (PLC). This equipment allows resources to be pooled, as a PLC can manage several electrical inputs and outputs, and therefore centralise the management of processes. PLCs also incorporates communications modules, and this led to the appearance of the firsts bus networks in industrial systems, using serial communications protocols.
This architecture model will continue to develop in the 80s with the increase of industrial protocols, based on the “Controller-Workers” model: A main PLC contains the centralised database and plays the role of an orchestrator by being linked to the “Workers”, corresponding to other PLCs, remote input/output cards, etc… This architecture simplifies process programming at a single point, as well as communication with supervisory devices such as the man-machine interface or proprietary SCADA.
The 1990s brought the democratisation of the TCP/IP model and the integration of ‘traditional’ IT into industrial environments: no more need for proprietary equipment, SCADA software can now be installed on conventional systems… but these computers still need to be able to communicate with the PLCs! Serial network cards exist, but industrial protocols are beginning to adapt to operate on a conventional Ethernet network. Master controllers are gradually being replaced to enable them to use TCP/IP protocols on the main network, while continuing to have serial network cards for field equipment. Then it was the turn of field equipment to adapt to the standardisation of TCP/IP use everywhere, so that today the use of serial communications is minimal. Even electrical inputs/outputs are now tending to be replaced by IP links on sensors and actuators, via the use of “Single Pair Ethernet” connectors, for example, which provide a low-cost and space-saving connection.
Evolution of field architectures
As a result, the following architecture is now commonplace: A “main” industrial physical network (in star or ring topology) containing all the supervision and external communications equipment (SCADA, Data Historian, operator station, etc.) as well as the PLC controllers, each of which has a second network port. This second network port makes it possible to create an isolated sub-network on each PLC on which the equipment closest to the physical process is located. The PLC controller then acts as a “functional pivot”, exchanging data with the SCADA system on the one hand, and with field equipment via the PLC’s data registers on the other. This architecture can be adapted in several ways, for example, by replacing the pivot PLC with a server, or by combining several layers of isolated networks with a SCADA server having two network ports, separating the main industrial network and the supervision network in which the controller PLCs are found, on which a new separation is made with field networks.
Example of industrial architecture integrating field networks
Now that we’ve looked at the past, let’s talk about the present, and in particular the three evolutions that are leading us to question the relevance of this architectural model today:
- Industry 4.0, which has changed the face of industrial networks, moving from an isolated model to an ultra-connected model to meet the challenges of Big Data, interconnection with the Cloud, the digital twin, etc…
- The standardisation of industrial technologies, enabling us to move away from industrial suppliers, via the development of “Soft PLCs” on Linux or onboard Windows, or the use of standardised industrial protocols such as OPC-UA.
- The introduction of cybersecurity solutions at the core of the industrial network, such as update servers, firewalls, antivirus and even EDR or network probes, whose presence makes sense with the modernisation of IT infrastructures and the development of cybersecurity in the industrial environment.
To study the relevance of field networks in the light of these new challenges, we are going to look at four operational security issues: network security, remote access, update management, and detection and mapping.
Network security
The first question to ask is simple: What are the advantages of field networks from a cyber security point of view? This advantage is reflected in the very principle of the architecture model: the use of pivot equipment provides physical isolation between an industrial network and a field network. In principle, therefore, it is not possible for the two networks to communicate directly, as information is transmitted via a database (registers for PLCs, OPC database for a server, etc.). There is no need for a firewall or diode: no flow can go from one network to another, which is the best way of protecting against propagation to field equipment.
But is this separation, made using a physical equipment not dedicated to the network, foolproof? On equipment operating on a ‘classic’ Windows or standard Linux system, the answer is no. There are many examples of attacks that convert these systems into pivots, exploiting the many possibilities offered: exploitation of remote access protocols such as RDP, VNC or SSH, RAT, C2C implants, etc. As a result, a separation with this type of system will slow down an attacker but does not significantly reduce the possibilities of reaching field networks that would exist on other network cards.
In the case of a “classic” PLC, this is usually a piece of equipment running on a proprietary operating system that offers few functions: at the very least it can run industrial programs and communicate with one or more industrial protocols and can optionally contain more traditional HTTP or FTP type servers. The equipment therefore offers far fewer functions than a computer or server and is not designed to provide gateways between its various network cards… or so we tend to think. However, it has been shown that it is possible to create gateways between the various network ports of a PLC: via research work such as that by Nicolas Delhaye and Flavian Dola presented at GreHack 2020 (the video here), but more concretely via the Pipedream malware discovered in 2022. This malware enables network routes to be created on Schneider PLCs, transforming them into proxies and giving them the ability to route any protocol to field networks.
Illustration of how the Pipedream module targeting Schneider equipment works.
We have therefore proved that, even in the case of separation by a PLC, the model is not infallible, but it still makes it possible to greatly reduce the risks by only exposing the field networks to very advanced attacks.
Mapping and supervision
Following the previous paragraph, a question naturally comes up: how do you supervise a network whose strong point is its isolation? Firstly, about logging, the current observation is that PLCs and industrial equipment are still very rarely included in security supervision perimeters: for technical reasons, as not all equipment is necessarily capable of sending back syslog-type logs, but also for organisational reasons, as SOC teams still lack the maturity to make proper use of event logs from this type of industrial equipment.
To overcome this lack of visibility, industrial environments are becoming increasingly subject to the installation of a network probe, enabling supervision and mapping requirements to be met. In particular, systems falling within the scope of the French Military Programming Laware required to install an ANSSI-qualified detection probe. Technically, it is possible to make isolated networks communicate with a probe by using network TAPs, whose function is to passively copy network traffic so that it can be listened in on. Strategically, field networks are rarely the place to monitor the network side. Priority should be given to interconnection points with other networks (company, supplier, etc.) or critical control equipment such as SCADA.
Example of a supervision architecture integrating field networks
However, the TAPs solution is not applicable to “active” probes, which seek to map by questioning the various devices on the network. But this type of solution is rarely implemented in an industrial context, to avoid ‘stressing’ the network and the equipment.
The field network model therefore remains compatible by focusing on network supervision with the installation of probes for detection, as well as passive mapping. The feedback of system logs from PLCs and industrial equipment is still not sufficiently relevant to the analysis capabilities of SOCs.
Update
To be able to make updates, it is necessary to have a network interconnection with a system allowing these updates to be sent to endpoints, which is opposed to the isolation of field networks. Does the need for updates in an industrial environment make the field network model obsolete?
Maintaining security is a complex issue when it comes to industrial systems: the high level of availability prevents any major intervention, systems that are isolated from the Internet mean that updates cannot be downloaded over the network, etc. In the case of networks made up mainly of PLCs, update mechanisms have evolved to take account of these constraints, with the result that today the number of PLCs kept up to date is very small (even on an annual basis), and these updates are mainly deployed manually by maintenance staff. The use of field networks to partition the architecture does not prevent these same mechanisms from being applied to PLCs.
On the other hand, the integration of IT technologies is changing the rules: one of the first security solutions recommended for a Windows installation is to set up a WSUS server to centralise the deployment of updates, and the same principle is also applicable to Linux technologies. This brings us to a new constraint for field networks with equipment such as Soft-PLCs or dedicated operator PCs: partitioning by dual network cards prevents centralised management of updates, forcing the implementation of a manual patching process that can be complex and time-consuming for many devices.
However, this constraint must be evaluated in relation to the need. The main argument in favour of updates is that they enable vulnerabilities to be corrected that increase the attack surface of an equipment. As the field network model strongly isolates systems, their attack surface is already greatly reduced. It is therefore acceptable for systems not to be constantly updated, and in this case a manual annual update of the equipment meets the need.
However, this model is not suited to the need for antivirus software to be constantly updated to guarantee optimum protection. This is why it is necessary in this case to rely on systems that move very little over time, which makes it easier to use whitelisted application filtering solutions such as AppLocker or WDAC (see our article on application filtering).
Finally, updating practices in industrial environments have adapted to the very principle of network isolation, enabling these needs to be reduced. These practices do, however, require equipment to be hardened when installed, and solutions to be put in place to maintain system security levels with a minimum of maintenance.
Remote access
Having looked at “automated” update flows, what about flows initiated by a user to access remote equipment for business or maintenance operations? For PLCs, such access is rare: they do not need human intervention to perform their tasks, and in the case of internal maintenance, this is often carried out by accessing the PLC from the network on which it is located (dedicated administration networks for PLCs are still very rare). If the PLC is accessible from the main production network, maintenance can be centralised from a single connection point. On the other hand, since field networks are isolated from the production network, the PLCs located there can be accessed by connecting the maintenance laptop to the ‘right’ switch, interconnecting the various items of equipment on the sub-network, or even directly to the PLC’s USB port with a serial link.
On the other hand, there are limits when it comes to field networks with equipment maintained by a supplier or maintenance service provider. This is because remote maintenance has become the preferred method, and it is quite rare these days to have third-party maintenance staff available to physically visit the site at any time. The most common solution to this problem is to install a VPN termination directly on a field network, with a tunnel connected to the service provider. This effectively addresses the problem, but also bypasses the whole principle of isolating field networks, which are then exposed in the event of the service provider being compromised.
This is where we reach the biggest limitation of the field network model, reinforced by the trend towards centralising remote access and installing bastion-type solutions that cannot cover access to field networks due to their isolation.
Conclusion
The existence of field networks is mainly historical, due to the old controller/worker architecture models and the gradual introduction of the TCP/IP model in industrial networks. These architectural models have adapted to the life cycle of systems: they are accessed very little by users and are designed to operate autonomously by sending data back to the controller.
Partitioning is the main strength of field networks: transforming a PLC in a rebound equipment to two different network interfaces is a highly advanced attack technique. To detect possible attacks, solutions exist for setting up supervision on isolated networks, in particular with TAPs.
The other advantage of network isolation is that it reduces the effort required to maintain security. The need to update isolated equipment is not necessarily the same as for equipment used by humans and interacting with third-party networks. Since isolated equipment has a lifecycle with few changes, the focus should be on hardening when it is brought into service.
However, the isolation of these networks poses several problems in terms of remote access: it is possible to limit this when the industrial estate is managed internally, but it is essential when a service provider needs to intervene remotely. To avoid local initiatives or third-party solutions, it is advisable to implement a controlled remote access solution (VPN, bastion, etc.), with the accessed equipment placed on a dedicated sub-network with a filtered and controlled entry point.
In conclusion, the field network model is still relevant today. However, recent trends, particularly those linked to Industry 4.0, will raise new issues: the emergence of Industrial IOTs, involving the implementation of IoT network buses interconnected with the outside world, calls into question the relevance of having isolated IP networks cohabiting with more exposed IoT buses.
Source
Dragos Analyzing PIPEDREAM: Results from Runtime Testing
https://www.dragos.com/blog/analyzing-pipedream-results-from-runtime-testing/
GreHack 2020: A full chained exploit from IT network to PLC’s unconstrained code execution
https://www.youtube.com/watch?v=PfdoaxYkmUE
