The ICS/OT Security Field Guide: Systems, Protocols, Threats, and Frameworks

Why OT security is its own discipline

Information technology protects data. Operational technology protects a *physical process*, so the priorities invert. In IT the classic order is confidentiality, integrity, availability. In OT it is closer to safety, availability, integrity, confidentiality: a chemical plant can survive a data leak, but not a runaway reaction. That single inversion explains almost every difference that follows, from why you cannot simply patch on Tuesday to why "just reboot it" is sometimes the most dangerous advice in the building.

This guide organises the ICS/OT landscape into five groups so you can hold the whole picture at once, which is exactly what the CISSP, GICSP, and our own ot_security exam expect of you.

1. Core systems: what you are actually defending

HMI (Human-Machine Interface): the operator's screen. Compromise it and you control what the humans *believe* is happening.

PLC (Programmable Logic Controller): the small ruggedised computer running the control logic. The crown jewels of the plant floor.

SCADA (Supervisory Control and Data Acquisition): the system that supervises many distributed sites and aggregates their data.

DCS (Distributed Control System): like SCADA but for a single large plant, with control distributed across many nodes.

RTU (Remote Terminal Unit) and sensors/actuators: the field devices that read the world and act on it.

EWS (Engineering Workstation): where PLC logic is written and downloaded, a prime target, because whoever owns the EWS can reprogram the process.

These are engineered for decades of uptime. A PLC installed in 2009 may still be running, unpatched, because the vendor no longer supports it and the process cannot stop for an upgrade. Longevity is a safety feature and a security liability at the same time.

2. Protocols: where the trust assumptions live

OT protocols were designed for closed, trusted networks, so most carry no authentication or encryption by default:

Modbus / Modbus TCP: simple, ubiquitous, and completely trusting. Any peer can issue a write.

DNP3: common in utilities; a secure-authentication variant exists but is often unused.

EtherNet/IP, PROFINET, BACnet: industrial and building-automation staples with the same trust-by-default posture.

OPC UA: the modern exception, designed with security in mind, but only as strong as its configuration.

The lesson: in OT you frequently cannot secure the *protocol*, so you secure the *network the protocol runs on*. That is why segmentation is the load-bearing control of the whole discipline.

3. Threats and attacks: the history that shaped the field

A handful of real incidents define OT threat modelling, and every serious exam references them:

Stuxnet (2010): sabotaged uranium centrifuges by altering PLC logic while feeding operators normal readings. It proved cyber can cause physical destruction.

Industroyer / CrashOverride (2016): purpose-built to speak grid protocols and trip substations; it caused a power outage in Ukraine.

TRITON / TRISIS (2017): targeted **safety instrumented systems (SIS)**, the last-line controllers that prevent disasters. Attacking safety systems is the red line of OT security.

Industroyer2 and PIPEDREAM/INCONTROLLER (2022): modular OT attack frameworks, a shift from bespoke tools to reusable ICS malware.

Alongside these sit the ordinary threats, ransomware reaching OT through flat networks, APTs, insider threats, and the internet-facing assets that show up in Shodan searches every day.

4. Defensive strategies: how you actually reduce risk

Segmentation and the Purdue Model: the reference architecture that layers the enterprise (Levels 4-5) above a DMZ, above supervisory control (Level 3), control (Levels 1-2), and the process (Level 0). Most OT security work is making these boundaries real.

Asset inventory: you cannot protect what you cannot see. In brownfield OT, building the inventory is often the first year of the programme.

Passive network monitoring: OT-aware IDS that baselines normal traffic without probing fragile devices.

Honeypots, tabletop exercises, and network segmentation testing to validate the above.

Safety-first patching: compensating controls when you cannot patch, tested change windows when you can.

5. Frameworks and governance: proving it to auditors and boards

IEC 62443: the dedicated ICS/OT standard, built around **zones and conduits** and **security levels (SL 1-4)**. If you learn one OT framework, learn this one.

NIST SP 800-82 Rev. 3: the U.S. government's OT security guide, mapping the NIST controls to industrial realities.

NERC CIP: mandatory (and enforceable with fines) for the North American bulk electric system.

ISA/IEC, MITRE ATT&CK for ICS, and newer regulation like the EU's NIS2 and Cyber Resilience Act round out the compliance picture.

How to study it

The trap with ICS/OT is treating it as a vocabulary test. It is really a *priorities* test: given a scenario, can you reason from safety and availability first, recognise which trust assumption is being abused, and pick the control that fits a system you cannot take offline? Our [ot_security practice bank](/certifications/ot_security) is built around that reasoning, and the [OT Security Lab](/labs/ot-security-lab) lets you work through realistic scenarios rather than memorise an alphabet soup of acronyms. Pair either with the [free domain summaries](/domain-summaries) to see how these topics are weighted on the exams that test them.