COMP 6660 · Enterprise Cybersecurity Critical Infrastructure Security

00 Introduction

Lesson 5.7 examined the device estate — mobile devices and the Internet of Things. This lesson examines the part of that estate where security failure carries the greatest consequence: the operational technology that runs critical infrastructure.

Critical infrastructure is the set of systems and assets so vital that their incapacity or destruction would have a debilitating effect on security, on the economy, on public health and safety, or on the effective functioning of society. It includes the electricity grid, water and wastewater systems, oil and gas pipelines, transportation networks, telecommunications, financial systems, healthcare, and emergency services. Each of these depends on industrial control systems — computers that sense and control physical processes.

Those control systems were not designed to be secure. They were designed to be safe, available, and deterministic — to keep a turbine spinning at the right speed, a valve in the right position, a patient's infusion pump delivering the right dose. They were designed for a world in which the control network was physically isolated from everything else, protocols had no authentication because everyone on the wire was trusted, and devices were expected to run unchanged for twenty years. That world no longer exists.

This lesson examines critical infrastructure security in detail. It establishes why the topic matters and what the consequence of failure actually is. It defines what counts as critical infrastructure and how nations designate it. It examines the defining differences between operational technology and information technology — differences that explain why conventional security practice frequently fails in this environment. It examines industrial control system architecture and components. It examines the cyber-physical threat landscape. It examines documented incidents and the lessons they establish. It examines the standards and regulatory frameworks that govern critical infrastructure security. It examines the controls that work in OT environments. It examines IT/OT convergence — the organisational and technical integration that has become the central governance challenge. It examines resilience and incident response where safety comes first. And it closes with the pitfalls that recur across critical infrastructure programmes.

The material here builds directly on Lesson 5.7 (mobile and IoT security) — operational technology is the constrained-device problem taken to its extreme — and on Lesson 3.7 (insider threats and supply chain security), which examined the supply-chain attack patterns that have defined several critical infrastructure incidents. It draws on the architecture reasoning of Unit 4 and the risk reasoning of Unit 3. It prepares for Module 3, where governance, risk management, compliance, incident response, and business continuity are examined in depth — all of which have specific and consequential application to critical infrastructure.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 5 outcome U5.3 (emerging infrastructure threats) and to Module 2 outcomes M2.9 and M2.10. See the Unit 5 learning outcomes page for the full mapping.

02 Why critical infrastructure security matters

Critical infrastructure security is distinguished from the rest of enterprise security by the consequence of failure. In a conventional enterprise, a security failure produces data loss, financial loss, and reputational damage. In critical infrastructure, a security failure can produce physical damage, environmental harm, injury, or loss of life — and can deprive a population of essential services.

The consequence of critical infrastructure security failures

Critical infrastructure failures span a range of consequence:

• Loss of essential service. Interruption of electricity, water, fuel supply, or communications to a population — with consequences that compound across every dependent service.
• Physical damage to equipment. Deliberate manipulation of control systems to damage equipment — turbines, centrifuges, transformers, and pipelines.
• Environmental release. Manipulation of chemical, water-treatment, or oil-and-gas systems producing release of hazardous material.
• Risk to life and safety. Compromise of medical devices, safety instrumented systems, or transport control — where security failure becomes a direct safety failure.
• Economic disruption. Interruption of production, logistics, or financial services — with effects extending well beyond the affected organisation.
• Erosion of public confidence. Loss of confidence in the reliability of essential services — a consequence that persists after service is restored.
• Geopolitical and strategic effect. Attacks on critical infrastructure as an instrument of state pressure — including pre-positioning for use in a future crisis.

03 What counts as critical infrastructure

Critical infrastructure is defined by consequence rather than by technology. Different jurisdictions enumerate it differently, but the sectors and the criteria are broadly consistent.

The sectors

National designations

Different jurisdictions approach designation differently:

• Canada. Public Safety Canada identifies ten critical infrastructure sectors and maintains a National Critical Infrastructure Resilience Strategy, with sector-specific networks and regulators including the Canadian Energy Regulator, the Canadian Nuclear Safety Commission, and provincial regulators for electricity and water.
• United States. CISA identifies sixteen critical infrastructure sectors, with sector-specific agencies, and designates individual entities as critical infrastructure. Executive and legislative action has extended mandatory incident reporting and minimum security requirements to specified sectors.
• European Union. The NIS2 Directive establishes cybersecurity risk-management and reporting obligations across essential and important entities in a defined set of sectors, and the CER Directive addresses the resilience of critical entities.
• United Kingdom. The Network and Information Systems Regulations and the Cyber Assessment Framework govern operators of essential services, with sector regulators overseeing compliance.
• Australia. The Security of Critical Infrastructure Act imposes obligations on designated critical infrastructure assets, including mandatory reporting and cyber security requirements.

Criteria for designation

Designation generally turns on one or more of the following:

• Essentiality. The service is essential to the functioning of society or the economy.
• Substitutability. There is no readily available alternative source of the service.
• Concentration. The service is provided by a small number of entities — so failure of one produces a large effect.
• Interdependency. The service is depended upon by other critical sectors.
• Consequence of failure. Failure produces significant harm to health, safety, security, the economy, or society.

Ownership and the public–private problem

The majority of critical infrastructure is privately owned and operated. In Canada, the United States, the United Kingdom, and much of Europe, essential services are delivered by private companies, regulated by public bodies. This creates a structural problem for critical infrastructure security:

• The consequence is public; the asset is private. The harm from failure falls on the population, but the investment decision sits with a private entity and its shareholders.
• The security objective differs. A private operator optimises for commercial return and regulatory compliance; the public interest requires resilience against capable adversaries.
• Intelligence asymmetry. The state frequently knows more about the threat than the operator does — requiring information sharing mechanisms, which are complicated by classification and by commercial sensitivity.
• Fragmented accountability. Operational responsibility sits with the operator; regulatory responsibility may sit with a sector regulator; national security responsibility sits with government. Coordination across all three is frequently weak.
• Regulation as the instrument. Because market incentives do not align, regulation — minimum requirements, mandatory reporting, and audit — is the principal mechanism through which public interest in critical infrastructure security is pursued.

04 Operational technology versus information technology

The single most important concept in critical infrastructure security is that operational technology (OT) is not information technology (IT). The two have different purposes, different priorities, different constraints, and different lifecycles — and security practice that ignores this distinction fails.

Definitions

• Information technology (IT). Systems that process, store, and transmit data — servers, workstations, applications, databases, networks. The subject of the preceding lessons in this unit.
• Operational technology (OT). Systems that monitor and control physical processes — industrial control systems, SCADA, distributed control systems, programmable logic controllers, and safety instrumented systems.
• Industrial control system (ICS). The general term for the collection of control components and networks that operate an industrial process. OT and ICS are frequently used interchangeably, with ICS referring more specifically to the control technology itself.
• Cyber-physical system. A system in which computation and physical processes are tightly integrated — the broader category that includes ICS, medical devices, autonomous vehicles, and robotics.

The defining differences

Why conventional security practice fails in OT

The differences above explain why standard IT security practice is frequently inapplicable:

• Vulnerability scanning can halt production. Active scanning sends unexpected packets to controllers that may be fragile — a scan that would be routine in IT can cause a PLC to fault and stop a process.
• Patching is not always possible. A controller running an unsupported operating system cannot be patched without vendor validation, engineering review, and a production outage — frequently with a rollback plan and a scheduled window months away.
• Endpoint agents cannot be deployed. Controllers do not support them, and their resource constraints would be exceeded if they did.
• Network controls can break control traffic. A firewall or IPS that inspects and blocks traffic can disrupt a proprietary protocol that the device expects to be transparent — producing an outage for security reasons, which is precisely the wrong trade.
• Identity controls do not map. Controllers do not support individual authentication, and processes frequently require shared service accounts — so least privilege and MFA cannot be applied at the device.
• Confidentiality-first reasoning is wrong. Encrypting control traffic may add latency that the control loop cannot tolerate — and the confidentiality of a valve position is not the concern.
• The safety case governs. Any change to an OT system must be assessed against the safety case and the regulatory approvals that support it. Security changes are not exempt.

05 ICS architecture and components

Industrial control systems have a characteristic architecture, conventionally described through the Purdue Enterprise Reference Architecture — a layered model that separates the physical process from the enterprise network. Understanding this model is necessary because the layers define where security controls belong and where the trust boundaries are.

The Purdue model

The model is a reference, not a mandate. Modern architectures flatten, virtualise, and cloud-extend the layers. But the underlying principle endures: the process must be protected from the enterprise, not only the enterprise from the process. The industrial DMZ exists because traffic must cross between IT and OT, and because the crossing point must be controlled and observable.

ICS components

ICS protocols

Industrial protocols were designed for reliability and simplicity, in a world where the network was trusted:

• Modbus. A simple, widely used protocol with no authentication, no encryption, and no integrity checking. Anyone on the network can read and write registers.
• DNP3. Widely used in utilities, with a secure authentication option (DNP3-SA) that is frequently not deployed.
• Profinet and EtherNet/IP. Industrial Ethernet protocols for manufacturing — providing deterministic communication without inherent security.
• IEC 61850. The substation automation standard — defining both communication and data models, with security provisions (IEC 62351) that are not universally implemented.
• OPC UA. A modern industrial interoperability standard with built-in security — authentication, encryption, and integrity — increasingly used as a secure intermediary between modern and legacy systems.
• BACnet. Building automation protocol — used in HVAC, lighting, and access control. Examined in Lesson 5.7 as part of the building systems estate.
• Proprietary protocols. Vendor-specific protocols used by DCS platforms — frequently undocumented, unanalysed, and uninspectable by security tooling.

Trust boundaries

The Purdue model defines where trust boundaries exist — and therefore where security controls belong:

• Between the process and the control layer. Physical access to controllers and field devices — a boundary protected primarily by physical security and by locked cabinets.
• Between the control layer and the supervisory layer. The boundary between controllers and HMI/SCADA — frequently a flat network, which is the primary architectural weakness in many installations.
• Between operations management and the industrial DMZ. The boundary where OT data is replicated for IT consumption — the correct place for controlled data flow.
• Between the industrial DMZ and enterprise IT. The boundary where IT and OT meet — the highest-value control point, and frequently the weakest in practice.
• Between the enterprise and the outside world. Vendor remote access, cloud services, and third-party connections — increasingly the most common path into OT environments.

06 The cyber-physical threat landscape

The threat to critical infrastructure differs from the general enterprise threat landscape. The adversaries are more capable, the objectives are more strategic, and the consequence of success is greater.

Threat actors

Attack patterns specific to OT

• Reconnaissance of exposed industrial systems. Search engines and scanning services index internet-exposed HMIs, SCADA interfaces, and industrial devices — providing adversaries with target lists.
• Initial access through IT. The most common path into OT is through the enterprise — phishing, exploitation of internet-facing services, or compromise of a vendor — followed by lateral movement into the OT network.
• Engineering workstation compromise. Taking control of the workstation that programs controllers — permitting modification of control logic, which is the objective of the most consequential OT attacks.
• Exploitation of vendor remote access. Persistent vendor connections for support — frequently with shared credentials, no MFA, and no monitoring.
• Targeting of safety systems. Attempting to disable or manipulate the safety instrumented system so that the process cannot be brought to a safe state — demonstrated in the Triton attack.
• Manipulation of process parameters. Gradual or deliberate changes to setpoints, limits, or control logic — producing equipment damage or unsafe conditions without necessarily triggering alarms.
• Denial of view. Impairing the operator's ability to see the process — manipulating HMI displays or historian data so that operators are unaware of what is happening.
• Ransomware in OT. Encrypting engineering workstations, historians, and management systems — halting operations even where the controllers themselves continue to run.
• Living off the land. Using legitimate engineering tools and protocols — vendor software, remote access tools — to blend into normal operational activity.

Why OT is attractive to adversaries

• High consequence. The effect of success is disproportionate to the effort — a small intrusion can produce a national-scale consequence.
• Low security maturity. OT environments frequently lack the inventory, monitoring, identity controls, and patching that IT environments have had for two decades.
• Poor visibility. Compromise in OT frequently goes undetected for extended periods — the record for nation-state pre-positioning is measured in years.
• Strategic value. Pre-positioning in an adversary's critical infrastructure provides leverage in a crisis — independent of whether the capability is ever used.
• Constrained response. The operator cannot simply shut down the process, cannot scan the network, and cannot patch quickly — so the defender's options are narrower than the attacker's.

07 Documented incidents and lessons

Critical infrastructure security is informed by a body of documented incidents. Each established a capability, a technique, or a defensive lesson that remains relevant.

Incidents that defined the field

Lessons that recur

• IT compromise becomes OT disruption. The most frequent path to operational disruption is through enterprise IT — not through direct attack on control systems. IT/OT segmentation is therefore a critical infrastructure control, not just an IT control.
• Remote access is the recurring vector. Vendor connections, remote administration interfaces, and remote desktop are present in the majority of documented OT intrusions.
• Small operators are targets. Municipal utilities, small water districts, and regional providers have the same consequence of failure as large operators, with a fraction of the capability — and are frequently the weakest link in a sector.
• Safety systems must be independent. Triton demonstrated the necessity of genuine architectural independence between the control system and the safety system, not merely procedural separation.
• Visibility is the first requirement. Every post-incident review finds the same thing: the operator did not know what was on the OT network, what was communicating, or what had changed. Asset inventory and network monitoring are the foundation of every other control.
• Manual fallback saves operations. Operators who could fall back to manual operation restored service faster than those who could not. Resilience is built from redundancy and manual capability, not from prevention alone.
• Recovery takes longer than expected. Restoring an OT environment is not like restoring a file server. It requires validated configurations, tested backups, physical inspection, and a slow, careful restart of the process — frequently with safety and regulatory oversight.
• Coordination is essential. Incidents involve operations, engineering, IT, security, executive leadership, regulators, and frequently national authorities. Organisations that had rehearsed the coordination responded materially better.

08 Standards and regulatory frameworks

Critical infrastructure security is more heavily standardised and regulated than general enterprise security. The frameworks below define what operators are expected to do and, frequently, what they are legally required to do.

Principal standards

IEC 62443 — zones and conduits

IEC 62443 provides the model that underpins most OT security architecture. It is worth understanding in detail:

• Zones. A grouping of assets that share security requirements — because they perform a similar function, are at a similar level of the architecture, or have a similar consequence of compromise. Each zone has a target security level.
• Conduits. A communication path between two zones — the controlled, secured, and monitored connection through which traffic may pass.
• Security levels (SL 1–4). Defined levels of protection against increasing adversary capability — from casual or unintentional violation (SL 1) through to a state-sponsored adversary with extended resources (SL 4).
• Foundational requirements. Seven categories — identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability.
• Application across roles. The standard defines requirements for asset owners, for system integrators, and for product suppliers — making it a lifecycle framework, not just a technical one.

Regulation and its consequences

Regulatory frameworks change the character of critical infrastructure security practice:

• Mandatory rather than voluntary. Controls that are optional in general enterprise security are legally required in regulated sectors — with penalties for non-compliance.
• Auditable. Compliance must be demonstrable through evidence — documentation, records, and audit. This drives formality that is unusual in IT security practice.
• Mandatory reporting. Incidents must be reported to regulators and frequently to national authorities within defined timeframes — changing the incident response sequence.
• Supply chain obligations. Recent regulation extends obligations to the operator's suppliers — requiring the operator to assess and manage the security of vendors, contractors, and service providers.
• Management accountability. Several regimes place personal accountability on named executives — shifting security from a technical function to a governance obligation.
• Compliance is not security. A recurring failure is treating compliance as the objective — producing documentation that satisfies an audit while leaving operational risk unaddressed. The frameworks are a floor, not a ceiling.

09 OT security controls

OT security controls are selected against the OT priority ordering — safety, then availability, then integrity, then confidentiality — and against the constraint that the process cannot be disrupted. Controls that cannot be applied safely are replaced by compensating controls.

Architecture and network controls

Access and identity controls

• Remote access through controlled paths only. All remote access — vendor, employee, and third-party — through a dedicated jump host in the industrial DMZ, with multi-factor authentication, session recording, and time-limited access.
• Vendor access management. Vendor connections enabled on request, disabled by default, with named individual accounts rather than shared vendor accounts, and with all activity logged.
• Remove direct internet exposure. Industrial systems should not be reachable from the internet — including HMIs, SCADA interfaces, engineering software, and remote management interfaces. Internet-wide scanning finds them continuously.
• Privileged access management. Where the platform permits, vault engineering credentials, control who can use them, and record sessions. Where it does not, use physical controls — locked cabinets, controlled workstations, and supervised access.
• Physical access control. Cabinets, control rooms, and substations physically secured — because physical access to a controller is equivalent to administrative access.
• Removable media control. Strict control of USB and removable media — the vector that carried Stuxnet across an air gap. Where media must be used, use dedicated, scanned, and controlled media.

Visibility and monitoring controls

• Asset inventory. A complete, maintained inventory of OT assets — controllers, workstations, network devices, and software versions. The foundation of every other OT control.
• Passive network monitoring. Monitoring through network TAPs or SPAN ports — observing OT traffic without generating packets. This is the safe way to gain visibility in OT, because active scanning can disrupt fragile controllers.
• OT-specific anomaly detection. Baselines of normal OT communication — which devices talk to which, using which protocols, at what times — with deviations flagged. Detects both external intrusion and insider activity.
• Engineering workstation monitoring. Specific monitoring of engineering workstations — the systems from which control logic can be changed — because compromise there is the most consequential.
• Log collection from OT devices that support it. Where controllers, HMIs, and switches can produce logs, collect them — forwarded through the industrial DMZ to the enterprise SIEM.
• Safety system monitoring. Specific monitoring of safety instrumented systems — any change to safety logic, any communication with safety systems from unexpected sources, and any attempt to place a safety system in bypass or override.

Vulnerability and lifecycle controls

• Passive vulnerability identification. Determining vulnerable components from inventory, firmware versions, and vendor advisories — rather than by scanning.
• Risk-based patching. Patching the highest-consequence vulnerabilities first, in scheduled maintenance windows, with vendor validation, engineering review, a tested rollback plan, and safety sign-off.
• Compensating controls where patching is impossible. Where a vulnerability cannot be patched, compensate: segment the device, restrict its communications, monitor it specifically, and document the accepted risk with a defined review date.
• Configuration management and baselines. Defined, version-controlled configurations for controllers and workstations — with monitoring for unauthorised change.
• Backup and recovery. Tested backups of control logic, configuration, and engineering project files — stored offline where possible, because ransomware in OT frequently targets the ability to recover.
• Lifecycle planning. A defined plan for replacing end-of-support components — the only real remediation for a device that cannot be patched.

Supply chain and procurement controls

• Vendor security requirements. Contractual security requirements for OT vendors — vulnerability disclosure, patch availability, secure development, and support commitments across the intended lifecycle.
• Component provenance. Verification that hardware and firmware are genuine — reducing the risk of counterfeit or tampered components.
• Third-party access governance. Contractual and technical control of vendor remote access — with defined scope, duration, and monitoring.
• Integrator assurance. Assessment of the system integrators who design, build, and maintain OT environments — they frequently hold deep access and significant influence over security posture.

Applying controls where capability is limited

Not every operator has the resources of a large utility. The following sequence prioritises controls that produce the greatest risk reduction for the least operational risk:

1. Remove internet exposure. Eliminate direct internet-reachable industrial systems — a high-value, low-risk action.
2. Build the asset inventory. Discover and record what is on the OT network, using passive methods.
3. Segment OT from IT. Establish and enforce the boundary, however simple.
4. Control remote access. Consolidate remote access through a single controlled path with MFA and logging.
5. Deploy passive monitoring. Gain visibility into OT traffic and establish baselines.
6. Eliminate default and shared credentials. Change defaults, remove unnecessary accounts, and manage shared credentials deliberately.
7. Protect backups. Ensure control logic and configurations can be restored, offline and tested.
8. Address the highest-consequence vulnerabilities. Compensate or patch, prioritised by consequence rather than by severity score.

10 IT and OT convergence

Operational technology and information technology have converged — technically, organisationally, and commercially. IT/OT convergence is the integration of previously separate technology environments, and it is both a source of operational benefit and the central governance challenge in critical infrastructure security.

Drivers of convergence

• Operational data demands. Business and operational analytics need process data — production, quality, energy consumption, equipment condition — which requires data to flow from OT to IT and to the cloud.
• Remote operations. Remote monitoring, remote diagnostics, and centralised operations centres require connectivity to OT environments.
• Vendor support models. Vendors require remote access for diagnostics, updates, and warranty service — a persistent and frequently uncontrolled connection.
• Standardisation on IT technology. Modern control systems increasingly run on standard operating systems, use IP networking, and expose web interfaces — bringing IT security problems into OT.
• Industrial IoT. Sensors and edge platforms that communicate through cloud services — extending the OT estate into the cloud and into the device estate examined in Lesson 5.7.
• Cost and skills. Consolidating on enterprise platforms, tools, and teams reduces cost — and reduces the separation that previously provided some protection.

Why convergence is a governance problem

Convergence brings two organisations with different priorities, cultures, and accountabilities into contact:

Governance models for convergence

• Clear ownership with defined interfaces. OT remains owned by engineering; security is owned by a function with authority across both; the interface between them is defined — who decides, who approves, and who is accountable for what.
• Joint security governance. A forum where IT security, OT engineering, and operations leadership jointly own OT security policy and risk acceptance — because risk acceptance in OT is an operational decision.
• Shared standards, differentiated controls. A single security standard for the organisation, with an explicit OT annexe that defines how each requirement is met in OT — or why it is met by a compensating control.
• Embedded security expertise. Security capability inside the OT organisation, or OT expertise inside the security team — either works, but a security team that does not understand the process will make unsafe recommendations.
• Integrated incident response. A single incident response capability with OT-specific playbooks — rather than separate IT and OT response functions that do not coordinate.
• Combined monitoring. OT telemetry flowing into the enterprise SOC, with OT-aware detection rules and analysts who can interpret them — so that an IT-visible intrusion with OT implications is recognised as such.

Architectural implications

• The boundary must be deliberate. Every connection between IT and OT should be known, documented, and controlled — and most should be removed.
• Data flows out; control does not flow in. The architecture should permit operational data to reach IT and the cloud while preventing anything from reaching back into the control layer. Unidirectional gateways implement this architecturally.
• Identity must span both. Where OT systems support identity, they should integrate with enterprise identity — and where they do not, the surrounding infrastructure should enforce it.
• Convergence should not flatten the architecture. The benefit of convergence is data and management integration — not the removal of the boundary that protects the process.

11 Resilience and incident response

In critical infrastructure, incident response begins with safety and availability. The objective is not to preserve evidence or to contain the adversary at all costs — it is to keep the process safe, to restore service, and to protect people. Everything else is secondary.

Resilience as the primary objective

Because prevention cannot be guaranteed, critical infrastructure security invests heavily in resilience — the ability to continue operating, or to restore operations quickly, despite a security failure:

• Redundancy. Duplicate control systems, duplicate communications paths, and duplicate equipment — so that loss of one component does not stop the process.
• Manual fallback. The ability to operate the process manually or locally — the capability that restored service fastest in several documented incidents.
• Segmented operations. The ability to operate parts of the process independently — so that a compromise affecting one area does not halt everything.
• Offline backups of control logic. Control logic, configuration, and engineering project files stored offline and tested — because the ability to rebuild is the ability to recover.
• Spare equipment. Replacement controllers and workstations held in reserve — because recovery frequently requires rebuilding rather than cleaning.
• Rehearsed procedures. Response procedures exercised with operations, engineering, and leadership — including the decision to shut down, which is frequently the hardest decision to make.

OT incident response principles

Preparing the response capability

• OT-specific playbooks. Response procedures written for the specific process — naming the assets, the safe states, the manual fallback procedures, and the decision authorities.
• Tabletop exercises with operations. Exercising the response with the people who run the process — not only with the security team — including the shutdown decision.
• Restoration drills. Rebuilding a controller from backup, on a bench, on a defined schedule — proving the recovery capability exists before it is needed.
• Pre-arranged external support. Retained incident response capability with OT experience, vendor contacts recorded, and forensic tooling that can operate passively.
• Defined authority. Documented authority to isolate segments, to disable remote access, and to recommend shutdown — so that decisions are not made for the first time during an incident.
• Regulatory relationships. Established contacts with sector regulators and national authorities before an incident — because notification obligations run on short timelines.
• Post-incident improvement. Findings fed into architecture, into procurement, into monitoring coverage, and into the risk register.

12 Common pitfalls

Critical infrastructure security programmes fail in predictable ways. Recognising the pitfalls accelerates improvement.

Pitfall 1 — Applying IT controls directly to OT

Deploying endpoint agents, active vulnerability scanning, aggressive patching, and inline inspection to OT systems — without understanding the operational consequence, and frequently causing the outage the controls were intended to prevent.

Mitigation: Adapt controls to OT. Use passive monitoring instead of scanning, compensating controls where patching is impossible, and vendor-aware firewalls rather than generic inspection.

Pitfall 2 — Assuming the air gap still exists

Treating the OT network as isolated because it is supposed to be — without verifying that remote access, wireless, vendor connections, and IT integration have not created paths across it.

Mitigation: Verify the boundary technically — map every path between OT and any other network, and confirm that each is intended and controlled.

Pitfall 3 — No asset inventory

Operating an OT network without a maintained inventory of devices, firmware versions, and communication relationships — making every other control impossible.

Mitigation: Build the inventory through passive network monitoring and physical survey. Maintain it continuously.

Pitfall 4 — Uncontrolled vendor remote access

Persistent, shared, unmonitored vendor connections into OT environments — the most common intrusion vector in documented incidents.

Mitigation: Consolidate remote access through a controlled jump host with MFA, named accounts, session recording, and access enabled only when required.

Pitfall 5 — Flat OT networks

A single, flat network spanning controllers, HMIs, engineering workstations, and safety systems — so that compromise of any component provides access to all of them.

Mitigation: Implement zones and conduits. Separate safety systems architecturally. Segment by function and by consequence.

Pitfall 6 — Safety systems not architecturally independent

Safety instrumented systems sharing network, hardware, or engineering access with the control system — so that control-system compromise can disable safety functions.

Mitigation: Establish genuine independence — separate hardware, separate network, separate engineering access, and monitoring for any communication with safety systems.

Pitfall 7 — No monitoring in OT

Operating OT environments with no network visibility — so that intrusions, lateral movement, and control-logic modification are undetected for months or years.

Mitigation: Deploy passive network monitoring, establish behavioural baselines, and feed OT telemetry into the SOC.

Pitfall 8 — Untested backups and recovery

Assuming recovery capability exists without ever rebuilding a controller, restoring a historian, or exercising the restart procedure.

Mitigation: Store control logic and configuration offline. Rebuild on a bench on a defined schedule. Exercise the restart procedure with operations.

Pitfall 9 — Compliance treated as security

Optimising for the audit rather than for the risk — producing documentation that satisfies the regulator while leaving operational exposure unaddressed.

Mitigation: Treat compliance as a floor. Maintain a risk register that reflects operational reality, and report against it alongside regulatory compliance.

Pitfall 10 — No governance across IT and OT

Separate IT and OT security functions with no shared governance, no combined monitoring, and no coordinated response — leaving the boundary between them unowned.

Mitigation: Establish joint governance, combined monitoring, an integrated response capability, and defined accountability for the IT/OT boundary.

Pitfall 11 — Ignoring the small operator problem

Sector-level programmes that focus on large operators while municipal utilities, small water districts, and regional providers remain without the capability to implement basic controls.

Mitigation: Provide shared services, sector-level guidance and tooling, managed security services, and proportionate regulation. Prioritise removal of internet exposure and basic segmentation.

Pitfall 12 — Response plans that assume IT incident response

Incident response plans written for IT — with containment and evidence preservation as the priority — applied to an environment where safety and continuity come first.

Mitigation: Write OT-specific playbooks. Exercise them with operations. Define shutdown authority. Rehearse the coordination with regulators and vendors.

13 Key concepts

The terms below are used throughout Unit 5. Capture them in your own words as you work through the lesson.

Critical infrastructure

Systems and assets so vital that their incapacity or destruction would have a debilitating effect on security, the economy, public health and safety, or the effective functioning of society.

Operational technology (OT)

Systems that monitor and control physical processes — industrial control systems, SCADA, distributed control systems, PLCs, and safety instrumented systems.

Industrial control system (ICS)

The collection of control components and networks that operate an industrial process. OT and ICS are frequently used interchangeably.

Cyber-physical system

A system in which computation and physical processes are tightly integrated — the broader category including ICS, medical devices, autonomous vehicles, and robotics.

Purdue model

The layered reference architecture for industrial control systems — separating the physical process (Level 0) from enterprise IT (Level 4) and the cloud (Level 5), with an industrial DMZ at Level 3.5.

PLC (Programmable Logic Controller)

A ruggedised computer that executes control logic and operates equipment. Frequently without authentication, logging, or encryption.

RTU (Remote Terminal Unit)

A control device similar to a PLC but deployed in remote, unattended locations — substations, pipelines, pumping stations.

IED (Intelligent Electronic Device)

A protection and control device in electrical networks — relays, meters, and controllers governed by IEC 61850.

HMI (Human–Machine Interface)

The operator's interface to the process — frequently a general-purpose Windows workstation, and a common initial foothold.

SCADA

Supervisory control and data acquisition — the system that gathers telemetry and issues supervisory commands across a wide geographic area.

DCS (Distributed Control System)

An integrated, vendor-specific control system for continuous processes — refining, chemical production, and power generation.

Safety Instrumented System (SIS)

An independent system that brings the process to a safe state when conditions exceed limits. Must remain architecturally independent of the control system.

Historian

A time-series database recording process data — containing detailed operational intelligence about production and equipment performance.

Engineering workstation

The workstation used to program and configure controllers. A high-value target because compromise permits modification of control logic.

Industrial DMZ

A controlled boundary layer between OT and IT — containing replica servers, patch repositories, jump hosts, and file transfer services.

Zones and conduits

The IEC 62443 architectural model — grouping assets by security requirement into zones, and controlling communication between them through conduits.

Security level (SL)

IEC 62443's defined levels of protection against increasing adversary capability — SL 1 (casual violation) through SL 4 (state-sponsored adversary with extended resources).

Unidirectional gateway / data diode

Hardware that permits data to flow in one direction only — used where OT data must be published without permitting any inbound path.

Passive monitoring

Observing network traffic through TAPs or SPAN ports without generating packets — the safe way to gain visibility in OT environments.

Compensating control

An alternative control applied where the primary control cannot be implemented — typically because patching is impossible or the platform cannot support it.

Modbus

A widely used industrial protocol with no authentication, encryption, or integrity checking — anyone on the network can read and write registers.

DNP3

A utility protocol with an optional secure authentication extension (DNP3-SA) that is frequently not deployed.

IEC 61850

The substation automation standard — defining communication and data models for electrical protection and control devices.

OPC UA

A modern industrial interoperability standard with built-in security — authentication, encryption, and integrity.

IEC 62443

The principal international standard for industrial automation and control systems security — defining zones and conduits, security levels, and requirements across operator, integrator, and vendor roles.

NIST SP 800-82

Guide to Industrial Control Systems Security — the US reference for applying security controls to OT environments.

NERC CIP

Mandatory reliability standards for the North American bulk electric system — covering asset identification, electronic security perimeters, systems security management, and incident reporting.

Safety case

The documented argument that a system is safe to operate — against which any change, including a security change, must be assessed.

IT/OT convergence

The technical and organisational integration of information technology and operational technology environments — bringing operational benefit and a significant governance challenge.

Living off the land

Using legitimate tools and protocols already present in the environment to avoid detection — a technique widely used by nation-state actors in OT environments.

Pre-positioning

Establishing persistent access to critical infrastructure for use at a future time — independent of whether the capability is ever used.

Manual fallback

The ability to operate a process manually or locally when control systems are unavailable — a core resilience capability.

14 Activities

The activities below help you test your understanding and prepare for the unit discussion, for Assignment 2, and for the Module 3 material on governance and resilience. They are not graded, but completing them will substantially improve your preparation.

15 Self-check

Answer the questions below to complete Unit 5. If you cannot answer a question confidently, revisit the corresponding section.

16 Summary

This lesson has examined critical infrastructure security — the part of the enterprise and national estate where security failure becomes physical, societal, and sometimes fatal. The essential points are:

• Consequence defines critical infrastructure. Systems and assets so vital that their incapacity would debilitate security, the economy, public health and safety, or the functioning of society — across energy, water, transport, communications, finance, health, food, government, and manufacturing.
• OT is not IT. Operational technology prioritises safety first, then availability, then integrity, then confidentiality. It is deterministic, long-lived, unpatchable, unagentable, and governed by engineering and safety culture. Security practice must adapt to these differences — controls that disrupt the process are the wrong controls.
• The Purdue model defines the architecture. Physical process, basic control, supervisory control, operations management, the industrial DMZ, enterprise IT, and the cloud — with the industrial DMZ as the controlled boundary between IT and OT.
• ICS components carry physical consequence. PLCs, RTUs, IEDs, HMIs, SCADA, DCS, historians, engineering workstations, and safety instrumented systems — each with specific vulnerabilities and specific significance.
• The threat is capable and strategic. Nation-state actors with pre-positioning objectives, criminal ransomware crews, hacktivists, insiders, and the supply chain — with engineering-layer compromise as the most consequential objective.
• Documented incidents establish the lessons. Stuxnet, the Ukraine grid attacks, Triton, NotPetya, Oldsmar, Colonial Pipeline, Volt Typhoon — establishing that physical damage is possible, that safety systems are targets, that IT compromise becomes OT disruption, and that visibility is the first requirement.
• Standards and regulation govern the field. IEC 62443 with zones, conduits, and security levels; NIST SP 800-82; NERC CIP; ISO/IEC 27019; NIS2 and CER; and sector-specific regimes — providing a floor, not a ceiling.
• OT controls favour the passive and the compensating. Segmentation, the industrial DMZ, unidirectional gateways, controlled remote access, passive monitoring, inventory-based vulnerability identification, risk-based patching, compensating controls, and offline backups.
• IT/OT convergence is the central governance challenge. Integrating environments with different priorities, cultures, and lifecycles — requiring joint governance, shared standards with differentiated controls, combined monitoring, and integrated incident response.
• Resilience is the primary objective. Redundancy, manual fallback, offline backups, spare equipment, and rehearsed recovery — because prevention cannot be guaranteed and recovery in OT is slow, physical, and safety-governed.
• Incident response begins with safety. Safety first, then service restoration — with containment at the network, evidence from environment telemetry, remediation by rebuild, and coordination with operations, regulators, and vendors.
• Common pitfalls recur. Applying IT controls directly to OT; assuming the air gap still exists; no asset inventory; uncontrolled vendor remote access; flat OT networks; safety systems not independent; no OT monitoring; untested backups; compliance treated as security; no IT/OT governance; ignoring the small operator problem; response plans that assume IT incident response.

This lesson concludes Unit 5. Across the eight lessons, the unit has examined the infrastructure estate in full — operating systems, endpoints, applications, databases, cloud, containers and virtualisation, the device estate, and critical infrastructure. The recurring themes have been consequence, constraint, and the necessity of designing security around the operational reality of the system being protected.

Module 3 turns to governance, operations, and enterprise resilience — examining how security is governed, how risk is managed, how compliance is demonstrated, how incidents are responded to, and how the enterprise continues to operate and recover. The critical infrastructure material in this lesson has direct application there: the safety-first priority ordering, the resilience emphasis, the regulatory environment, and the multi-party coordination required in a serious incident are all themes that Module 3 develops in depth.