Lorenzo Rinieri opens the industrial part of the course with a question — why talk about Industrial Control Systems? — and answers it with data and with two names. Cyber incidents continue to grow globally and in Italy; among the most affected victim categories in Italy are the government and public administration sectors, followed by the manufacturing sector.
The key point, stated in the slides, changes what "incident" means: when cyberattacks affect industrial operational environments, consequences may go beyond data and directly affect services, physical processes, and people safety.
Stuxnet was the first publicly reported malware specifically targeting industrial control systems. It combined multiple capabilities — zero-day exploits, a Windows rootkit, and network infection routines — and it proved that attackers could move from the IT network to manipulate industrial control environments. Together with Industroyer, it targeted OT environments: the systems, networks and programmable devices used to monitor and control industrial physical processes.
The course distils three lessons, and they structure everything that follows in chapters 9 to 11:
| Lesson | Meaning |
|---|---|
| 1. OT is a real attack surface | ICS devices and industrial processes can be targeted deliberately. |
| 2. Impact is operational, not only informational | The goal may be disruption, manipulation or unsafe process behaviour — not only data theft. |
| 3. Security must be architecture-aware | Because OT has unique peculiarities in performance, reliability and safety constraints, security must be designed around the industrial network architecture. |
Lesson 3 is the bridge to the rest of the course. If security must be architecture-aware, then the architecture — the segmentation, the paths, the visibility — is the security control. That is precisely what a programmable network lets you change, and why a P4 switch turns out to be a security device in chapters 10 and 11.
Modern Industrial Control Systems rely on two interconnected technological domains, and the one-line distinction in the slides is the one to memorise: IT manages information and data. OT controls operations.
| Information Technology (IT) | Operational Technology (OT) |
|---|---|
| Supports data processing, communication, applications and business services. | Monitors and controls industrial devices and physical processes. |
Many OT systems were not originally designed with cybersecurity in mind. OT environments often include legacy devices, proprietary technologies, limited visibility and strict real-time requirements. The consequence is stated sharply: a security control that is acceptable in IT may disrupt an industrial process in OT. Hence the governing principle:
In OT, security must protect the system without breaking the process. This single sentence explains most design choices in the industrial half of this course — why in-network encryption is attractive (chapter 10), why segmentation is preferred to endpoint agents, and why "just enable TLS everywhere" is not an available answer (section 10 below).
Traditionally IT and OT evolved as separate domains, and OT systems were designed for local control, reliability and continuity. Over time industrial environments became increasingly connected to enterprise systems, remote maintenance services, cloud platforms and analytics and monitoring tools. The evolution of industry is turning isolated OT systems into connected cyber-physical ecosystems — which creates new advantages and a larger attack surface.
The convergence has a name — Industry 4.0 = IT/OT convergence — and the slides place it in a sequence. The historical detail is examinable, so here it is compactly:
| Revolution | When | What defined it |
|---|---|---|
| Industry 1.0 — mechanization | Began in Britain in 1784, later Europe and the United States | Mechanization and coal as a new energy source; steam power transformed manufacturing and transportation; spinning machines, mechanized looms, the steam engine. Manufacturing moved from manual to mechanized production. |
| Industry 2.0 — mass production | 1870–1914 | Enabled by electricity, gas and oil; assembly lines and mass production; new industries — steel, chemicals, modern transportation; combustion engine, telephone, telegraph, car, airplane. Electrified mass production. |
| Industry 3.0 — automation | 1969 — the Digital Revolution or Information Age | Computers, electronics, programmable systems, automated control, later digital communication networks; the rise of the Internet accelerated communication, data exchange and information processing. |
| Industry 4.0 — smart systems | 2011, began in Germany | The cyber-physical transformation of manufacturing: integration of physical industrial systems with digital communication, data and intelligent control. This evolution drives the convergence between IT and OT. |
| Industry 5.0 — human-machine collaboration | and beyond | Complements Industry 4.0 rather than replacing it: it keeps digitalisation and automation but adds a broader focus on societal value, built around three pillars. |
Note the verb in the Industry 5.0 row: complements, not replaces. The course is careful about this because the security consequences of 4.0 (connectivity, convergence, a larger attack surface) do not go away in 5.0 — they are joined by human-centricity, resilience and sustainability. Chapter 10's research agenda is explicitly framed as "from Industry 4.0 to 5.0".
Industrial Control Systems are responsible for the operations of production plants and critical infrastructures such as nuclear plants and smart grids, and they are organised according to the Purdue Enterprise Reference Architecture — a layered way to separate industrial operations from business systems and external connectivity.
Three facts define the model:
The levels closest to production — 0, 1 and 2 — usually have the strictest availability and timing requirements, and the slides characterise each with a key point:
| Level | Examples | Key point |
|---|---|---|
| 0 — Physical process | Sensors, transmitters, drives, valves, motors; conveyor movement, temperature, pressure, flow, batch steps | This is the real-world process being measured or actuated. |
| 1 — Basic control | PLCs, RTUs, intelligent relays, embedded controllers; logic execution, interlocks, local control loops | Fast deterministic control happens here. |
| 2 — Supervisory control | HMI stations, SCADA servers, engineering workstations; alarm views, setpoint changes, recipe download, line supervision | Operators gain visibility and supervisory control here. |
Levels 0 to 2 mean increasing abstraction, but they are all still operational technology. Level 3 is the transition zone: site operations (MES, batch management, quality systems, patch staging, OT historians; production scheduling, work orders, asset context, reporting) coordinates manufacturing at site level without directly controlling the physics of the process. Level 3.5, the often-added Industrial DMZ, is a common cybersecurity pattern: jump hosts, remote access gateways, proxy services, replicated historians, antivirus and update relays — a buffer so that communications between OT and enterprise networks are tightly mediated rather than fully open.
Above it sits the IT world: level 4, enterprise business planning and logistics (ERP, supply chain planning, finance, HR, enterprise analytics; cross-site reporting, order management, procurement, inventory visibility), whose main concern is business optimization, not real-time machine control; and level 5, external networks and cloud-connected ecosystems (partner networks, remote vendors, cloud platforms, customer and supplier integrations; corporate internet access, B2B exchange, advanced enterprise data platforms), concerned with broader connectivity and data sharing outside the plant boundary.
A Programmable Logic Controller (PLC) is an industrial computer that can receive data through its inputs and send operating instructions through its outputs. ICS sensors (inputs) and actuators (outputs) are usually controlled by PLCs, and fundamentally a PLC's job is to control a physical system using its internal control logic. The slides give it the memorable role: PLCs bridge the gap between the physical and the cyber world.
The IEC 61131-3 standard defines five programming languages for the control program within a PLC — three graphical and two textual:
| # | Language | Kind |
|---|---|---|
| 1 | Structured Text | textual |
| 2 | Instruction List | textual — deprecated |
| 3 | Ladder Logic | graphical |
| 4 | Function Block Diagram | graphical |
| 5 | Sequential Function Chart | graphical |
The scan cycle is the periodic process that handles the execution of the PLC program, and it has exactly three phases before repeating:
The course points at real installations: research testbeds such as SWaT and a chemical plant, and the ICS the department actually has in Cesena — a Niryo Ned 2 robotic arm and a Fischertechnik factory model.
Modbus is a communication protocol developed by Modicon systems — in simple terms, a method for transmitting information over serial lines between electronic devices. The device requesting information is the Modbus Master; the devices supplying it are Modbus Slaves. In a standard Modbus network there is one Master and up to 247 Slaves, each with a unique slave address from 1 to 247. The master can also write information to the slaves — which, as section 8 explains, is where the security problem lives.
Modbus semantics revolve around four logical object types, independent of the physical device memory. The 2×2 structure — one bit or sixteen bits, read-only or read/write — is worth memorising as a grid:
Function codes tell what to access and whether to read or write. The eight codes in the slides:
| Function code | Action | Name |
|---|---|---|
| 01 (01 hex) | Read | Discrete Output Coils |
| 05 (05 hex) | Write single | Discrete Output Coil |
| 15 (0F hex) | Write multiple | Discrete Output Coils |
| 02 (02 hex) | Read | Discrete Input Contacts |
| 04 (04 hex) | Read | Analog Input Registers |
| 03 (03 hex) | Read | Analog Output Holding Registers |
| 06 (06 hex) | Write single | Analog Output Holding Register |
| 16 (10 hex) | Write multiple | Analog Output Holding Registers |
The final project challenges (chapter 11) are written almost entirely in terms of function codes: mirror the traffic related to function code 4, or to codes 1 and 2; count packets for codes 1 to 6; raise an alarm if code 4 exceeds 20 packets. Being fluent in this table — especially which codes read and which write — is directly examinable and directly needed to build the project.
There are three main versions of the Modbus protocols:
Serial port with binary data on the wire. Commonly used on RS-485 buses, where one master/client polls multiple slave/server devices. Addresses run from 1 to 247 decimal (0x01 to 0xF7), and address 0x00 is reserved for broadcast. Timing matters: silent intervals separate frames on the serial line. The encoding is compact and binary: device address + function code + data + CRC.
Serial port with ASCII data on the wire. The same protocol logic as RTU, encoded as readable characters instead of binary — easier to debug, less efficient on the wire.
TCP/IP encapsulation of the Modbus Protocol Data Unit (PDU) taken from Modbus/RTU. It is an application-level protocol that typically uses TCP port 502. Crucially there is no serial-line CRC in the application frame: transport reliability is handled by TCP and Ethernet mechanisms.
The Modbus TCP frame is prefixed by the MBAP header, whose four fields are exactly what a P4 parser must extract in chapters 10 and 11:
The Length field is the one that makes the P4 parsing exercise interesting. Because it gives the number of following bytes, the Modbus payload has variable length — and a P4 parser, which prefers fixed-size extractions, must compute the payload size from IPv4 Total Length, TCP Data Offset and the MBAP Length before it can extract it. That is precisely the five-step parsing pipeline described in chapter 11.
The slides organise this as three columns — what is inherently wrong, what you can do about it in practice, and what the modern option is.
| Inherent limitations | Practical mitigations | Modern option |
|---|---|---|
|
|
|
Read the middle column again: segment, mediate, make write paths explicit, monitor. Every one of those is a network control, not a device control — because the devices cannot be changed. This is the concrete reason why the answer to industrial security in this course is programmable networking rather than endpoint hardening.
OPC UA — Open Platform Communications Unified Architecture — is the modern counterpart to Modbus and a completely different kind of object. It is a platform-independent, service-oriented architecture for industrial communication, designed to provide interoperability between industrial devices, control systems, software applications and higher-level IT systems. It was released in 2006.
Two properties distinguish it sharply from Modbus: it is not only a transport protocol — it also defines an information model, so data can be described in a structured and semantically meaningful way — and it includes built-in support for security.
Its main characteristics:
The slides list six security properties with their mechanisms — this is a favourite exam table:
Asymmetric encryption for key exchange plus symmetric encryption for encrypting the exchanged messages. The classic hybrid: public-key cryptography to agree on a key, symmetric cryptography for the bulk data because it is far cheaper per byte.
Message signing with asymmetric keys during the key agreement phase, and with symmetric keys for all other messages. The same hybrid logic applied to authenticity rather than secrecy.
The amount of processing performed on a message before it is authenticated is minimized. This is a denial-of-service defence: an attacker should not be able to make the server do expensive work with unauthenticated traffic.
Application authentication using X.509 v3 certificates, plus user authentication by username and password or by certificate. Two distinct identities: which application is talking, and which human is behind it.
Server-specific. It can be coarse-grained — allowing or denying a client access to a server — or much more narrowly targeted to specific resources.
Logs of successful and unsuccessful connection attempts, configuration changes, system changes, user interactions and session rejection. Without this the other five properties cannot be audited.
Establishing a session requires a security handshake in which client and server authenticate themselves using their OPC UA certificates; these certificates are mutually exchanged and verified, and each device maintains a Trust List of certificates it trusts. Chapter 10 returns to this handshake, and to the very awkward practical problem of how the trust list gets populated in a real plant.
The section closes the loop on IT/OT convergence. Because industrial protocols originally intended to operate only in closed OT networks are now frequently exposed to broader and potentially hostile environments, secure variants matter more than ever. And yet, in the slides' own words: although secure variants of industrial communication protocols exist, mostly based on TLS, their adoption in practice remains marginal.
The number comes from Dahlmanns et al., Missed opportunities: measuring the untapped TLS support in the Industrial Internet of Things (AsiaCCS 2022):
Only 6.5% of 967,551 identified ICS deployments used TLS. The recurring obstacles the authors identify: legacy devices, TLS overhead, TLS computational cost, and the complexity of key and certificate management.
Those four obstacles are not excuses; they are engineering constraints. A device from 2004 cannot be given a TLS stack, a real-time control loop cannot absorb an unpredictable handshake delay, a microcontroller may not have the cycles for asymmetric crypto, and a plant with thousands of devices has no PKI to manage certificates with. This is the gap that chapters 10 and 11 attack — not by fixing the devices, but by putting the cryptography in the network, in a P4 switch, where the devices do not have to know about it.
Stuxnet was the first publicly reported malware specifically targeting ICS (combining zero-day exploits, a Windows rootkit and network infection routines) and it proved attackers could move from the IT network to manipulate industrial control environments. The three lessons: (1) OT is a real attack surface; (2) impact is operational, not only informational — disruption, manipulation or unsafe process behaviour; (3) security must be architecture-aware, designed around the industrial network architecture.
IT supports data processing, communication, applications and business services — it manages information and data. OT monitors and controls industrial devices and physical processes — it controls operations. OT cannot be secured like IT because of legacy devices, proprietary technologies, limited visibility and strict real-time requirements: a control acceptable in IT may disrupt an industrial process. In OT, security must protect the system without breaking the process.
1.0 Britain 1784: mechanization, coal, steam power, spinning machines and mechanized looms. 2.0 1870–1914: electricity, gas and oil, assembly lines, mass production, steel and chemicals, combustion engine, telephone, car, airplane. 3.0 1969: the Digital Revolution — computers, electronics, programmable systems, automated control, digital networks, the Internet. 4.0 2011, Germany: the cyber-physical transformation of manufacturing, driving IT/OT convergence. 5.0 complements 4.0, adding a focus on societal value.
By operational role, timing sensitivity and trust boundary; the lower the level, the closer to the physical process. Commands flow downward toward control devices; production data, alarms and KPIs flow upward toward operations and enterprise tools. It matters because it supports segmentation, clearer ownership, safer remote access and reduced blast radius.
0 physical process (sensors, valves, motors); 1 basic control (PLCs, RTUs — fast deterministic control); 2 supervisory control (HMI, SCADA, engineering workstations); 3 site operations (MES, historians, scheduling — no direct control of the physics); 3.5 industrial DMZ (jump hosts, remote access gateways, proxies, replicated historians); 4 enterprise IT (ERP, finance, logistics); 5 external and cloud-connected ecosystems. Levels 0–2 are the plant floor, 4–5 the enterprise.
An industrial computer that receives data through inputs and sends operating instructions through outputs, controlling a physical system with its internal control logic — it bridges the physical and cyber worlds. Scan cycle: (1) read the sensors and store their values in a local buffer; (2) execute the control logic; (3) update the output signals to the actuators from the buffer values. Then repeat.
Structured Text (textual), Instruction List (textual, deprecated), Ladder Logic, Function Block Diagram and Sequential Function Chart. The last three are the three graphical languages; the first two are the two textual ones.
One Master requests information; up to 247 Slaves supply it, each with a unique address 1–247; the master can also write. Objects: coils (1-bit, read/write — outputs and commands), discrete inputs (1-bit, read-only — contacts and status), input registers (16-bit, read-only — measurements) and holding registers (16-bit, read/write — setpoints and configuration).
01 — read Discrete Output Coils; 04 — read Analog Input Registers; 06 — write single Analog Output Holding Register. (Also: 05 write single coil, 15/0F write multiple coils, 02 read discrete input contacts, 03 read holding registers, 16/10 write multiple holding registers.)
RTU: serial with binary data, commonly on RS-485; one master polls many slaves; addresses 1–247 with 0x00 reserved for broadcast; timing matters (silent intervals separate frames); frame is device address + function code + data + CRC. TCP: application-level, typically port 502, TCP/IP encapsulation of the RTU PDU, with no serial-line CRC in the application frame because TCP and Ethernet handle reliability. Its MBAP header adds Transaction Identifier, Protocol Identifier, Length and Unit Identifier.
No built-in authentication or user identity in legacy Modbus; no native encryption in classic RTU or Modbus TCP; register writes can change process behaviour if access is uncontrolled; broadcast or flat networks enlarge the blast radius. The modern option is the Modbus Security specification, a TLS-based secure profile on dedicated registered port 802 — but many plants still rely on compensating controls because device support varies.
It defines an information model, so data is described in a structured, semantically meaningful way, and it has security built in. Released 2006; platform-independent and service-oriented; client-server and publish-subscribe; 10 service sets (Discovery, Secure Channel, Session, Node, View, Query, Attribute, Method, Subscription, Monitored Item). Security: confidentiality (asymmetric key exchange + symmetric message encryption), integrity (asymmetric signing during key agreement, symmetric afterwards), availability (minimise processing before authentication), authentication (X.509 v3 application certificates + user credentials), authorization (server-specific, coarse or fine-grained), accounting (logs of connections, configuration and system changes, user interactions, session rejections).
Only 6.5% of 967,551 identified ICS deployments used TLS, with four recurring obstacles: legacy devices, TLS overhead, TLS computational cost, and the complexity of key and certificate management. It matters because it rules out "just enable TLS" as a solution and motivates putting security in the network — an approach the programmable data plane makes possible.