Just as other hardware continues to evolve into software and cloud-computing services, many OT cybersecurity functions are making that transition—and gaining automation along the way.
“Software-defined networking (SDN) is going to change how OT networking and cybersecurity is done,” says Jeff Smith, CTO at Dynics Inc., which develops software and security platforms, such as ICS360.Defender. He’s also acting CTO at Veracity Industrial Networks, which makes an OT SDN controller. “Organizations can add all the cybersecurity monitoring and management tools they want, but the operations guy doing multiple jobs in multiple disciplines doesn’t have time to monitor or respond 24/7 to cybersecurity issues. Plus, if they don’t use these tools every day, some may forget and risk failing to respond to an event. This is why many users are looking at running SDN in the OT space and integrating it from the plant-floor up.”
Origins in OT
Smith reports that companies such as Belden tried to deploy an SDN solution in the OT space a few years ago, but there were too many gaps in traditional SDN networking technology that led to too much complexity and gaps in capability suitable for the OT space.
“Now, we’re trying to bridge those gaps and give users visibility into and control of their OT networks, and the traditional IT approach to SDN typically doesn’t fit the OT space,” says Smith. “Meanwhile, many of today’s monitoring and detection software sniffs and pokes but doesn’t step as lightly as it should. It may be OK not to get a Word document in 500 milliseconds, but it’s likely not OK if a PLC can’t reach its I/O for 500 milliseconds because of slow network or device response times."
Microsegment for earlier alerts
Smith adds that securely connecting an OT network to an enterprise or traditional network can be fraught with security concerns that many traditional approaches to segmentation don’t address. SDN microsegments the network.
“Using traditional IT tools or many OT monitoring solutions such as Claroty or Nozomi’s SCADAguardian allow OT asset managers and network managers visibility into the OT network, but that’s only half the equation,” he says. “That approach provides visibility without control. There’s value in what products such as Claroty and SCADAguardian provide, but users must wait until the software detects devices and anomalies and tickets come in. Plant-floor guys can’t wait around for these alerts, and they may not be able the address them for hours anyway.”
This is where SDN can help because it behaves as though there is firewall on every port of every switch. This lets SDN establish device-to-device data flows by protocol, which provides secure traffic between devices. For example, known traffic is handled between the switches, and unknown traffic is blocked, while undesired traffic can be preemptively discarded at the switch. User-defined policies in the SDN controller dictate how the switches are configured on the fly. There’s no need for a switch to ask the SDN controller how to handle a particular traffic type between devices once the controller has directed the switches how to handle that traffic.
SDN controls traffic between devices per protocol, so while an I/O module might be able to respond to CIP connections from a PLC, it can’t necessarily respond to CIP or any other protocol from another device on the network. SDN in the OT space allows a vendor-neutral approach to device and protocol-level security. A simple policy can be created such as “allow all PLCs to talk to all I/O modules over EtherNet/IP” or it can be controlled between specific device types.
Instructing the switches
Smith explains that SDN-capable switches employ an agent that supports OpenFlow, an industry standard SDN management protocol. The agent replaces the switch’s control plane, which is generally unique from vendor to vendor and often switch-family to switch-family. The control plane is where the switch is configured, either via CLI or via a web-Interface.
“If a switch supports OpenFlow, the control plane becomes nothing more than an agent that interfaces with the SDN controller. The agent, at the direction of the controller, determines how the switch will behave and what it will do,” says Smith. “Because SDN is deny-by-default, it prevents communication until it’s allowed. By regulating these flows between devices, it controls communications point by point, and micro-segments the network, far exceeding the granularity and security offered by traditional concepts such as VLANs. This network is controlled by an SDN controller that uses Dykstra algorithms to calculate the fastest path between two endpoints. This allows automatic redundancy and recalculation of flows, lays in flows automatically, and provides nearly real-time network status at the controller, so users don’t need to monitor the protocol and network operations.”
SDN controls the network
Smith states that SDN isn’t an application that runs on the network—it is the network, so it can control east-to-west connections across switches unlike purely monitoring solutions or most other OT cybersecurity solutions. All this happens at Layer 2, so SDN can work with any industrial protocol such as EtherNet/IP and Profinet. “Users don’t need to use VLANs or enable spanning tree protocols such as RSTP, MSTP, or PVST+, and it’s 100% secure out of the box,” says Smith. “SDN has been used in the enterprise and cloud for years, but Veracity Industrial Networks is the first to apply it to the OT space. SDN is standard IEEE Ethernet; the only difference is how the network is managed. Any application that runs on an IEEE ethernet network today, will run on an SDN managed network”
To implement SDN, Smith begins by asking users how much cybersecurity is enough for them and their operations, and how much downtime they can tolerate. “You need to mitigate the risk you’re not willing to live with, and then look for solutions,” says Smith. “IT usually wants to allow most communications and block what’s suspected of being bad, while OT usually wants to block everything and only allow what’s known to be good.”
Smith concludes that SDN eliminates complexity, and translates policies into actions. “For example, users don’t have to manually update large numbers of managed switches or be concerned with fat-fingered or manual-entry errors because the SDN controller dishes out policy changes to the switches and can change the security posture of the network broadly as opposed to manual entry across large numbers of switches,” adds Smith. “This can be a big help for operators because it simplifies design, deployment and management of their OT networks.”
