The Great Divide: Protocols and “Can You Hear Me Now?”

Welcome back, fellow travelers on the digital frontier. Joe Baxter here, and today we're diving into the final difference between IT and OT worlds: Protocols. Before we begin, in case you have missed any of the previous installments, here are quick links:

1. Priorities … Here
2. Personnel … Here
3. Programs … Here
4. Processing … Here
5. Parameters … Here
6. Privileges … Here
7. Placement … Here
8. Protocols … You are Here

IT protocols talk the talk, but OT protocols make the plant walk

The divide between Information Technology (IT) and Operational Technology (OT) is not just a matter of people or purpose; it's deeply rooted in the very language their systems speak: protocols. While both worlds rely on networks to communicate, the fundamental differences in their protocols create a chasm that modern cybersecurity solutions often fail to bridge. Understanding this gap is crucial to securing the critical infrastructure that powers our world and keeping it operational.

The Standardized World of IT

The IT landscape is a world of standardization. The gold standard for data transmission is the Transmission Control Protocol/Internet Protocol (TCP/IP) suite, specifically version 4 (IPv4). This suite has replaced older, now-obsolete protocols like NetBEUI and IPX/SPX, bringing a level of uniformity that makes network management and security relatively straightforward. Some IT systems have even begun to adopt IPv6, further solidifying the trend towards standardized, well-documented communication methods.

This standardization means that IT security tools are designed to work within a predictable framework. They rely on the clear addressing and routing capabilities of TCP/IP to perform tasks like vulnerability scanning and asset inventory.

The Wild West of OT

In stark contrast, the OT environment is a patchwork of old and new. While some OT devices use standard IPv4 protocols, a significant portion still relies on a long list of custom and proprietary protocols. This isn't just a matter of legacy systems; many of these protocols were designed decades ago for performance and reliability, often operating in cleartext with little to no concern for cybersecurity.

This lack of standardization presents a massive challenge for IT-centric security solutions. Many OT devices still use unbuffered and unprotected ports, making them vulnerable to unexpected reactions from standard IT tools. A simple ping sweep, a routine part of an IT network scan, could trigger a device to crash or fail over, potentially causing a costly and hazardous disruption to operations. The risk of disrupting a critical process often outweighs the perceived benefit of a security scan, leading to a "hands-off" approach that leaves OT networks exposed.

The Routing Conundrum

Another key difference lies in how these systems address and route data. TCP/IP is inherently routable; it uses a host address and subnet bit length to determine whether a packet can be sent to a local device or must be forwarded to a gateway. This allows IT networks to scale and connect across different locations and subnets.

Many OT protocols, however, are non-routable by design. They may have a host address but lack a network address or gateway, meaning they cannot be forwarded outside their local network segment. This makes them invisible to standard IT tools that rely on routable protocols to map and manage the network. It's like trying to navigate a foreign city without a map—you can see the buildings, but you have no idea how to get from one to the other.

The MTU and Serial Legacy

The differences extend to technical details like the Maximum Transmission Unit (MTU) size. While IT networks have long since upgraded to accommodate larger MTU sizes for things like modern encryption, older OT equipment may still be stuck with smaller limits. This can cause significant problems when trying to integrate new technologies or implement security measures that add overhead to data packets. 

I well remember the day that we began to implement 3DES on bank routers to keep in step with FDIC mandates. One by one, each of the bank’s branches dropped off the WAN while we looked on in confusion. The MTU size, set years earlier, could only handle the relatively small overhead created by the DES encryption. And since the DF (don’t fragment) flag had been universally set, nothing got through. That turned into a very long night, but we were ready when the first tellers showed up the next morning.

Finally, while IT has almost entirely moved away from older technologies like serial communications (RS-485 and RS-232) in favor of TCP/IP, OT continues to use them widely. The last IT asset I touched that used RS-485 was a modem-connected Kronos time clock that reported back into a DOS server once each week. And by touch, I mean soldiering on a DB-9 connector and setting the AA (auto-answer) Hayes codes on the modem. On the other hand, OT device manufacturers still have new RS-485 devices on their roadmap! This includes not just serial but also other legacy media like coax and microwave transmission. This reliance on outdated technologies creates yet another blind spot for standard IT security solutions, which are simply not built to handle these communication methods.

Bridging the Gap

The protocol divide between IT and OT is a major reason why traditional cybersecurity approaches fail to secure critical infrastructure. The proprietary, non-routable, and often cleartext nature of OT protocols requires a new approach—one that is built from the ground up to understand and interact with the unique language of industrial control systems without disrupting their delicate operations. Only by bridging this protocol gap can we truly hope to secure the OT environment.

Crossing the Chasm: Bridging The Great Divide

I’ve been in this game for a long time, back when "OT" was just part of the factory floor and "IT" was the folks in the server room. The lines are blurring now, and honestly, that's both the biggest challenge and the most significant opportunity we've ever faced.

My journey has taught me one thing: the tech is only half the battle. The real work is in understanding the processes, the people, and the mission behind the machines. I've seen countless brilliant systems fail because they didn't account for how the plant actually operates, or because the teams couldn't find a way to communicate with each other.

The key to success isn't just knowing your code or your control systems; it's about building bridges. It's about getting out of your silo and walking the factory floor. It's about listening to the production manager just as closely as you listen to the network admin.

Let's not lose sight of that. The integration of IT and OT isn't just a technical problem—it's a human one.

Keep on building those bridges.

Best,

Joe Baxter

‍