The Great Divide: Why IT and OT See the World So Differently (Part 3: Programs)

Hey everyone, Joe Baxter here again. If you haven't read the previous iterations yet, I recommend catching up, because today, we're diving into another critical area where these two worlds diverge: Programs and Applications.

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

When I talk about "programs" here, I mean the software, the applications, and the underlying logic that manipulate and secure workloads and data in both IT and OT environments. And just like everything else, their design, purpose, and even their very philosophy are often worlds apart.

Access Control: Discretion vs. Mandate

In IT, a core concern is protecting information and controlling access. The concept of Discretionary Access Control (DAC), introduced way back in 1971, has functionally changed very little. IT systems control the relationship of a subject (a user or a service) to an object (a system or a resource). Even more restrictive models like Role-Based Access Control (RBAC) are essentially variations on this theme of "discretion" – giving users choice within defined boundaries.

The impact of access control issues in IT can often be absorbed. If, for instance, the email server becomes unavailable, an IT user might temporarily switch to a different task until the service returns. It’s an inconvenience, but rarely catastrophic.

In stark contrast, OT applications operate under a much stricter paradigm, often closer to a Mandatory Access Control (MAC) model, even if not explicitly named as such. If an OT resource becomes unavailable, production may immediately halt. There's no "switching to a different task" when a critical sensor stops feeding data to a controller. The system dictates access based on the asset's function, not a user's discretion.

User-Centric vs. Asset-Centric Applications

The type of software found in IT environments revolves around its focus on the user. We're talking about "userland" software: email clients, word processors, spreadsheet applications, and the vast array of Software as a Service (SaaS) tools that fill IT catalogs. These are user-centric applications and operating systems that extensively use web-based interfaces and browser applications. If IT can't find off-the-shelf software to satisfy user needs, a team of internal or external developers will be employed to create custom functionality.

OT applications, however, are fundamentally asset-centric. Their focus is squarely on controlling and monitoring the OT asset itself, usually without much regard for state-of-the-art user interface (UI) and user experience (UX) trends. You rarely see OT teams building custom software from scratch. Instead, the vendor delivers a completed system after months or even years of rigorous Factory Acceptance Testing (FAT) and Site Acceptance Testing (SAT) before it goes live during a planned production outage.

Vendor-Specific vs. Generic Business Applications

This brings us to another key difference: the OT space is filled with many vendor-specific applications. If an entity purchases a robotic system or a generating unit from Vendor X, a significant portion of the software used within that entity’s OT environment will originate directly from Vendor X. Even if a Supervisory Control and Data Acquisition (SCADA) system covers multiple assets, the hardware vendors will likely still source the PLC programming software, the relay connection software, or the MTU programming software. It's a highly specialized, often proprietary ecosystem.

In the IT market, hardware has almost become an afterthought. IT systems have been "software-centric" for many years. Case in point: Microsoft Office and Adobe Acrobat have established true market dominance and serve as the de facto business standard. These two applications run on a wide variety of hardware, from Dell, Lenovo, Sony, Apple as well as in a vast number of operating environments, such as Windows, MacOS; even on iPad and Android. So ubiquitous in fact, that a user would find it incredibly frustrating to use a platform that couldn’t at least open a PDF or DOC file. In this way, the IT world relegates the hardware to almost immaterial status, serving only to provide access to the software. On quite the other hand, in the realm of OT, the software is custom-fitted almost exclusively to the hardware.

Internet Dependencies vs. Local Applications: The Cloud Divide

Finally, two more differences come as a matched pair. In IT, many business-critical applications have moved into the Cloud, have Internet dependencies, or both. Patch management often reinforces these dependencies, as systems may refuse communications with unpatched clients.

In contrast, administrators in OT grant Internet access to few (if any) systems. They deal with patch management as a manual, highly controlled process, often aligning remediation with planned outages or maintenance cycles to minimize disruption. While IT adopts the cloud wholeheartedly, OT remains largely cloud-averse, prioritizing local control and minimizing external dependencies due to the critical nature of their operations (although this might be changing now with advanced customers). 

These profound differences in how IT and OT approach applications—from access control models to software development and cloud adoption—are not just technical nuances. They reflect the core priorities we discussed in Part 1: IT's focus on information protection and user flexibility, versus OT's unwavering commitment to availability, reliability, and human safety.

In our next post, we'll delve into how these differing approaches to programs and applications directly impact security strategies and the ongoing challenge of IT/OT convergence. Stay tuned!

Joe Baxter, Network Architect, IT & OT Battle-scarred Veteran