Lesson 2: IT/OT Security Principles

Every student who has taken one security course can recite confidentiality, integrity, availability. Most of them have never been asked why that order exists. It exists because in the environments where the triad was popularized, the asset was information, and the worst thing that happens to information is that the wrong person reads it. Order the properties by consequence and confidentiality lands on top. The triad is not a law of nature; it is a consequence ranking for a particular kind of asset.

Change the asset and the ranking changes with it. At Clearwater the asset is not a record, it is a physical outcome: water that leaves the plant within specification. An attacker who reads the current chlorine setpoint has taken nothing anyone will miss. An attacker who changes it, or who prevents the operator from seeing that it changed, has reached the thing the facility exists to produce. Apply the same consequence test the IT ordering was built on and it produces availability and integrity first, confidentiality last. Students find this convincing when they derive it; they find it arbitrary when they are handed it.

Be precise about what availability means here, because the word is doing different work than it does in a service-level agreement. Enterprise availability is usually a percentage over a year. Control availability is a deadline measured in milliseconds, repeated continuously: the loop must close on time, this cycle, and the next one. A system that is up 99.99 percent of the year but drops fifty milliseconds at the wrong moment has failed in a way the annual figure cannot express.

Integrity deserves the same care. In IT, integrity usually means the file has not been altered. In OT it extends to the number on the operator's screen, the setpoint in the controller, the logic that was downloaded to the PLC, and the timestamp on the historian record that will become a regulatory submission. An operator making a correct decision from a corrupted reading produces a physical outcome that no later forensic finding can undo.

The common shorthand is that OT uses a "SAIC" model with safety bolted onto the front. It is a useful mnemonic and a slightly misleading one. Safety is not competing for rank with the other three properties, because you never trade a unit of safety for a unit of confidentiality. Safety is the boundary condition inside which the other three are optimized. Anything that improves a security property while degrading safety has not made a trade-off; it has failed.

This distinction has teeth in practice. Consider a proposal to require multi-factor authentication at the HMI in the Clearwater control room. As a confidentiality and access control measure it is excellent. As a safety measure it may be catastrophic, because an operator responding to a high-level alarm at 3 a.m. now stands in front of a prompt while a clearwell overflows. The correct answer is not "security wins" or "operations wins" — it is that the control must be redesigned so it does not sit in the path of an emergency action. Authenticate the session at shift start, authenticate privileged changes, and leave the alarm response path clear.

The safety instrumented system makes the constraint visible in hardware. The SIS exists to drive the process to a safe state independently of the control system, it is engineered and certified to its own discipline under standards such as IEC 61511, and it is deliberately not a place where a security team experiments. When students ask why it cannot simply be hardened like everything else, the answer is that any change to a certified safety function requires re-validation, and an unvalidated safety function is worse than an unpatched one.

When an IT student says a system is available, they mean a request would succeed if one arrived. When a control engineer says the same words, they mean the loop closed on schedule and will close again in twenty milliseconds. The difference is not pedantry. It determines which failures count, which controls are acceptable, and how you would even measure whether your security program has hurt anything.

Availability in OT also stacks in layers that fail differently. If the historian is unavailable, nothing physical happens today — but the monthly compliance report to the state is at risk, which is a regulatory problem on a longer clock. If the HMI is unavailable, the process keeps running while the operator goes blind, which is a live safety concern even though nothing has technically stopped. If the controller is unavailable, the process is uncontrolled. Teaching students to name which layer they are talking about prevents an entire category of sloppy risk statements.

This layered view also explains why the reflexive containment move from an IT playbook can be precisely wrong here. Isolating a suspected HMI removes the operator's window into a running physical process. Isolating a controller may leave the process in an uncontrolled state. Containment in OT has to be designed in advance, with engineering, for specific scenarios, and the design frequently involves manual operating procedures rather than a network action. That is a planning obligation, and it belongs in the curriculum before the incident response lesson, not after it.

Integrity in a control environment is the property that makes the rest of the system usable. An operator does not observe the process; they observe a rendering of the process assembled from sensor readings, transported over a network, and drawn on a screen. Every one of those steps is an opportunity for the picture to diverge from the plant. The dangerous outcome is not that the operator sees nothing — it is that they see something plausible and wrong, and act correctly on it.

Break integrity into the objects that carry it, because "data integrity" is too coarse to act on. There is the process variable in flight from a transmitter. There is the setpoint held in the controller. There is the control logic itself, which defines what the plant does. There is the alarm configuration, which defines what the operator will be told. And there is the historian record, which will later be used to prove compliance to a regulator. Each of these has a different threat, a different owner, and a different verification method.

Most legacy industrial protocols provide no help here at all. Modbus TCP and classic DNP3 were designed for a private serial link between devices that trusted each other by virtue of being wired together. A write to a register is a write to a register; nothing in the frame proves who sent it or that it was not altered. This is not a defect that someone forgot to fix — it is the correct design for the environment the protocol was built for, and it becomes a problem only when that environment is connected to something else. Students who understand this stop treating legacy protocols as negligence and start treating them as a design constraint that architecture must compensate for.

Practical integrity assurance in OT therefore leans on things other than cryptography in the protocol. Known-good archives of controller logic with a verified restore. Change detection on project files. Configuration baselines compared on a schedule. Cross-checks between independent instruments where the process allows. Time synchronization so that records can be correlated at all. None of these are glamorous; all of them are what an assessor will ask for.

Ranking confidentiality last is a statement about priority under conflict, not a licence to ignore it. When a control would improve confidentiality at the cost of availability or safety, the OT answer is usually to decline it or redesign it. When it costs nothing operational, there is no reason to skip it. Students who take the inversion too literally arrive at "confidentiality does not matter in OT," which is wrong and will embarrass them in front of anyone who works in the field.

There is real material to protect. Process recipes and setpoint tables are frequently the most commercially sensitive thing a manufacturer owns. Network diagrams, asset inventories, and firewall rule sets are a map for anyone planning against the facility. Vendor drawings and integrator documentation often carry contractual confidentiality obligations. In defense manufacturing, some of this is controlled unclassified information with statutory handling requirements. And in utilities, certain system information carries regulatory protection of its own.

For a faculty audience this connects directly to how you run your own course. Student work products in an OT class tend to accumulate exactly the material described above — real drawings from an employer, a photograph of a live panel, a network diagram from an internship. The course safeguards require this to be synthesized or scrubbed before it reaches a shared repository, and this is the section where you explain to students why that rule exists rather than simply enforcing it.

Data exists in three states and each one is protected by different mechanisms. Data at rest is stored: historian archives, controller project files, HMI graphics, backup images, engineering drawings. Data in transit is moving: a Modbus read, a DNP3 poll, a syslog message, a report emailed to the state. Data in use is loaded in memory and being acted upon: the process variable inside the PLC's current scan, the value the HMI is rendering right now, the setpoint the controller is comparing against.

Enterprise security spends most of its energy on the first two, because that is where the enterprise risk sits — a stolen database is data at rest, an intercepted session is data in transit. OT inverts this emphasis in the same way it inverts the triad. Data in use is where the physical consequence lives, because that is the state in which data becomes motion. A corrupted historian archive is a reporting problem discovered later. A corrupted value in the active scan is a valve position now.

The awkward part is that data in use is also the state with the fewest available controls. You cannot encrypt a value the controller has to act on, and you generally cannot add an integrity check inside a deterministic scan without spending the timing budget the loop needs. So protection of data in use is achieved almost entirely indirectly: control who can reach the device at all, control what may be written and from where, and detect changes to logic and setpoints after the fact. This is the clean argument for why segmentation and access control carry so much weight in OT — they are the only practical way to protect the state that matters most.

Students reach for technical controls first because technical controls are what they came to learn. Left alone, they will produce a recommendation list that is entirely firewalls and multi-factor authentication, and a plant manager will decline most of it. Teaching the three families explicitly gives them a wider vocabulary and, more usefully, a way to salvage a recommendation that has just been refused on operational grounds.

Administrative countermeasures are the ones written down and enforced by authority: policy, standards, procedures, management of change, role definitions, contract language with an integrator, an acceptable use agreement, a documented approval path for a firmware update. In OT these are unusually powerful, because management of change is already an established discipline in a plant. A security requirement folded into an existing MOC process gets followed; the same requirement issued as a new security policy competes for attention and loses.

Educational countermeasures are the ones that change what people do when nobody is watching: role- specific training, awareness campaigns, tabletop exercises, drills, competency verification before someone gets privileged access. They are cheap relative to their effect and they are the family that community college faculty are best positioned to influence, since the workforce being trained is the control. This is worth saying out loud in a faculty workshop — your curriculum is itself a countermeasure deployed across the region.

Technical countermeasures are the engineered ones: network segmentation, conduits and firewall policy, application allowlisting, jump hosts, unidirectional gateways, logging and passive monitoring, backup and tested restore. They are necessary and they are the family most constrained by the operational realities in this lesson. The professional judgment being taught is not which family is best — it is that a defensible program uses all three, and that when one family is blocked, the other two absorb the risk.

A PLC does the same four things forever: read all inputs, execute the logic, write all outputs, service communications. That sequence is the scan cycle, and it has a budget. For a fast process the budget may be ten or twenty milliseconds. Determinism is the guarantee that the cycle completes inside that budget every time — not on average, not usually, every time. Average performance is an IT metric. Worst case is the OT metric.

This is where the security connection becomes concrete rather than rhetorical. A controller has to spend part of its budget servicing communications. Unexpected traffic — a scan, a broadcast storm, a chatty new monitoring tool, a malformed request the stack handles poorly — consumes that portion and can push the total past the deadline. The controller does not crash and there is no alert. It simply completes late, which means an input was read late and an output was written late. On a slow process nothing observable happens. On a fast one, that is a physical event.

The practical consequence is that a whole category of ordinary IT activity is restricted on control segments. Active vulnerability scanning may be limited to outages or prohibited outright. Discovery tools may be required to run passively from a span port. New monitoring agents get evaluated for their traffic profile before deployment. None of this is superstition, and students should be able to explain the mechanism rather than repeating "you can't scan OT" as a rule they were handed.

Teach the flip side too, or students will conclude that nothing can be done. Passive monitoring provides substantial visibility with zero traffic added. Test systems and simulators absorb the activity that production cannot. Vendor guidance often specifies exactly what a device tolerates. And an outage window, planned with operations well in advance, is a legitimate and frequently used way to do the things that cannot be done while running.

Enterprise hardware is refreshed on a three-to-five-year cycle because the business case supports it. Industrial equipment is specified for fifteen to twenty-five years and routinely exceeds it, because the business case does not: the controller is not the expensive part. Replacing it means requalifying a process, revalidating a safety function, retraining operators, updating drawings, and accepting downtime. A perfectly functional PLC from 2004 stays because replacing it costs vastly more than the device is worth.

Patching runs into the same wall from a different direction. A vendor may need to validate the patch against the installed configuration, which takes time. The plant will not apply it outside a scheduled maintenance window or turnaround, which may be months away. Some devices have no update path at all. Students should stop reading "unpatched" as a finding to be written up and start reading it as the environment they will be designing within for their entire careers.

What replaces patching is architecture, and this is where the Purdue Model and IEC 62443 stop being vocabulary and start being the answer. If the vulnerability requires network reachability, remove the reachability: put the device in a zone, define the only permitted path as a conduit, and terminate remote access at a jump host. If it requires a service, disable the service where the vendor permits. If neither is possible, increase monitoring on the segment so exploitation would be visible, and verify that a known-good copy of the controller logic exists and has actually been restored in a test.

The Purdue Model gives a mixed room a shared drawing. Level 0 is the physical process — sensors and actuators. Level 1 is basic control, where PLCs and RTUs execute logic. Level 2 is area supervisory control: HMIs, engineering workstations, local alarm servers. Level 3 is site operations, holding the historian, OT domain services, and plant-wide applications. Levels 4 and 5 are the business: ERP, email, corporate services, the internet.

The layer that does the real work sits between 3 and 4 — the industrial DMZ, conventionally called Level 3.5. Its purpose is to eliminate any path where an enterprise system talks directly to a control system. The historian is replicated into the DMZ so business analysts query the copy, never the original. Remote support terminates at a jump host in the DMZ where sessions are authenticated, mediated, and recorded. Where assurance requirements are highest, a unidirectional gateway allows data out while making inbound flow physically impossible.

IEC 62443 generalizes the same instinct with better vocabulary. Instead of fixed layers it asks you to group assets that share security requirements into a zone, and to define every permitted communication path between zones as a conduit with its own controls. This survives contact with real plants better than five clean levels do, because a wireless sensor network or a vendor-managed skid rarely sits neatly on a layer. It also produces a sentence students can write and defend: this zone, that zone, this protocol, this direction, initiated by this party.

Be honest about the model's limits. Cloud analytics, IIoT gateways with cellular connections, and vendor remote-monitoring services all cross layers by design, and modern architectures are less strictly hierarchical than the drawing suggests. Purdue remains valuable not as a mandate but as a forcing function: every line on the diagram makes someone answer three questions — what is allowed to cross here, in which direction, and who initiates it?

Everything in this lesson descends from a single move: apply the same consequence test that produced the CIA ordering, to an asset that is physical rather than informational, and let the answer come out differently. Safety becomes the constraint rather than a competitor. Availability becomes a repeating deadline. Integrity becomes the trustworthiness of the number an operator is about to act on. Confidentiality keeps its value but yields under conflict.

The three structural facts follow from the same place. Data in use is where consequence lives and where direct controls are unavailable, so architecture substitutes for cryptography. Determinism makes latency a security property, so ordinary IT activity has to be re-examined rather than banned by folklore. Twenty-year lifecycles make patching an occasional event rather than a routine one, so zones and conduits carry the risk that patching carries elsewhere.

A participant who has this lesson can do three things. They can re-rank the triad for a described facility and defend the ranking to a skeptical IT peer. They can name which countermeasure family a proposed control belongs to and supply an alternative when it is refused. And they can write a permitted communication path as a zone-and-conduit sentence rather than as a firewall rule. Lesson 3 takes the device tour — PLCs, RTUs, IEDs, HMIs, historians, safety systems — and every device gets placed on the drawing you started here.