This is the first part in our “Real-World Lessons from the Field” blog series – the series will focus on interesting lessons learned from actual case studies taken from Claroty installations. With extreme visibility, Claroty not only provides real-time security monitoring and anomaly detection, it helps customers understand the intricate details of how their Industrial Control Systems (ICS) networks are configured and operating. Each blog in this series will cover either a security or operational risk – risks that are often caused by configuration errors and exacerbated by the lack of common understanding and shared knowledge between the “shop floor” and IT Security teams. We have chosen case studies which we have repeatedly encountered and that in our opinion represent common weaknesses in many Operational Technology (OT)/ICS networks.
In this blog we discuss the cybersecurity risks introduced by nested devices.
What are Nested Devices?
In a standard Ethernet IT network, each node is assigned an IP address. In the OT network world, however, there is a common practice of Programmable Logic Controllers (PLCs) that function also as a gateway to other nodes (remote I\O or other PLCs) that are nested behind it. A nested node doesn’t have a distinct IP address so the intercommunication between its network card and the higher nodes (Engineering Workstation/EWS or Human Machine Interface/HMI) takes place through an additional network card that resides in the nesting PLC chassis.
Figure 1 (above) shows the standard communication between an EWS and a PLC. The PLC in the figure has only one network card in its chassis, with the IP address of 10.0.0.2.
Now let’s examine a nested device communication:
We can see that PLC 10.0.0.2 has an additional network card in its chassis. When the EWS needs to communicate with the nested PLC it again addressed 10.0.0.2 and the PLC logic redirects it to the additional card which communicates with the card in the nested PLC.
Nested Devices Communication – Security Caution
The intuitive assumption is that nested communication should not introduce new security challenges. A nested device merely extends a certain traffic vector, but does not change its initial direction, so if the EWS\HMI -> PLC traffic is well segmented, so is the EWS\HMI -> nested-device traffic.
Figure 3 illustrates a seemingly secure OT network. This network is isolated from the enterprise network with a firewall. In this simplified illustration, all traffic that involves 10.0.0.2 is allowed only with the firewalled network segment. Even though the nested PLC is not explicitly included in the policy configuration, it doesn’t seem to matter much since the traffic it generates would be introduced as a 10.0.0.2 traffic.
However, this assumption is voided when we notice that the nested device might contain several network cards in its chassis. One of these cards is used to communicate with the OT network EWS\HMI, but the others might feature additional connections.
Figure 4 illustrates the security gap that can occur from a nested device that features two independent and parallel connections. Apparently, this nested device contained another network card with and explicit IP assigned to it that communicates directly with a DMZ node. The most common of such simultaneous connections is the automation system OEM that needs a direct connection to push updates, gather metrics, etc. In this case, the network card will typically feature an explicit outbound facing IP to which the OEM logs.
We can see that the nested PLC in this example interfaces with a network segment that the firewall excludes from an OT node. The segmentation policy is thus violated, or more accurately, is never fully enforced, without the security team ever having knowledge.
Moreover, not only does the nested device interface with a non-OT network segment, the node it interfaces with directly interfaces the internet, making it low hanging fruit for threat actors.
The lack of a built-in authentication mechanism, in most to all OT protocols, means that attackers that have gained a foothold in this segment can easily discover the device’s IP, log in to it and leverage it as a bridgehead to compromise further nodes in the OT network.
All this would take place without the network security team ever suspecting. In fact, this team would likely be convinced that the OT network is well segmented both internally and from the IT network – after all they have took great care to identify and define access policies to all the internode communication within the OT network.
The security team would never assume that nested devices might feature an outbound facing IP address. In fact, they probably don’t know that nested devices even exist as independent network entities. The OT team, on the other hand, knows very well both what nested devices are and that these devices are routinely accessed by their OEM, but it never occurs to them that there is any security risk involved so these devices are never mentioned in the discussions with the network security team.
Non-monitored nested devices’ connections pose a high potential risk to your network, enabling attackers to compromise critical OT nodes from non-OT network segments, or even directly from the Internet. Network security teams are likely unaware of nested devices’ multi network-card architecture and would unknowingly allow external connections to exist even within a thoroughly-segmented network.
The Claroty platform’s proprietary DPI approach monitors all traffic and automatically maps network connections within the OT network, including nested devices’ parallel connections.
Claroty provides end to end visibility, bringing all network data to the surface and enabling OT and security teams to communicate and leverage their combined knowledge to maintain OT networks’ safety and reliability.