Even though the acronyms make IT/OT convergence sound complicated, admins must learn how to make OT and IT converge in more ways than just terminology if they don’t want to think about creating separate technology for operational missions.
Everyone knows IT stands for information technology, but many find the acronym OT difficult to understand. OT means operational technology R12; the software and networks used to directly control business and industrial processes. But individuals still don’t know why OT isn’t the same as IoT, or why it’s not just a subset of IT.
IT and OT differences inhibit integration
The biggest technical difference between IT and OT is the former focuses on transactional human-to-application interactions, and the latter focuses on event-based condition-to-process-system interactions. IT creates workflows, and OT creates control loops. IT often doesn’t focus on reducing response times to a few tens of milliseconds, because human processes typically tolerate process delays. In OT, sometimes even a 10-millisecond control loop is long.
The second issue in IT/OT convergence is the difference in security requirements. IT supports workers who apply human judgment to the actions the system takes or recommends. OT feeds control commands directly to industrial processes. Hacking them could have an immediate real-world effect. For example, think of hacking the power grid.
How to reconcile differences
There are three possible ways to address the unique requirements of OT. The first is rarely practical: Create a totally separate network for it. The second and third both accommodate OT differences using the same technology as IT networks. The second creates an OT partition, and the third prioritizes OT traffic within the IT framework. Sometimes, the two can be applied independently, but it’s best when they’re used together.
Partitioning IT/OT networks means creating a separate virtual network for each to isolate the OT traffic and manage connectivity. Admins can more easily prioritize OT traffic if it’s separated in a virtual network.
Creating a separate IP subnet for OT traffic is an obvious step. OT applications would normally deploy within an IP subnet, where each component would be given a private IP address that cannot be routed onto the internet. Selected components that require outside access can be exposed to the organization’s VPN. Today’s containers, particularly those built around Kubernetes, make this kind of structure easy to build and use.
Organizations often use private IP addresses only within IP subnets, but it’s possible to build them on a pan-application scale, moving all OT traffic to a private IP address. Only expose addresses for APIs that are referenced by applications or users or reference other APIs. This will significantly enhance OT security, even if the organization takes no other steps.
Sensors and controllers can also be protected if placed in the same address as the applications and hosts. Most of the interactions between control elements and OT applications will then take place within the private virtual network, and none of the sensor and controller addresses need to be exposed to the organization’s VPN or to the internet. In effect, this measure builds an almost-independent OT community that shares resources with IT applications, but is partitioned from those applications and their users.
The partitioning of OT networks using subnets or private IP addresses won’t make the applications invisible at the LAN level. For greater IT/OT isolation, it’s possible to actually segment the LAN to provide almost complete isolation. Virtual LAN technologies include the standard 802.11q specification and proprietary VLANs from vendors like Cisco. Recently, it’s become possible to build highly flexible VLANs of unlimited numbers and sizes using software-defined networking. The OpenFlow standard provides a means of controlling switches to create explicit VPNs. Organizations, including VMware, Juniper and Nokia, offer other methods.
VLANs are the most practical way to provide LAN partitioning of OT hosts and applications, because it can separate applications even within a data center. For the sensor and control part of an OT network, it’s sometimes easier to use a different physical LAN. Use wired Ethernet, Wi-Fi or a combination. OT sensors and controllers are usually located in limited areas, so LAN partitioning might be easier to do.
IT/OT convergence requires network separation
It may sound like an oxymoron, but partitioning is the most reliable way to converge IT and OT, where neither system is aware of the other. If it’s not possible to partition OT off from IT using common facilities, it may be necessary to wall things off using access control. As long as OT uses a separate and distinct range of addresses, admins can construct forwarding rules and access control policies that will control who or what can accesses the OT side and even give OT traffic priority at points of possible congestion.
The biggest problem with IT/OT convergence is the difficulty in recognizing how the two are different. If organizations treat OT applications just like IT applications and OT sensors and controllers just like workers, they will have to enforce common practices for the two. Doing otherwise would require constant changes to policies and access control tables.
On the other hand, if all OT addresses fall into a specific range, even if the range is an open part of the VPN, admins can build policies to prioritize traffic and prevent unauthorized access simply by examining the address ranges themselves.
Organizations don’t want to waste money. If admins have solid reasons to integrate IT and OT, they should try not to outrun the advantages these reasons create with the cost of integration methods. If the organization has no real reason to integrate currently separate networks, then they should wait until there is a reason and clear requirements to guide the process.