Teaching Operational Technologies

Start with a comparison your students can feel. A hospital's billing server is compromised and patient records are exposed: the harm is real, it is expensive, and it is measured in records, notification letters, and regulatory penalties. Now change one variable. At Clearwater, an attacker who reaches the chemical dosing controller does not steal anything at all. They change a number — the sodium hypochlorite setpoint — and the harm is measured in parts per million, in a boil order issued to forty thousand households, and possibly in someone's health.

That is the whole distinction, and it is worth spending real time on before a single acronym appears. Industrial cybersecurity protects a process, not a database. The asset under threat is the physical outcome the system produces: water that is safe to drink, a weld that holds, a turbine that spins at the right speed, a batch that meets specification. Data matters mainly because it is the mechanism by which someone influences that outcome.

Once consequence is understood, the economics follow naturally. Downtime in an industrial setting is not a help desk queue; it is production hours that cannot be recovered. A line that stops for a shift may take longer to restart than it did to stop, because material in process has to be purged, equipment has to be brought back up in sequence, and quality has to be re-verified before the first sellable unit comes off the end. When a plant manager resists a control you propose, this is usually the arithmetic behind the resistance.

It is also worth telling students plainly that a great deal of industrial cyber harm is not an attack at all. A vulnerability scan aimed at a fragile device stack, a misconfigured firewall rule pushed during a maintenance window, a technician's laptop carrying commodity malware from a home network — these produce process upsets regularly. Framing the field as purely adversarial gives students an incomplete and slightly cinematic picture. Reliability and security are the same discipline here more often than not.

Underneath every industrial control system is one repeating idea: sense a condition, compare it to a target, act on the process, and repeat. A level transmitter in a clearwell reports that the tank is at 61 percent. The controller compares that measured value — the process variable — against the operator's setpoint of 65 percent, finds an error of four percent, and opens a valve or speeds a pump until the error closes. Then it does the whole thing again, and again, on a fixed cycle measured in milliseconds.

That fixed cycle is the part IT students tend to miss, and it explains a surprising amount of OT behavior. A programmable logic controller runs a scan: read all inputs, execute the logic, write all outputs, handle communications, repeat. The program is deterministic and the timing budget is tight. A device that spends an unexpected fifty milliseconds answering malformed network traffic is not merely slow — it may have missed a scan, and a missed scan on a fast process is a physical event.

Above the controllers sits the supervisory layer, which exists so people can see and steer what the controllers are doing. An HMI renders the process as a graphic with live values and alarms. An operator adjusts a setpoint from a console. A historian quietly records every tag at intervals so that engineers can troubleshoot last Tuesday's upset and so the compliance report to the state can be generated at month end. None of these systems control the process directly; they mediate between the people and the controllers that do.

Finally, remind students that processes come in different shapes and fail differently. A continuous process — water treatment, refining, power generation — runs for months and cannot simply be paused. A batch process makes discrete lots to a recipe, where an interruption may scrap the batch. A discrete manufacturing line assembles countable units, where a stop is costly but recoverable. The security conversation changes with the shape of the process, and students who ask which one they are looking at are already thinking correctly.

SCADA and DCS are not competing products so much as two answers to two different problems. SCADA answers distance: a water utility with fifteen remote pump stations, a pipeline running two hundred miles, a distribution grid spread across a county. Control is largely local at each site, a supervisory system polls the field over whatever communications exist, and a few seconds of latency is tolerable. A DCS answers density: thousands of tightly coupled control points inside one facility, with redundant controllers, integrated engineering tools, and control loops that interact with one another continuously.

Inside either architecture, the same cast of devices appears. PLCs and RTUs execute logic in the field. Intelligent electronic devices carry protective functions in electrical systems. HMIs give operators a window and a set of controls. Historians and OPC servers move process data toward people who need to analyze it. Sensors and actuators sit at the boundary where the network stops being informational and starts being physical.

Spend extra time on the engineering workstation, because students consistently underrate it. The EWS holds the project files, the controller logic, and the software licensed to download that logic to devices. An attacker on the EWS does not need to craft protocol traffic or understand your process — they can use the vendor's own engineering tool exactly as intended. It is the machine that can rewrite what the plant does, it usually runs a general-purpose operating system, and it is frequently the least-maintained computer in the building.

Keep the safety instrumented system visually and conceptually separate from the moment you introduce it. The SIS exists to bring the process to a safe state independent of the control system — it is the last line, it is engineered and certified to its own discipline, and it is not a place where anyone experiments. Students should leave the lesson understanding that control and safety are deliberately different systems, for the same reason a building has both a thermostat and a sprinkler.

Students arriving from an IT program bring habits that are correct in their world and unwelcome in a control room. Make the differences explicit and early, because the alternative is a student who confidently recommends something that would shut down a plant and does not understand why the room went quiet.

The priority order inverts. In enterprise IT, confidentiality usually leads. In OT, safety leads absolutely, availability follows closely, integrity of process data matters because decisions are made from it, and confidentiality typically finishes last. Nobody at Clearwater is worried that an attacker learns the current tank level. They are worried that the level reading is wrong, or that the pump will not run.

Time scales differ by an order of magnitude. Enterprise hardware refreshes every three to five years; industrial equipment is specified for fifteen to twenty-five and often exceeds it. A controller installed when the plant was built may have no firmware update path, may speak a protocol designed for a private serial link, and may have a network stack that predates any expectation of hostile traffic. This is normal, not negligent, and students should stop treating it as a finding and start treating it as a design constraint.

Ownership differs too, and this may be the most consequential difference of all. OT typically reports to operations or engineering, not to the CIO. The people who own those assets are measured on production, safety, and regulatory compliance — not on patch percentages. A security professional who arrives with IT authority and no operational fluency will be politely ignored. Much of what makes someone effective in this field is the ability to translate a control into the language of uptime, safety, and cost.

Here is the situation that defines the job. A vulnerability is published for a controller running a critical process. The patch exists. The vendor has not yet validated it against the installed configuration, and even after validation the plant will not apply it until the next scheduled turnaround — which is in seven months. The textbook answer is unavailable to you for the better part of a year. What do you actually do?

The professional answer is compensating controls, and students should learn to reach for them without treating them as a compromise or a failure. If the vulnerability requires network reachability, restrict who can reach the device to a named jump host. If it requires a particular service, disable the service where the vendor permits. Increase monitoring on the segment so that exploitation would be visible. Verify that a known-good copy of the controller logic exists and that someone has actually restored it in a test. Each of these reduces risk without touching the process, and each can be explained to an operations manager in one sentence.

Scanning and containment need the same rethinking. Active scanning may be restricted to non-production periods or prohibited outright on sensitive segments, so visibility is built from passive traffic monitoring, configuration review, and physical walkdowns instead. And the reflexive incident response of isolating an affected host can be exactly wrong here: pulling an HMI off the network may leave an operator blind to a running process, which can be more dangerous than the intrusion. Containment strategies in OT have to be designed in advance, with engineering, for specific scenarios.

Quality belongs in this conversation as much as safety. In a regulated batch environment, an interruption at the wrong moment does not merely cost time — it can scrap product, trigger an investigation, and create a documentation trail that follows the plant for years. When you propose a control, someone in the room is calculating that exposure. Teaching students to anticipate that calculation is what turns a technically correct recommendation into an accepted one.

The Purdue Model gives a shared drawing to a room full of people who otherwise use different words for the same things. Level 0 is the physical process itself — 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, where the historian, the OT domain services, and plant-wide applications live. Level 4 and 5 are the business: ERP, email, the corporate network, the internet.

Between Level 3 and Level 4 sits the piece that does the real work — the industrial DMZ, often written as Level 3.5. Its purpose is to eliminate any path where an enterprise system talks directly to a control system. The historian gets 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. Rather than fixed layers, it asks you to group assets that share security requirements into zones, and to define every permitted communication path between zones as a conduit with its own controls. This turns out to be more useful in practice, because real plants are messier than five clean levels — a wireless sensor network or a vendor-managed skid may not sit neatly anywhere.

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

Most industrial incidents do not begin with anything exotic. They begin with conditions that a reasonably prepared student could find in an afternoon with a clipboard and permission to ask questions. Framing risk this way is deliberately deflationary — it moves students away from the idea that this field requires rare skill and toward the realization that it mostly requires attention.

Legacy systems come first because they are unavoidable. Unsupported operating systems on HMIs, controllers with no firmware update path, and applications that require a specific outdated runtime are all normal findings. Flat networks come second and are more consequential: when the business network, the control network, and the guest wireless share address space and routing, one compromised laptop reaches everything, and the blast radius of an ordinary infection becomes the whole plant.

Access is the third cluster, and in practice the busiest. Persistent vendor VPN connections that nobody reviews. A support account shared by an integrator's whole team. Operator consoles logged in for an entire shift because logging in for each action is impractical mid-process. Accounts belonging to people who left two years ago. None of this is exotic and all of it is common, which is exactly why access control and identity get a full lesson of their own later in the course.

The last cluster is the stuff that arrives outside the process. IIoT sensors and cellular gateways installed by a department that never spoke to the network team — shadow OT that bypasses the firewall entirely. USB drives and contractor laptops moving between facilities. Field devices still carrying vendor default credentials. And underneath all of it, the absence of a reliable inventory, which means nobody can say with confidence what is even connected.

The United States designates sixteen critical infrastructure sectors, and the striking thing about the list is how thoroughly the entries depend on one another. Water treatment requires electricity. Electricity generation requires fuel delivery and communications. Fuel delivery requires pipelines, payment systems, and transportation. Hospitals require all of it. A disruption rarely stays inside the sector where it started, which is why an incident at a mid-size facility can produce consequences far out of proportion to the facility's size.

One pattern deserves particular attention because it recurs constantly and students routinely misread it. Ransomware lands on the business network — billing, scheduling, order management, none of it touching a controller. The operator nonetheless shuts down production. Not because the malware reached the process, but because they cannot prove it did not, and continuing to run a physical process with uncertain boundary integrity is not an acceptable risk. Poor segmentation and poor visibility convert an IT incident into an OT outage, without the attacker ever having to reach OT.

Teach real incidents, and teach a lot of them — but establish the protocol first. This course reads incidents at the level of conditions, control gaps, and outcomes: what made it possible, what detected it or failed to, what the operational impact was, and what the organization changed afterward. It does not reconstruct attacks as procedures, walk through tooling, or produce anything a student could carry out against a live system. That boundary is stated in the course safeguards and it holds in every case discussion.

Public advisories are a good habit to build early. Vendor security bulletins and national advisories give students current, defensible material and get them reading primary sources rather than headlines. A standing assignment — bring one advisory relevant to a device we have discussed, and explain the affected function in plain language — pays off all term.

A defensible OT program has an order of operations, and inventory comes first. You cannot segment a network whose devices you cannot enumerate, monitor traffic whose baseline you have never established, or restore a controller whose logic nobody archived. In environments where active scanning is restricted, that inventory gets assembled from passive traffic analysis, configuration exports, purchase and maintenance records, and walkdowns — slower than a scan, and entirely achievable.

From there the layers stack in a sensible sequence. Segmentation and a real industrial DMZ limit reach. Access control removes standing vendor connections and grants privilege by role and by need. Hardening disables unused services and ports and removes default credentials wherever the vendor permits it. Monitoring — passive, with synchronized time across every log source so events can actually be correlated — provides detection. Backup and recovery covers controller logic and device configurations, not just servers, and the restore is tested rather than assumed. Physical security underpins all of it, because an unlocked panel defeats a great deal of network engineering.

Frameworks give this structure a common language. IEC 62443 is the OT-native family: it organizes systems into zones and conduits, defines security levels as targets rather than grades, and assigns distinct responsibilities to asset owners, system integrators, and product suppliers. NIST SP 800-82 provides practical guidance specific to operational technology and maps cleanly onto the Cybersecurity Framework's functions, which is useful when an OT program has to report alongside an enterprise program. ISO/IEC 27001 contributes the management-system discipline — documented scope, risk treatment, evidence, review.

Pick one framework as the spine of your course and reference the others. Teaching four frameworks in parallel produces students who can recite structure and cannot apply any of it. For most community college programs, IEC 62443 is the right spine — it is OT-native, employers recognize it, and its vocabulary of zones, conduits, and security levels gives students language that will still be useful in the capstone and in an interview.

Return to where the lesson opened. A record breach is measured in records; a process compromise is measured in parts per million, in gallons, in degrees, in whether a valve closed when it was supposed to. Every distinctive feature of this field descends from that single fact — the inverted priority order, the twenty-year equipment, the refused patch, the layered architecture, the caution about scanning something that is currently controlling a pump.

Students should now be able to name the components of a control system and place them on a Purdue drawing without notes, explain to a skeptical IT peer why confidentiality ranks last at Clearwater, and identify several risk drivers in a facility they have only read about. If a student can do those three things, the foundation is sound and everything else in the course is elaboration.

Lesson 2 turns these principles into architecture decisions. Where exactly does the boundary go, what crosses it, and how do you defend a design choice to someone whose primary concern is that the plant keeps running? Bring the drawing from this lesson; it becomes the working document.