When the developers of Modbus began enabling communications from heterogeneous devices leveraging the RS-485 standard in 1979, it was off to the races for fieldbus communications interoperability. RS-485 defined the electrical characteristics of drivers and receivers used in serial communications systems to connect a wide range of controllers, sensors, instrumentation, PID controllers, motor drives, and more. DeviceNet, Profibus, SERCOS, ASi, Foundation Fieldbus, and HART followed suit – all of which remain unencrypted.
OPC UA (IEC 62541), a unifying technology that bridges industrial automation and modern computing technologies, serves as the background for the interoperability spawned by vendors and suppliers, industrial and enterprise software, and yes cloud service technologies. OPC UA standards allow sensors to communicate from many types of controllers and devices for the purpose of coordinating sensor data within a historian. This functionality allows enterprise layers to correlate process data with business functions without redundant software for translation and normalization of protocols communicate to and from disparate systems. But how can all of this connectivity and data be networked and managed?
From Hubs to Switches to Modern Networking
Before network switches, hubs were the main way to interconnect Ethernet based networks. A hub is a quite simple device which physically copies each packet from its source port to each destination port connected to a single hub in a multicast manner. While cheap and simple, this technology does not scale well because even a small network with low number of clients has many packets transferring between computers, causing too much traffic and potential spamming and jamming on the hub. For example, if a client behind port 1 was exchanging packets with a client behind port 10, in principle only these two ports should have seen those packets.
The solution for this predicament was the introduction of Ethernet switches. A switch is more sophisticated than a hub, as its hardware has the capability to better understand and route packets on a local network. In fact, it is able to read the Ethernet layer (the first 14 bytes, 6x2 for the MAC addresses and 2 for the EtherType, stating the protocol of the next layer e.g. IP), and some upper layers like ARP, and understand which MAC addresses are connected to each single port. With that, it builds what is called an ARP table and uses that to forward packets only to the right port(s), similar to the old switch board used for telephone communications.
Broadcast packets, sent to all clients on a network, still require forwarding to all ports, but the switch remains a huge improvement compared to the ‘all-speak-to-all’ situation that is a reality with early hub technology. Modern network switches have adopted increased capabilities to deal with complex network design complexities like VLANs and QoS, and can even do router-like jobs if defined as “Layer3 switches” where packets are routed to their default mac address gateways. Layer 3 switches Support Virtual Router Redundancy Protocol (VRRP) and Open Shortest Path First (OSPF). VRRP provides automatic assignment. When a master router fails to connect, the backup router is automatically switched to the new master router. OSPF is often used in large network-like substations; it can calculate the shortest route for data transmission and make the process more efficient.
All of the functionality above is designed to work at high speeds: originally at 10 Mbits, then grew to 100, 1000, etc. Today, certain switches are able to operate at tens of Gbits. To achieve that, an ASIC (Application Specific Integrated Circuit) is usually employed. This hardware circuit is dedicated solely to the purposes of a switch, and while less flexible (it cannot be reprogrammed or used as a generic processing unit), it is able to transmit data at wire-speed where full gigabit traffic can be transmitted without packet loss and collision. Another CPU (Central Processing Unit) remains to orchestrate other functions, configuration, setup, etc.
SPAN Ports Enter the Chat
SPAN (Switched Port Analyzer) ports, also known as mirror ports, were originally introduced by Cisco to allow network engineers to troubleshoot network issues around switches. With hub technology, it was quite easy to understand what was going on in a network – all you needed to do was connect to a free port and all packets flowing in that network were visible for inspection. But with switches, that is no longer possible. A SPAN port is basically a configuration of one (or more) ports so that they can receive a copy of the traffic transferred on the switch (or in a specific VLAN, or a set of ports - nowadays configurations are certainly more complex that in the beginning).
The beauty of SPAN port technology is that this capability is included in the ASIC unit discussed above, therefore, it does not affect network performance by eating into other tasks and services. For example, SPAN configurations will not cause the switch to drop packets on the other ports or introduce latency. There are no major concerns about performance when it comes to setting up SPAN ports. Of course, certain limitations can apply - and some older models may omit some packets to the SPAN port under certain situations, but the main and core functionalities of the switch won’t introduce delays in its wire-speed.
Enabling Monitoring for OT/ICS Networks
When Nozomi Networks founded one of the earliest companies dedicated to industrial cybersecurity network monitoring, an early milestone was to produce a third-party certified review of SPAN port technology. The report confirmed that no impact on performance is observed when SPAN or mirror ports are used. In that test, different kind of switches of different brands and price were tested, to show customers that it was not essential to upgrade to the latest and greatest brand and model to enable network monitoring capabilities to introduce cybersecurity tools and controls.
Industrial control systems (ICS) environments, comprised largely of heterogeneous components with custom operating systems and network protocols, historically have fewer cybersecurity tools designed to interrogate customized protocols and behaviors. This is especially true for areas of cyber-physical systems architecture closest to field and input/output (I/O) devices. Customized sensors, installed at a SPAN or TAP port within the customer networks, passively monitor raw network data in real time, without disrupting business operations, providing real-time visibility into all network activity to alert on vulnerabilities, potential attacks in progress, and emerging anomalies.
Modern networking, SPAN port evolution, and protocol interoperability paved the way for operational technology (OT) and ICS network monitoring and cybersecurity. Today, these solutions have expanded their software capabilities to interrogate the analyzed traffic, to include complete database matching of known vulnerabilities and indicators of compromise, deep packet inspection to analyze packet traffic, commands and connectivity, threat intelligence feeds, and machine learning engines to define baseline network traffic and alert on anomalies in communications and process variables. These third-party security offerings offer holistic security awareness where vendor-specific options cannot cover heterogeneous systems across an environment.
