IT/OT Security Principles

In IT, the CIA triad is usually taught — and usually practiced — in the order confidentiality, integrity, availability. Confidentiality means keeping data secret from anyone not authorized to see it; integrity means data hasn't been altered in unauthorized ways; availability means authorized users can get to the system when they need it. IT's default instinct, when those three collide, is to protect the secret first, even at some cost to uptime — an unpatched, internet-facing web server usually gets taken offline immediately rather than left running exposed.

In OT, that ordering breaks down as soon as you apply it to a real process. Availability, defined here as the control system continuing to run the physical process without interruption, is almost always the priority IT would rank last but OT ranks first within the triad. Integrity — trusting that a sensor reading or a command is accurate and hasn't been tampered with — usually ranks second, because an operator who trusts a false reading can make a dangerous decision. Confidentiality, the very first thing IT protects, usually ranks last in OT, not because secrecy doesn't matter, but because almost nothing about "the tank is 62% full" is sensitive in the way a customer's password is.

Safety in OT refers to the prevention of harm to people, the environment, and physical assets — and it is not the fourth item in a longer triad. It sits structurally above confidentiality, integrity, and availability, because a security decision that compromises safety is not a trade-off worth making, no matter what it protects. This is formalized in functional-safety standards such as IEC 61508 and IEC 61511, which govern safety instrumented systems (SIS) — independent layers of sensors, logic solvers, and final elements (like emergency shutdown valves) whose entire job is to force a process into a safe state when a hazardous condition is detected, regardless of what else is happening on the network.

The practical rule that follows is simple to state and easy to violate under pressure: a cybersecurity control must never be allowed to inhibit a safety function. Taking a safety system offline "just for twenty minutes" to apply a patch, run a vulnerability scan, or swap a certificate is not automatically the safe choice just because it's the security-compliant one — it can be the opposite. IEC 62443, the standard most directly aimed at industrial automation and control system security, is explicit that security measures must be designed and tested to coexist with, not compete with, safety functions.

Determinism means a system produces the same output within the same, predictable amount of time, every time — not "usually fast," but "guaranteed within this window." A PLC's control loop runs on a fixed scan cycle: read inputs, execute logic, write outputs, repeat, often every few milliseconds to a few tens of milliseconds. Everything downstream of that loop — a motor's speed, a valve's position, a robot's coordinated motion — assumes that cycle time is stable. IT security tools were built for a fundamentally different world, one where a five-second delay to run a malware signature check is invisible to a human reading email. On a control network, five milliseconds of unplanned delay can be the difference between a smooth stop and an overspeed fault.

This is why the standard IT security toolkit — real-time antivirus, automatic patch installation, deep-packet-inspection firewalls sitting inline — has to be applied very differently, or sometimes not applied at all, at the lower levels of an OT network. It isn't that OT doesn't care about malware. It's that a control loop cannot tolerate an unpredictable CPU spike or network delay, and most IT security tooling was never engineered to guarantee it won't cause one.

IT's patch cadence assumes a refresh cycle measured in years — three to five for a server, often less for a laptop. OT capital equipment is frequently engineered, procured, and depreciated on a cycle measured in decades: a rolling mill, a distillation column, or a substation transformer is routinely expected to run for twenty years or more, often with the same control system installed on day one still running on year eighteen. That single fact breaks almost every assumption IT security tooling makes about "just patch it."

Once faculty accept that OT prioritizes differently and runs on a different clock, they need a shared map for talking about where a given device or system actually sits. The Purdue Enterprise Reference Architecture — almost always shortened to the Purdue Model — organizes an industrial enterprise into numbered levels, from field devices at Level 0 up to the enterprise IT network at Level 5, with a buffer level, 3.5, inserted between the OT and IT halves. It was never designed as a security architecture on its own, but it has become the standard teaching scaffold for one, because it gives every device a defensible "address" and every security decision a defensible "location."

Zones and conduits, the vocabulary formalized in IEC 62443, build directly on top of that map. A zone is a grouping of assets that share the same security requirements and the same level of trust — typically, though not always, aligned to one or more Purdue levels. A conduit is the governed pathway that connects two zones, and it's where security controls — firewalls, data diodes, protocol-aware inspection — actually live. The Purdue levels tell you what belongs together; zones and conduits tell you how (and whether) two groupings are allowed to talk to each other at all.

Select a scenario below to see how the same decision plays out differently depending on whether it's made using IT's default priority order or OT's. Nothing here touches a real network, controller, or patch pipeline — this is a model of a decision, not a procedure to follow.

Five questions covering the lesson's key distinctions. Answer each, then select Grade My Quiz to see your score and an explanation for every item.

• 📄 Download: Purdue Model Reference Diagram (PDF) — a printable version of the levels-and-zones diagram used in this lesson, suitable for classroom handout.
• Introduction to ICS Security, Part 2 (SANS) — a practitioner-level follow-up on the priority inversion and safety concepts introduced in this lesson.
• CUBE: Interactive ICS Environment Explorer — an external, browser-based tool for exploring ICS architecture concepts; review before assigning, as it is maintained outside this course.