IoT and ICS/SCADA Architecture Overview — The Glorious Mess Behind the Machines

"If cloud is the office bureaucracy of IT, OT is the factory foreman who yells at everything that moves — and actually means it."

You already know about shared responsibility, identity controls, and container/Kubernetes hardening from the Cloud Infrastructure arc — now we're diving into the physical side of the house. Think of this as moving from securing the HR department (cloud) to securing the power plant that keeps the coffee machine functioning (OT/ICS) — and the hundreds of tiny smart devices (IoT) that bring in the donuts.

What this section covers (and why it matters)

A clear, visual architecture of IoT devices vs ICS/SCADA systems
How their components fit together and why their priorities differ from cloud environments
Quick mappings to cloud security concepts you already know (shared responsibility, identity, segmentation, incident response)
Practical questions to ask when assessing an environment

If you liked tightening up containers and building guardrails in the cloud, congratulations: now you get to do similar things for devices that literally control the environment.

High-level architecture: Who talks to whom? (Spoiler: everything.)

The main players

Field devices / Sensors & Actuators (IoT edge): Temperature sensors, flow meters, valve actuators. Often small, single-board, firmware-limited. Purpose: measure and act.
PLCs (Programmable Logic Controllers) / RTUs (Remote Terminal Units): Real-time controllers running deterministic logic. These are the muscle of OT.
DCS (Distributed Control Systems): Clustered controllers used in continuous process industries (chemical, oil, etc.).
SCADA Servers & Historian: Central servers that collect telemetry, persist time-series process data, and provide supervisory control.
HMI (Human Machine Interface): Operator consoles and dashboards.
Engineering Workstations: Where control logic is developed and pushed to PLCs/RTUs.
Gateways & Protocol Converters: Bridges between OT networks and corporate/IT or cloud.
Cloud/Edge platforms: Increasingly present for analytics, remote monitoring, firmware management.

Communication flows

Field devices ↔ PLCs/RTUs (often local protocols)
PLCs ↔ SCADA/Historian/HMI (supervisory telemetry and commands)
Gateways ↔ Cloud/IT (analytics, remote ops, vendor access)

Real-time, deterministic traffic dominates inside the control loop; anything that adds jitter is enemy number one.

Table: IoT vs OT (ICS/SCADA) — Architectures and Security Priorities

Dimension	IoT (consumer/enterprise edge)	OT / ICS / SCADA (industrial control)
Primary goal	Data, convenience, telemetry	Safety, availability, process integrity
Lifecycle	Short — frequent updates	Long — years/decades, infrequent patches
Real-time needs	Often soft real-time	Hard/deterministic real-time
Security priority	Confidentiality and integrity	Availability and safety first
Protocols	MQTT, CoAP, HTTP/REST	Modbus, DNP3, OPC-UA, IEC 60870
Patchability	Over-the-air common, vendor-managed	Risky — may require scheduled downtime
Typical failure impact	Data loss, privacy	Physical damage, safety incidents

Protocols & Peculiarities (the attack surface)

Modbus/TCP — Ancient, plaintext, stateless read/write. Great for debugging, terrible for security.
DNP3 — Better features, often used in utilities. Some secure variants exist.
OPC-UA — Modern, supports encryption/auth; slowly winning hearts.
Proprietary serial protocols — Every vendor's special snowflake. Means you learn one system at a time.

Code block example: a tiny Modbus read (hex) so you know what lurks on the wire:

// Modbus TCP Read Holding Registers (pseudobytes)
Transaction ID: 0x0001
Protocol ID: 0x0000
Length: 0x0006
Unit ID: 0x01
Function: 0x03 (Read Holding Registers)
Start Addr: 0x0000
Quantity: 0x0002

Yes, that is human-readable enough for attackers and dumb enough to be intercepted and manipulated.

How cloud security concepts map to OT/IoT (so your brain doesn't explode)

Shared responsibility: In cloud you share with CSPs. In IoT/OT you share with device manufacturers, system integrators, and plant operators. Who owns firmware updates? Who maintains certificates? Ask early.
Identity controls: Kubernetes RBAC -> device identity & PKI. Use unique device identities (certs, TPMs). Don't treat IoT devices like anonymous guests.
Segmentation & Zero Trust: Microservice isolation becomes network microsegmentation, VLANs, and firewall rules for OT. Put DMZs/gateways between IT/cloud and OT. Assume east-west is lethal.
Incident Response & Forensics: Cloud forensics taught you logs & snapshots; in OT, logs may be sparse. Use historians, packet captures at gateways, and immutable backups of PLC logic. Test your playbooks in a simulated plant.
Hardening: Container images -> firmware hardening. Remove unused services, lock down debug ports (yes, JTAG), enforce secure boot.

Threats that actually matter in OT/IoT

Ransomware targeting HMIs / historians (encrypting data and disrupting operators)
Firmware tampering / supply chain compromise (malicious logic in PLCs) — TRITON and Industroyer were chilling previews
MITM and command injection on plain protocols (write to coils, flip valves)
VPN backdoors and remote vendor access abuse
False data injection — spoof sensors to make control logic behave dangerously

Ask yourself: what happens if a sensor lies? If the PLC gets a bad setpoint? This is not just data; it's motive power.

Practical assessment checklist (quick, actionable)

Inventory: Do you know every device and firmware version? (If not: stop and inventory.)
Topology: Where are the gateways? Is there an OT-IT DMZ? Where does vendor access land?
Protocols: Which plain-text protocols traverse networks? Can you isolate them?
Identities: Are devices uniquely identified? Are certs in use? Is there a PKI?
Patch strategy: How do you validate and roll out firmware safely?
Monitoring: Do you have network-based anomaly detection for OT? Are historians protected?
Incident response: Can you restore PLC logic? Are backups tested?

Lab ideas & next steps (aka nerdy homework)

Stand up a mini SCADA lab: a Modbus simulator, an open-source PLC emulator, and an HMI. Practice packet capture and injection.
Learn Modbus/DNP3/OPC-UA enough to recognize a legitimate command vs garbage.
Practice incident response: encrypt a historian (in a lab), perform recovery, and iterate the playbook.
Map your org's shared responsibilities with vendors for firmware updates and remote access.

Final words (TL;DR you fabulous chaos manager)

OT cares about safety and uptime, not fancy cryptography. Your job is to translate cybersecurity into terms operators care about: safety, availability, and production continuity.
Bring cloud lessons with you, but adapt them. Identity, segmentation, and forensics are still king — but implementation is different (long lifecycles, fragile updates, deterministic timing).

Security in OT/IoT is less about installing a patch and more about building a provable, auditable fortress around real-world consequences.

Key takeaways: inventory everything, assume devices will be compromised, segment ruthlessly, and practice incident response with physical-process awareness. Now go make some diagrams, spin up a lab, and remember: the valve you mess with might actually make a river of coffee flow into the server room. Handle with respect.

IoT and OT (Operational Technology) Hacking

Content