Operational technology, air gaps, segmentation and infrastructure as code

Objective 3.1 compares architecture models by their security implications. The previous lesson took on-premises and cloud. This one takes the models that break the usual assumptions: operational technology, networks isolated by an air gap, segmentation done logically or physically, and infrastructure defined as code.

Why this matters

Everything in the first half of this lesson breaks an assumption the rest of the course relies on. "Patch it promptly" assumes a patch exists and downtime is acceptable. "Scan it" assumes the device survives a scan. "Deploy the agent" assumes the device can run one. None of that holds for a controller running a production line or a water treatment plant.

The exam tests whether you recognise when the standard answer does not apply -- a genuinely different skill from knowing the standard answer. The second half, infrastructure as code, shows the opposite: an architecture that makes the standard answers easier to apply everywhere at once, including the mistakes.

The lesson

OT: availability first, and what that does to your control choices

Operational technology (OT) is the hardware and software that monitors and controls physical processes: manufacturing lines, power distribution, water treatment, pipelines, building automation, medical and transport systems. Industrial control systems and the supervisory systems that run them across sites (SCADA) are part of it; the devices at the bottom are typically programmable logic controllers.

The defining difference from IT, and the thing to carry into the exam: the priority order is inverted. IT security usually puts confidentiality first. OT puts availability and safety first, integrity second, confidentiality last. A control that risks stopping the process is worse than the risk it mitigates, because stopping the process can mean flooding, fire, a damaged plant or a hospital losing power.

What follows from that:

• Active scanning can crash devices. Controllers have been knocked offline by ordinary vulnerability scans. Passive monitoring of the traffic is preferred; active testing happens in a test environment or a shutdown.
• Availability controls dominate: redundancy, safe failure states and predictable behaviour.
• Protocols are old and often unauthenticated. Many industrial protocols, Modbus being the usual example, were designed for isolated networks and carry no authentication or encryption, so anyone who can reach the network can send commands. That is why network position is the control.
• Changes need the process owner. The engineers who run the plant, not the security team, decide when a change is safe.

Why industrial equipment outlives its patch support, and the update window that does not exist

Three properties create the problem, and they compound:

• Long service life. A controller is expected to last as long as the plant, building or vehicle it sits in -- often decades.
• Short vendor support. The manufacturer supports the software for a fraction of that, and sometimes not at all once a product line ends.
• Replacement is a capital project. Nobody rebuilds a production line because its firmware is unsupported.

Even where a patch exists, applying it is hard. Many devices must keep strict timing, so anything that adds unpredictable delay -- an agent, an on-access scanner, inline inspection -- is unacceptable. Restarting may only be possible in a planned shutdown months away. Safety-certified systems may need recertification after any software change, which is a legitimate reason a known vulnerability stays open.

So a large share of OT is, and will remain, permanently unpatched. That is a property of the asset class, not a failure of vulnerability management, and the expected exam answer is compensating controls placed around the device: segment it, restrict what it can reach and what can reach it, monitor its traffic passively, control vendor remote access, and record the accepted risk with a review date.

Air gaps, and the assumptions that quietly break them

An air-gapped network has no network connection at all to any other network. It is the strongest network control there is, and it is used for OT, classified systems and offline backups. It is also the control most likely to be true on the diagram and false in reality:

• Removable media. Data has to get in and out somehow. USB drives are the standard route and the standard bypass; the best-known attack on industrial equipment crossed an air gap this way.
• Dual-homed machines. An engineering laptop connected to the isolated network today and the corporate network tomorrow is a bridge with legs.
• Maintenance connections. A vendor's support link, a cellular modem in a field device, a wireless link added for convenience -- each is a hole nobody recorded.
• Shared infrastructure. Two "isolated" networks on one switch, separated only by configuration, are one mistake from being one network.

An air gap therefore needs continuous verification, not a one-time design decision. When a scenario claims an air gap and describes a USB workflow, the gap is not what protects them; media control, scanning stations and monitoring are.

Logical versus physical segmentation, and what each costs to get wrong

Segmentation divides a network so that a compromise in one part cannot reach the rest freely. It can be done two ways.

• Physical segmentation uses separate hardware: separate switches, cabling, firewalls, sometimes separate buildings. Nothing can be misconfigured into connecting the segments, because nothing joins them except where you put a device. The costs are money, space and inflexibility -- and the temptation for people to bridge segments themselves when the official route is inconvenient.
• Logical segmentation divides shared hardware with configuration: VLANs, subnets, access control lists, firewall rules, cloud security groups and microsegmentation down to individual workloads. It is cheap and flexible, and it fails silently: a mis-tagged port, a trunk carrying the wrong VLANs or an "allow any" rule added during troubleshooting merges segments without any visible change.

The exam's trade: physical buys assurance at high cost; logical buys flexibility and depends entirely on configuration being right and staying right. High-consequence boundaries such as OT to IT often justify physical separation, or at least a dedicated firewall and a buffer zone between them, with traffic brokered rather than routed freely. Layered reference models for industrial networks, such as the Purdue model, express exactly that idea. Either way, segmentation only counts if it is tested: try to reach what should be unreachable, and review the rules.

Infrastructure as code, and the security review moving into the pull request

Infrastructure as code (IaC) defines infrastructure in machine-readable files -- networks, firewall rules, virtual machines, identity policies -- applied by a tool rather than configured by hand.

The security benefits are substantial:

• Consistency. Every environment is built from the same definition, so drift is detectable.
• Version control. Every change is an attributable commit with a history -- change management evidence produced automatically.
• Review before deployment. A firewall rule change becomes a pull request a human approves, and automated policy checks run against it before anything is created.
• Reproducibility, which is a recovery capability: the environment can be rebuilt from the definition.

The risks are the mirror image:

• A mistake is deployed everywhere, instantly and identically.
• Secrets in the repository. Credentials committed into IaC files are a common source of cloud compromise. Secrets belong in a secrets manager and are referenced, never embedded.
• The pipeline is privileged infrastructure. Whatever applies the code can create and destroy anything, so compromising the pipeline is compromising the estate.
• Drift, where a manual change is silently reverted by the next run -- or survives, leaving reality and definition disagreeing.

The exam framing: IaC moves security left, into review and automated policy checks, and concentrates risk in the repository, the secrets and the pipeline.

What to take into the exam

• In OT, availability and safety come first and confidentiality last, so active scanning and immediate patching are often the wrong answer.
• Industrial protocols frequently lack authentication, so network position is the control.
• Unpatchable equipment gets compensating controls around it: segment, restrict, monitor passively, accept and review.
• Air gaps are broken by removable media, dual-homed machines and forgotten maintenance links.
• Physical segmentation is costly and hard to undo by accident; logical segmentation is cheap and fails silently through configuration.
• IaC gives consistency, reviewable change and reproducibility, and concentrates risk in the repository, the secrets and the pipeline.