← All coursesBack to the simulator →

OT/ICS: industrial network security

Networks that move real things: PLCs, HMIs and the historian, availability first, the Purdue model and IT/OT segmentation, the industrial DMZ, Modbus without authentication, the data diode and one-way flows, attacks on OT (Stuxnet, ransomware, insiders, vendor access) and operational defense (inventory, passive monitoring, zones, backups).

This is a text preview of the lessons for reading. The full version – an interactive simulator with animations, exercises and quizzes – runs in the app.

▶ Launch the interactive version

Lesson 1: What OT is and why it differs

The network that moves things

IT-PCENGFWHISTHMIPLCDIODEPLC: reads sensors, switches valves

So far our courses lived in the IT world: computers, servers, websites – the network moves information. Now we enter a world where the network moves real things: conveyor belts in a factory, valves in a water plant, turbines in a power station. It is called OT (Operational Technology) and its networked form ICS (Industrial Control Systems). Meet the main elements on the scene: a PLC (programmable logic controller) is a small rugged computer bolted next to a machine – it reads sensors and switches motors or valves; it is the hand that actually moves things. An HMI (Human-Machine Interface) is a touch panel or a control room from which an operator watches and drives production – it sends commands to the PLC. A historian is a database that continuously stores values from production (temperatures, pressures, piece counts) so the rest of the company can look at them. And the supervisory system above it all is called SCADA. Why does this belong in a security course? Because when IT fails, you lose data. When OT fails, production stops – or a boiler blows. The firewall (FW) and the data diode (DIODE) on the scene will make sense in later lessons.

Step by step

  1. A PLC is a rugged computer next to a machine. It reads sensors and switches motors or valves – it moves real things.
  2. From the HMI (panel, control room) the operator watches and drives production – sending the PLC commands. The supervision above it is SCADA.
  3. The historian continuously stores production values (temperatures, pressures, counts) so the rest of the company can see them.
  4. Why security? When IT fails, you lose data. When OT fails, production stops – or physical damage happens.

Availability above all

IT-PCENGFWHISTHMIPLCDIODEIT: confidentiality > integrity > availability

In IT security you learned the CIA priority order: confidentiality first, then integrity, availability last. In OT the order is exactly reversed: availability > integrity > confidentiality. Why? Picture a bottling line. If someone ‘reads’ how many bottles per hour you fill, it is unpleasant – but production runs. If the line stops, every minute costs money, restarting takes hours, and for some processes (a melting furnace, chemicals) an outage can mean destroyed equipment or danger to people. From this priority follows behavior that surprises IT folks: in OT you do not reboot ‘just in case’, you do not install updates mid-shift, and a security measure that could take production down is worse than none. Even a well-meant action – a network scan, an agent on a workstation – can knock over sensitive control systems (more in lesson 6). Remember this as the key to the whole course: every OT measure is judged first by ‘can it stop production?’ – and only then by ‘does it improve security?’.

Step by step

  1. In IT you mainly protect data: the CIA order – confidentiality, integrity, availability.
  2. In OT the order is reversed: availability above all. The line must run.
  3. Stopped production costs money every minute; with furnaces or chemicals it risks destroyed equipment or danger to people.
  4. The key: judge every OT measure first by ‘can it stop production?’ – only then by ‘does it improve security?’.

Twenty years without a patch

IT-PCENGFWHISTHMIPLCDIODEa PLC serves 20–30 years

The second culture shock for an IT person: equipment age. You replace a laptop after five years, a server after seven. PLCs and control systems are bought with the production line and serve 20 or 30 years – as long as the line runs. Inside often runs an old system (Windows XP in a control room is not a joke but common reality) that has had no patches for years. And even if patches existed: an update means an outage and the risk the line will not restart – and the line’s vendor often forbids touching the system, or you lose warranty and certification. The result: an OT network is full of devices with known, never-fixed holes – which nobody may or can fix. What then? Flip the approach: when I cannot fix the device, I must protect the network around it. I wrap the vulnerable PLC in segmentation and a firewall so an attacker never reaches it – a hole nobody can reach cannot be exploited. This is called a compensating control and it is the main reason the rest of this course is about segmentation, one-way flows and monitoring, not patching.

Step by step

  1. PLCs and control systems are bought with the line and serve for decades – as long as the line runs.
  2. Inside run old systems without patches; an update = outage + risk + often a vendor ban.
  3. Flip the approach: a hole an attacker cannot reach cannot be exploited. Wrap the vulnerable PLC in segmentation and a firewall.
  4. These are compensating controls – which is why the rest of the course is about segmentation, one-way flows and monitoring.

▶ Open in the simulator

Lesson 2: The Purdue model and IT/OT segmentation

The Purdue model: the plant’s floors

IT-PCENGFWHISTHMIPLCDIODElevels 0–1: sensors, valves, PLC

How do you find your way around an industrial network? A map called the Purdue model is used: it splits the plant into levels 0–4 by how close they are to the physical process. Level 0: sensors and actuators – thermometers, valves, motors. Level 1: the PLC that reads and drives them. Level 2: supervision and control – the HMI, the control room, SCADA. Level 3: managing production as a whole (shift planning, recipe management). And on top level 4: ordinary corporate IT – email, accounting, offices. On our scene: IT-PC is level 4, the HMI level 2, the PLC level 1. What is the map for? It gives the network admin and the plant engineer a shared language: ‘this traffic belongs to level 2, nothing from level 4 goes through here’. Above all it defines boundaries: between levels (mainly between 3 and 4 – between OT and IT) you build a firewall, and traffic is allowed only rarely and deliberately. The lower you are in the model, the more sensitive the network and the fewer things may enter it. How exactly to build the IT/OT boundary is shown in the next two modules.

Step by step

  1. At the bottom level 0 (sensors, valves, motors) and level 1 (the PLC driving them). The most sensitive floors.
  2. Level 2: supervision and control – HMI, control room, SCADA. Level 3 then manages production as a whole.
  3. On top level 4: offices, email, accounting – the ordinary corporate IT network.
  4. Between levels you build boundaries – mainly between IT and OT stands a firewall, and traffic is allowed only deliberately.

Why IT must not reach the PLC directly

IT-PCENGFWHISTHMIPLCDIODEthe office network = the dirtiest

Why so strict? It would be convenient for the production manager to look at the PLC straight from the office… But think through what a direct link means. The office network (level 4) is the dirtiest part of the company: people click attachments, browse the web, bring their own devices – malware shows up there routinely. If a direct path led from it to the PLC, every infected office PC is one hop from production. And recall lesson 1: the PLC is twenty years old, unpatched, and if it drops, the line stops. A direct IT→PLC link thus connects the dirtiest network to the most vulnerable device – the worst possible combination. Hence the rule: the IT network never touches the PLC directly. Between IT and OT stands a firewall (FW on the scene) with a default-deny policy: what is not explicitly allowed is forbidden – the same rule you know from course 5, only here it guards a boundary between two internal worlds, not the internet edge. Yet production does need to share data (the manager really wants those numbers). How to get them out without a path leading in? That is the job of the industrial DMZ – next module.

Step by step

  1. Level 4 is the dirtiest: attachments, web, personal devices – malware shows up here routinely.
  2. A direct IT→PLC link = the dirtiest network + the most vulnerable device. An infected PC is one hop from production.
  3. So between IT and OT stands a default-deny firewall: what is not explicitly allowed is forbidden (course 5).
  4. Yet production needs to share data. How to get it out with no path in? The industrial DMZ – next module.

The industrial DMZ and the middleman

IT-PCENGFWHISTHMIPLCDIODEthe historian lives in the DMZ (level 3.5)

From course 5 you know the DMZ: an anteroom between the internet and the inner network where you put the web server so strangers do not come inside. Industry uses the same trick between IT and OT: it builds an industrial DMZ (called level 3.5 in the Purdue model, because it sits exactly between level 3 – production management – and level 4 – corporate IT) and places the historian there – a data middleman. The flow looks like this: from the OT side the historian continuously pulls production values and stores them; from the IT side anyone authorized queries the historian (a database query) and reads the numbers. What matters is what the firewall allows: IT → historian: YES (the database port only), IT → PLC: NO, OT → historian: YES (data collection). No rule leads from IT into OT! The production manager has his numbers – and yet no path exists for office malware to hop onto the PLC: it gets at most to the historian, which (unlike the PLC) is modern, patched and expendable – if it fell, production keeps running. Note the general principle, you will meet it across OT security: data is handed over via a middleman in the DMZ, never by a direct link between a dirty and a sensitive network. The ‘OT/ICS network’ preset in the simulator is built exactly this way – you will try it in lesson 3.

Step by step

  1. Between IT and OT an industrial DMZ (level 3.5) is built, and the historian – the data middleman – goes in it.
  2. From the OT side the historian continuously collects and stores production values.
  3. From the IT side the authorized query the historian (a database query). No rule allows IT → PLC.
  4. The principle of OT security: data via a middleman in the DMZ, never a direct link between a dirty and a sensitive network.

▶ Open in the simulator

Lesson 3: Industrial protocols

Modbus: a protocol without a lock

IT-PCENGFWHISTHMIPLCDIODEModbus/TCP: ‘write register’ (port 502)

What do OT devices speak to each other? The most widespread industrial protocol is Modbus – born in 1979 for serial lines, later given the network form Modbus/TCP on port 502. It is beautifully simple: ‘read register 40001’, ‘write value 75 into register 40002’. But that simplicity has a dark side: Modbus has no authentication at all. No password, no verification, no encryption. The PLC executes a command from anyone able to connect to port 502 – the protocol does not distinguish whether the writer is the authorized HMI or an attacker’s laptop. Write ‘open the valve fully’ and the PLC opens it. This is not an implementation bug fixable by a patch – the protocol is designed that way: in 1979 the network was a few meters of wire between the control room and the machine, and nobody imagined a stranger could be on it. And it is not just Modbus: other industrial protocols (DNP3, Profinet, S7) are similarly ‘trusting’. Now you see in full force why the segmentation from lesson 2 is so essential: when the protocol cannot say ‘no’, the network must say it instead – the only real defense is that no unauthorized party ever reaches port 502.

Step by step

  1. Modbus/TCP (port 502): the HMI reads and writes PLC registers – ‘read the temperature’, ‘set the valve’.
  2. The dark side: Modbus has no authentication. The PLC executes a command from anyone on port 502 – by design (1979).
  3. The protocol cannot tell the authorized HMI from an attacker’s laptop. ‘Open the valve fully’ – and the PLC obeys.
  4. When the protocol cannot say ‘no’, the network says it: segmentation and the firewall keep the unauthorized away from port 502.

Where data flows: 502 vs 1433

IT-PCENGFWHISTHMIPLCDIODEinside OT: HMI ↔ PLC (Modbus 502)

Let us merge lesson 2 and the previous module into one picture – what flows where in a well-built industrial network. Inside OT: HMI ↔ PLC over Modbus 502 – the operator drives production, both sit in the same sensitive zone, this traffic never leaves. Data collection: the historian reads values from the PLC (Modbus 502) – the only one allowed to peek from the DMZ into OT, and only to read data. And the office: IT-PC → historian over database port 1433 (SQL) – the manager sees production charts without getting anywhere near the PLC. Notice how the firewall distinguishes by port and direction: 1433 from IT into the DMZ yes, 502 from IT to anywhere NO – port 502 never crosses the OT/DMZ boundary outward. This ‘what is allowed’ set has a name you know from course 5: a flow whitelist. In OT it is especially effective because an industrial network is boring and predictable: the same devices exchange the same messages over and over, no web browsing. The list of legitimate flows fits on one page – and everything else is suspicious. You may have already seen exactly this topology in the simulator: the ‘OT/ICS network – IT/OT segmentation’ preset. In the next module you will verify the rules on it.

Step by step

  1. Inside OT: HMI ↔ PLC over Modbus 502. Both in the same sensitive zone – this traffic never leaves.
  2. Data collection: the historian reads PLC values – the only allowed peek from the DMZ into OT, data only.
  3. The office: IT-PC → historian on port 1433 (SQL). The manager sees charts and never nears the PLC.
  4. The firewall distinguishes port and direction: 1433 from IT yes, 502 from IT never. OT is predictable → a short flow whitelist.

Verify it in the simulator

IT-PCENGFWHISTHMIPLCDIODEtest 1: IT → PLC:502 → blocked ✓

Theory is nice, but this simulator exists so you can touch it. The whole architecture from the last two lessons is ready for you: in the Templates menu open the ‘OT/ICS network – IT/OT segmentation’ preset. You will find exactly our scene: an IT LAN, the inter-firewall, an industrial DMZ with the historian and an OT LAN with the PLC and HMI. What to try? In the right-hand Traffic Test panel pick a Source (from) and a Destination (protocol and port under Advanced) and click ▸ Test traffic: (1) IT-PC → PLC on port 502 – it must end blocked at the firewall; this very rule protects production from the office. (2) IT-PC → historian on port 1433 – it must pass; that is how the manager gets his numbers. (3) Historian → PLC on 502 – passes; that is the allowed data collection. Then open the firewall rules and note the default-deny policy: the list of allowed flows is short, everything else falls. And if you are up for it, try the ‘OT/ICS segmentation’ challenge in Tasks: you get a broken industrial network and your job is to build the IT/OT boundary yourself. Learn to read a blocked packet as good news: in OT every ‘blocked’ in the right place is one path an attacker cannot take to a valve.

Step by step

  1. Test 1: IT-PC → PLC on port 502. The packet must end blocked at the firewall – the office must not reach the PLC.
  2. Test 2: IT-PC → historian on 1433 must pass – this is how the office gets production numbers.
  3. Test 3: historian → PLC on 502 passes – the allowed data collection. Nothing else leads into OT.
  4. Open the OT/ICS network template, review the rules (default-deny) – then try the challenge where you build the boundary yourself.

▶ Open in the simulator

Lesson 4: The data diode and one-way flows

The diode: physics instead of rules

IT-PCENGFWHISTHMIPLCDIODEa firewall = software and rules

The firewall from lesson 2 is software: it decides by rules. And software can have a bug, someone can add a rule by mistake, the admin password can leak. For the most critical operations there is a harder caliber: the data diode. It is named after the electronic component that passes current one way only – and that is exactly what it does with network traffic. But it is not a rule in a config: it is a physical construction. Picture an optical fiber with only a transmitter (LED/laser) on one side and only a receiver on the other. Data physically flows left to right – and the reverse is impossible, just as you cannot speak into a loudspeaker and expect the radio to hear you. No misconfiguration, no stolen admin account, no zero-day flips that direction – physics cannot be hacked. Note the fundamental difference from a firewall: a firewall decides (‘this packet yes, that one no’) and can be wrong; the diode decides nothing – the other direction simply does not exist. The price is ruthlessness: not even a TCP acknowledgment passes back through the diode (that too is return traffic! – you know acknowledgments from the ISO/OSI and TCP/IP map course), so it needs special one-way protocols. Where it pays off and how it is wired is in the next module.

Step by step

  1. A firewall decides by rules – and software can have bugs, rules mistakes, passwords leaks.
  2. A data diode: only a transmitter on one side, only a receiver on the other. The reverse direction physically does not exist.
  3. Production data flows out through the diode. No config or stolen account flips the direction – physics cannot be hacked.
  4. The price of ruthlessness: not even a TCP acknowledgment passes back – the diode needs special one-way protocols.

Monitoring out, no path in

IT-PCENGFWHISTHMIPLCDIODEPLC → diode → historian (out only)

What good is a link you cannot answer through? Exactly one thing – and in OT it is golden: letting production data out without creating any path in. Recall the dilemma from lesson 2: production needs to share numbers (supervision, reporting, diagnostics), but every link toward OT is a risk. A firewall solves it with rules – a diode solves it absolutely. You see the wiring on the scene: the PLC sends values (temperatures, states, alarms) through the diode into the historian in the DMZ; from the historian IT reads them, the monitoring center, even a cloud. If an attacker took over the historian, the IT network, the whole internet – they cannot reach the PLC through the diode, because the inbound direction physically does not exist. Monitoring works, remote control from outside is impossible. Of course it costs something: (1) through a diode nothing can be controlled or fixed remotely – a command inward is also a ‘path inward’; a service intervention needs physical presence or a separately guarded channel (lesson 5 shows why that is sensitive). (2) One-way protocols are special and pricier – the sending side cannot know the data arrived, so it sends it repeatedly with checksums. That is why the diode does not replace the firewall everywhere – it is deployed where the risk of an inbound direction is unacceptable. Where exactly is the last module of this lesson.

Step by step

  1. The PLC sends values through the diode to the historian in the DMZ. IT and monitoring read them from there.
  2. Even if an attacker owned the historian, IT or the whole internet – the inbound direction through the diode physically does not exist.
  3. The price: nothing can be controlled or fixed remotely through the diode – a command in is also a path in.
  4. The diode does not replace the firewall everywhere – it goes where the risk of an inbound path is unacceptable.

Where the diode pays off

IT-PCENGFWHISTHMIPLCDIODEpower plants: diode by regulation

A data diode is expensive (tens of thousands of euros) and inconvenient – so where does it make sense? Where a breach of the control network would mean catastrophe, not just damage. The textbook example is power plants, especially nuclear: the reactor’s control system must send data to supervision and regulators, but the idea that anything from outside could send a command in is unacceptable – so one-way gateways there are often required by regulation itself. Likewise transmission-grid substations, water treatment plants, gas pipelines: critical infrastructure where the state prescribes how control networks may be connected. And uses beyond industry: security monitoring – logs from a sensitive network flow through a diode to a SOC (monitoring center), so analysts see everything, yet even their own compromised workstation cannot touch the sensitive network; or military systems where a classified network may only receive data. Back to earth: an ordinary cookie factory usually does not need a diode – a well-configured default-deny firewall (lesson 2) is proportionate defense for it. Risk analysis decides: what is the worst possible harm if the inbound direction failed? If the answer is ‘explosion, deaths, cities without power’ – you buy a diode. If ‘production stops for a week’ – a firewall and good rules suffice. In the simulator you can add a diode from the device palette and try how a topology behaves when a link works one way only.

Step by step

  1. Power plants (especially nuclear), substations, water treatment: a breach = catastrophe, one-way gateways often required by regulation.
  2. Beyond industry: logs flow to the SOC through a diode – analysts see everything, they cannot touch the sensitive network.
  3. An ordinary factory usually needs no diode – a default-deny firewall is proportionate. Risk analysis decides.
  4. In the simulator add a diode from the device palette and watch how the topology behaves with a one-way link.

▶ Open in the simulator

Lesson 5: Attacks on OT

Stuxnet: the attack that moved iron

IT-PCENGFWHISTHMIPLCDIODEUSB and a service laptop jump the air gap

The story that splits OT security into ‘before’ and ‘after’. Around 2010 Iran was enriching uranium at the underground Natanz plant – thousands of fast-spinning centrifuges driven by PLCs. The facility was disconnected from the internet (a so-called air gap), and yet malware got in – known today as Stuxnet. How? Via USB sticks and service technicians’ laptops – it beat the air gap not through the network but through people. Inside, Stuxnet showed why it is still the textbook case: it sought no data, it sought a specific PLC model with a specific centrifuge configuration. Once found, it began altering speeds: briefly accelerate past the safe limit, return to normal, repeat weeks later. And it covered its tracks brilliantly: it replayed recorded normal values to the control-room operators, so the HMI showed calm while the centrifuges were physically destroying themselves. The result: hundreds of wrecked centrifuges, the program delayed by years – software broke iron. Three lessons to take away: (1) an air gap is not absolute – a USB stick, a service laptop or a supplier jumps it; (2) an attacker may go after the physical process, not data; (3) if your HMI can lie to you, you need independent monitoring of what is really happening in the network and process (lesson 6). Stuxnet was a state operation with huge resources – but the techniques it demonstrated have been imitated by more ordinary attackers ever since.

Step by step

  1. Natanz was disconnected from the internet – Stuxnet got in via USB sticks and technicians’ laptops.
  2. Inside it sought a specific PLC driving centrifuges – and altered speeds: briefly past the limit, back, again weeks later.
  3. It replayed recorded normal values to operators – the control room saw calm while centrifuges wrecked themselves.
  4. Hundreds of wrecked centrifuges. Lessons: the air gap is not absolute, the target may be the physical process – and the HMI can lie.

Ransomware: production stops via IT

IT-PCENGFWHISTHMIPLCDIODEransomware encrypts IT

Stuxnet is the extreme – the more common scenario of recent years is more mundane: ransomware. And here comes an unexpected point: production often stops without the attacker ever entering the OT network. How? Recall what production depends on around OT: order planning, warehouses and shipping, recipes, invoicing – all of it runs in IT. When ransomware encrypts the IT network, the plant still has working PLCs and HMIs, but does not know what to make, from what, or where to ship it. And there is a second, even more direct reason: when the company fears the infection will spread across the boundary into OT, it shuts production down preventively itself. Exactly that happened in real cases: aluminum maker Norsk Hydro (2019) switched smelters to manual control, Colonial Pipeline (2021) stopped the largest US fuel pipeline – not because ransomware drove valves, but because IT was crippled and certainty was missing. Lessons for defense: (1) the IT/OT boundary from lesson 2 is also a firebreak – the cleaner and better audited, the better the chance production survives an IT incident; (2) OT must be able to run a while without IT (manual mode, local recipe copies) – that is a continuity-plan question; (3) backups of the IT systems production depends on are part of OT security even though they live in IT. Ransomware does not aim at valves – it aims at money. But it stops production all the same.

Step by step

  1. Ransomware encrypts the IT network: planning, warehouses, recipes, invoicing – everything production depends on.
  2. OT is untouched: PLCs and HMIs work. But the plant does not know what to make, from what, or where to ship it.
  3. And production is often shut down preventively for fear of spread (Norsk Hydro 2019, Colonial Pipeline 2021).
  4. Defense: a clean IT/OT boundary (a firebreak), OT able to run a while without IT, and backups of production’s IT systems.

The insider, USB and the service laptop

IT-PCENGFWHISTHMIPLCDIODEa USB stick bypasses the firewall

Segmentation from lesson 2 guards network paths. But paths into OT also exist that no firewall shows – people carry them. Path one: the USB stick. A technician needs to load a new program into the PLC or update the HMI – and the network is (rightly!) separated, so he carries it on a stick. That same stick was in his home computer yesterday… exactly how Stuxnet traveled. Path two: the service laptop. An external technician tours dozens of plants with one laptop, plugging it straight into OT networks – an ideal carrier. Path three: the insider – a disgruntled or bribed employee who has legitimate OT access; the most famous case: Maroochy Shire (Australia 2000), where a former contractor’s technician remotely released sewage into rivers and parks – dozens of interventions before he was caught. What to do? For sticks: ban on foreign media + a scanning station (kiosk) where every stick is checked for malware before entering the plant, or company ‘vetted’ sticks for OT only. For laptops: the vendor gets your vetted laptop, or their machine may only join a separated service network. For insiders: least privilege (a technician sees only his line), immediate access removal on departure, and logs of who accessed what and when – without them Maroochy took months to investigate. The common denominator: rules for people and devices matter in OT as much as rules on the firewall.

Step by step

  1. A USB stick reaches the HMI/PLC outside the network – no firewall ever sees it. Yesterday it was in a home computer…
  2. An external technician’s service laptop tours dozens of plants, plugging straight into OT – an ideal carrier.
  3. The insider has legal access: at Maroochy Shire (2000) a former technician remotely released sewage into rivers.
  4. Defense: a kiosk scans every stick, the vendor gets your laptop, least privilege and who/when/what logs.

Vendor remote access

IT-PCENGFWHISTHMIPLCDIODEa vendor’s always-on VPN to the PLC ⚠

The last big path inside is official and blessed by contract: vendor remote access. The line’s manufacturer needs to service it remotely – diagnostics, tuning, updates. Sounds reasonable – but think through what it means: a hole through all your carefully built boundaries, leading from the internet straight to the PLC. And often in the worst form: a permanently-on VPN, a shared ‘service’ account for all the vendor’s technicians, full access to the whole OT network, no record of what happened during the session. Why is that so dangerous? Compromise one vendor – and you hold keys to dozens of plants at once (exactly the reasoning behind supply-chain attacks). What does the safe version look like? (1) A jump host: the vendor never connects directly to the PLC but to a middleman in your DMZ, from which one proceeds (supervised) further – no direct internet→OT path. (2) Just-in-time access: the VPN is normally off; your operator enables it for an announced service window and disables it afterwards. (3) Personal accounts and session recording: you know which technician did what – remember Maroochy. (4) Least privilege: access only to the line the vendor services, not the whole OT network. Check the same at home in miniature: how many ‘temporary’ remote accesses (TeamViewer on the heating, the vendor cloud of your solar panels) do you keep permanently on?

Step by step

  1. The worst form: an always-on VPN, a shared account, full OT access, no record. A hole through every boundary.
  2. Compromise one vendor and you hold keys to dozens of plants – the supply-chain attack logic.
  3. The safe version: the vendor lands on a jump host in the DMZ, and only from there (supervised) onward. No direct internet→OT path.
  4. Plus just-in-time: the VPN goes on for announced service and off again. Personal accounts, session recording, least privilege.

▶ Open in the simulator

Lesson 6: OT defense and operations

Inventory: you can’t protect the unknown

IT-PCENGFWHISTHMIPLCDIODEwhat exactly is on the network?

OT defense starts with a question that sounds trivial yet few plants can answer in practice: what exactly do we have on the network? Industrial networks grew for decades: a line from one vendor, an extension from another, a ‘temporary’ link from 2009 that is still there. Nobody has a complete list. Yet it is the foundation of everything: you cannot protect what you do not know about. A firewall rule for a device missing from the list? Segmenting a network nobody mapped? Impossible. That is why step one of every OT security project is the asset inventory: what it is (PLC, HMI, sensor…), where it is (hall, cabinet), what firmware it runs, whom it talks to (which flows – recall the whitelist from lesson 3) and who is responsible for it. The last point hurts most: for a twenty-year-old line, often nobody knows who maintains it anymore. How to get the list? In IT you would run a scanner – in OT that can be dangerous (as the next module shows). So OT inventory is built mainly passively: by listening to network traffic (who talks to whom, over which protocol) and by tedious legwork – going through documentation, cabinets, labels. The reward: only on top of a complete list does everything else make sense – segmentation, rules, monitoring and the recovery plan.

Step by step

  1. The industrial network grew for decades – the ‘temporary’ link from 2009 is still there. Nobody has a complete list.
  2. You cannot protect what you do not know about: no rule for an unmapped device, no segmentation design.
  3. In OT the inventory is built passively: listening to traffic (who with whom, which protocol) + documentation and labels.
  4. The reward: only over a complete list do segmentation, the flow whitelist, monitoring and recovery planning make sense.

Passive monitoring: why you don’t scan

IT-PCENGFWHISTHMIPLCDIODEan active scan: a volley at everything ⚠

In IT, active scanning is routine: a tool walks the network, ‘knocks’ on every address’s ports and learns what runs where. Trying the same in OT is a rookie mistake that can stop production. Why? Recall lesson 1: a PLC is a twenty-year-old computer with minimal memory and a fragile network stack, built to talk to one HMI over a known protocol – not to face a volley of odd packets from a scanner. Real consequences from practice: a PLC freezes after a scan and the line stops; a sensor reboots mid-process; an old print server in the hall starts spewing paper. In IT the same scan would knock over nothing – in OT it is a gamble. You already know the fix from the previous module: passive monitoring. The switch is set to mirror traffic (a SPAN/mirror port – a copy of everything flowing through; covered in detail in The Switch in Depth course) and the analyzer just listens: it transmits nothing, so it can break nothing. What can listening reveal? Surprisingly much – and here it helps that the OT network is boring and predictable (lesson 3): monitoring learns the normal (the HMI talks to the PLC, the historian collects data) and shouts on a deviation: a new unknown device, a Modbus write from an address that never wrote, a connection to the internet from OT. Remember Stuxnet: the HMI lied, but the network traffic did not – independent passive monitoring is exactly the safety net Natanz lacked.

Step by step

  1. The IT habit: a scanner ‘knocks’ on all ports. In OT a gamble – the PLC’s fragile stack was not built for it.
  2. Real consequences: a PLC freezes, a sensor reboots mid-process. In OT you do not scan actively.
  3. Passive monitoring: the switch mirrors traffic (SPAN port), the analyzer only listens – transmits nothing, breaks nothing.
  4. OT is predictable → alert on deviation: a new device, an unusual Modbus write. The HMI can lie, traffic does not.

Zones, conduits and the recovery plan

IT-PCENGFWHISTHMIPLCDIODEzones: IT / DMZ / OT (IEC 62443)

Two last practical items for your OT toolkit. First: zones and conduits. The IEC 62443 standard (the international norm for industrial system security – it is enough to know it exists and this is its core) formalizes what you built intuitively in this course: the network is split into zones – groups of devices of equal sensitivity (OT line 1, OT line 2, DMZ, IT) – and between zones you define conduits: guarded connecting channels, each with a written list of allowed flows. Recognize it? That is exactly our preset: IT / DMZ / OT zones, conduits through the inter-firewall, a whitelist of 1433 and 502. In the simulator you can even draw the zones – the + Zone button on the canvas; do it, a visual boundary helps thinking. Second: backups and recovery. Even with perfect segmentation something will one day break – and OT recovery has a twist: you need to restore not just data but the PLC programs (the logic driving the machine) and the configurations of HMIs and network gear. Questions you must be able to answer in advance: Do we have a current copy of every PLC’s program? (After twenty years of tweaks, often the only copy lives in the PLC itself.) Can we load it back, and do we know how long that takes? Have we tried it as a drill? A recovery plan nobody ever tested is just paper. The module’s closing point: zones limit how far a problem spreads; backups decide how fast you recover from it.

Step by step

  1. Zones: device groups of equal sensitivity – IT, DMZ, OT. IEC 62443 formalizes what we built all along.
  2. Between zones run conduits: guarded channels, each with a flow whitelist (1433, 502). In the sim: the + Zone button.
  3. OT recovery: besides data also PLC programs and configs. After years of tweaks the only copy often lives in the PLC.
  4. Back up PLC programs and drill the recovery. Zones limit the spread; backups decide the speed of return.

Summary: the whole defense together

IT-PCENGFWHISTHMIPLCDIODEsegmentation: IT only to the historian

The course ends – let us assemble industrial network defense into one picture. Think differently: in OT availability > integrity > confidentiality; devices are old and unpatched, so you protect the network around them, not the devices themselves (lesson 1). Segment: Purdue levels, an IT/OT boundary with a default-deny firewall, an industrial DMZ with the historian as middleman – no rule ever leads from IT straight into OT (lesson 2). Do not trust the protocols: Modbus and friends have no authentication; whoever reaches port 502 is in control – the only real defense is that they never reach it (lesson 3). Where the risk is unacceptable, use physics: a data diode lets monitoring out and nothing leads in (lesson 4). Count on people: Stuxnet arrived on a stick, ransomware stops production through IT, the insider has legal access and a vendor VPN is a hole through every boundary – a media kiosk, a jump host, just-in-time access, logs (lesson 5). And operate: the inventory (you cannot protect the unknown), passive monitoring instead of scanning, zones and conduits, tested PLC program backups (lesson 6). Notice the common thread: almost none of this was new technology – the firewall, DMZ, whitelist and backups you know from earlier courses. OT security is largely discipline: familiar tools applied with respect for a world where a mistake does not crash an app but stops a plant. If you saved the ‘OT/ICS segmentation’ challenge for the end – now is the time.

Step by step

  1. Segment: an IT/OT boundary with default-deny, a DMZ with the historian as middleman. No rule leads from IT into OT.
  2. Do not trust protocols: Modbus has no authentication. Whoever reaches port 502 controls – so keep them from reaching it.
  3. Physics where risk is unacceptable (the diode) – and people: a media kiosk, a jump host, just-in-time, logs.
  4. And operate: inventory, passive monitoring, zones and conduits, tested backups. Congratulations – now the simulator challenge!

▶ Open in the simulator