A lot of time is invested into defining and describing OT Security or Operational Technology Security, especially in contrast to IT Security. It’s very often hard to draw a proper line between both and complicated to keep it strict. Here is a little insight into why the line helps, where it makes things worse and a few recommendations on dealing with the resulting challenges.

What is Operational Technology?

No, I won’t even try to write a definition, so here a few examples (my perspective):

Machines in production plants mixing or packing stuff
Robots moving stuff
Robots welding things together
Powerplants, or rather the generator, furnace and everything around them
Railway-systems and their components
Drawbridges

Typical Parameters

Loooong lifespan 10, 15, 20, 30 years or even longer
Expensive, talking millions for a single system
Old”, symptom of the lifespan
Static, often designed as a one-shot product, maintenance as in updates where never considered during system design

Challenges

All the aforementioned parameters
Patching prohibited: manufacturer support is voided after changes
High availability without sufficient redundancy: No potential for regular downtimes for software/firmware updates
“Never touch a running system”: both mentality and necessity for notably old systems
Realtime requirements
Safety relevant: High chance of life being at risk, when something goes wrong

Breaking the Model

So, trains or locomotives are often considered as being OT. The question in return is, aren’t cars OT, too? Buses maybe? Planes? OT is often used as a catch-all or catch-rest pool, summarizing everything that has a physical part to it and isn’t typical IT. Then come the fun topics. When looking into SCADA Systems, the hardware part is OT Security and Embedded Security. When looking at similar components in a classic computer, i.e., the mainboard, it would be considered IT-Security or Embedded Security.
A black / white definition is simply impossible.

Disciplines or Categories?

When talking about distinguishing OT Security from something else, one always has to keep the overall topic in mind: In disciplines automotive security will probably be it’s own discipline, as the automotive security community has grown over the last few years. The same applies to SCADA and ICS, which often are the heart and brains of OT systems. Then comes “OT Security” for the rest, that doesn’t have communities, yet.
When talking policies, standards and guidelines, proper attribution becomes more important, as it’s used as one of the main factors to decide which processes and measures apply. Here being IT or being OT can have both significant pros and cons.

Systems Classified as IT

Systems falling under IT are usually controlled pretty strictly, or at least they have the potential to do so. There are regular OS updates, which can be installed, the software on top should also be maintained and there are solutions for centralized management. So, in theory, installing critical updates within 24h ought to be possible. Even though it might be a night shift for testing. In addition, redundancy makes quick reactions even easier.

Coming from here, running an IT system can be exhausting and stressful! Or otherwise said, expensive concerning time and people. Wouldn’t it be great to just classify regular and spontaneous patching impossible? Especially if you can do it in an understandable and technically valid manner?

Systems Classified as OT

Let’s talk blast furnaces, smelting ore into metal. Depending on which site on the net you read, it can take about a month to shut down and then days to restart it, if a restart is even possible. In some the metal seemingly just hardens and then that’s it. This obviously is a very extreme example, just as wanting to patch a car at a random moment, no matter whether it’s currently driving or not. But even patching a building automation system can be a tough call when the lights in rooms without daylight rely on it. This brings us to safety and potentially certification which might have to be performed prior to changing anything on certain systems.
The point being, patching an OT system requires a notable amount of preparation, some of it resulting from processes, some from legal requirements. –> The understandable and technically valid reasons that probably made most readers smile before.
Hypothetically, when having lazy admins, classifying a system as being OT and thus “not spontaneously patchable” can be a very chilled choice.
In return, specifically classifying systems as IT creates a certain amount of, partially necessary, pressure.

Two too Simple Definitions

“OT is just old IT”: While this certainly applies to a lot of management systems, peripherals and HMIs (Human-Machine-Interface), which often just run a piece of software on a Windows box, the insides are by far different. They partially contain highly specialized hardware and software/firmware which isn’t really used anywhere else. Even when generally using the phrase to describe OT, it doesn’t shed any light on the underlying complexity of things, which does exist. Still (bouncing back and forth here) it’s a perfect description for a lot of components on the borders of OT systems! “The driver only runs on XP” shouldn’t be the reason enforcing the use of an EOL component in a multi-million Euro system.

“Cyber Physical Systems” or “IT and Physics”: While the first feels a bit (very) buzzwordy to me, the second sounds a bit too simple. Yes, one side is IT, yes, the other side is an actual physical process, but there is a lot in between. Also, a lot of IoT devices have physical processes on the other side (smart washing machines, ovens, kettles), are they also OT?

Do we need a Definition?

A rough guide is critical when talking policies and rules, so that operators can work out which ones they have to apply to their systems. This also prevents conflicts, when something does go wrong, and everybody wastes time discussing whether to act at all instead of either fixing the actual issue or implementing temporary measures to compensate for the issue.

Is OT just a Bunch of Exceptions from IT Perspective?

Maybe? When deciding whether to fix or replace a system or accept limitations, cost usually is the deciding factor. In addition to cost, many companies have learned to also calculate with risk. So simply treating an old OT system like a modern IT system, and creating a risk acceptance for every single challenge, might result in a clear motivation to exchange even expensive systems. In return, when the accumulated risk from all these exceptions currently isn’t significant enough, it doesn’t make any sense to complain. The numbers would then probably confirm that plain segmentation to protect the system from everything else and everything else from the system can be sufficient.
That said: Replacing to reduce risk isn’t as trivial as it sounds, as the companies building the systems and machines are just at the beginning of introducing security to their products. Even if a customer orders security, well, if the company has never designed a secure system before, the first few tries will fail until they’ve learned about all the pitfalls.

The Personal Factor

Everybody has their own approach of doing things, their own experiences and their own pains. When IT people swoop in, they tend to just apply their ways to the existing systems and often forget the processes behind them. To many this feels like a bunch of disrespect. In return next to everybody bringing their skills and knowledge into a new environment, with the task of applying them, tends to seem pretty hot headed. Explicitly drawing a line between IT and OT, and also treating IT systems connected to OT as OT simply slows down both sides a little, defines competence and makes sure it’s clear, where who takes the lead.
In addition, starting to treat OT like IT, does create certain fears within the workforce, as some might feel a little redundant or underqualified, which just takes a little time.

Eventually…

Eventually, distinguishing between IT and OT is probably just an individual strategic decision, with a long list of different approaches and motivations behind it. So just keep in mind, that in a perfect approach we’d have threat and risk analysis for each individual component and system and could thus just do the maths to calculate the ideal security measures. Working with categories, clusters and IT or OT is just a compromise to make things easier – so make sure it does.