IoT, ICS/SCADA, embedded systems and infrastructure as code

Objective 3.1 in this course covers architecture models. The previous lesson took on-premises, cloud and virtualisation; this one takes the remaining items in CompTIA's scope note for it — Internet of Things, industrial control systems, and infrastructure as code — together with embedded systems and real-time operating systems, which sit alongside them.

Why this matters

Everything in this lesson breaks an assumption the rest of the course relies on. "Patch it promptly" assumes a patch exists and downtime is acceptable. "Reimage the host" assumes there is an image. "Deploy the agent" assumes the device can run one. None of that holds for a programmable logic controller running a production line, or for a sensor with 128KB of memory.

The exam tests whether you recognise when the standard answer does not apply — and that is a genuinely different skill from knowing the standard answer.

The lesson

Why an embedded system's lifetime outlives its patch support

An embedded system is a computer built into a larger device to do one job: a medical infusion pump, a building management controller, a lift, a vehicle control module, a smart meter, a point-of-sale terminal.

Three properties create the security problem, and they compound:

• Long service life. The device is expected to last ten, fifteen, twenty-five years, because it is part of a building or a vehicle or a factory that lasts that long.
• Short vendor support. The manufacturer supports the software for a fraction of that — often five years, sometimes less, sometimes not at all after the product line is discontinued.
• Replacement is a capital project. You do not swap out a building's access control system because its firmware is unsupported. The cost and disruption are measured against a business case that security rarely wins on its own.

The consequence is that a large share of these devices are, and will remain, permanently unpatched. That is not a failure of the organisation's vulnerability management — it is a property of the asset class, and the exam expects the answer to be compensating controls: segment them onto their own network, restrict what they can reach and what can reach them, monitor their traffic for anything unusual, and record the accepted risk with a review date.

IoT devices share all of this and add two things: they are often deployed outside IT's knowledge (shadow IT from Domain 2), and they frequently ship with default credentials, unnecessary services and cloud connections the buyer did not ask for. The single highest-value control is a separate network segment with no route to anything important, plus changing defaults and disabling what is not needed.

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

Industrial control systems (ICS) run physical processes — manufacturing, water treatment, power distribution, pipelines, building automation. SCADA (supervisory control and data acquisition) is the supervisory layer that monitors and controls them across sites. The devices at the bottom are PLCs (programmable logic controllers) and RTUs.

The defining difference from IT, and the thing to carry into the exam: the priority order is inverted. IT security generally ranks confidentiality first. In operational technology it is 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, explosion, or a hospital losing power.

What follows from that:

• Patching is scheduled around production, sometimes annually, sometimes only during planned shutdowns. "Patch immediately" is not available.
• Active scanning can crash devices. PLCs have been knocked offline by ordinary vulnerability scans. Passive monitoring is preferred; any active testing is done in a test environment or during a shutdown.
• Availability controls dominate: redundancy, fail-safe states, and deterministic behaviour.
• Protocols are old and unauthenticated. Modbus, DNP3 and similar were designed for isolated networks and generally have no authentication or encryption at all, so anyone who can reach the network can issue commands. That is why network position is the control.

The standard architecture is the Purdue model: layered zones from the physical process up to enterprise IT, with controlled conduits between them and a demilitarised zone separating OT from IT. You do not need the layer numbers for SY0-701; you do need the idea that OT is segmented from IT and traffic between them is brokered, not routed freely.

Real-time operating systems, and the update window that does not exist

A real-time operating system (RTOS) guarantees that an operation completes within a bounded time. That guarantee is the product: an airbag controller, an anti-lock braking system, a robotic arm and a medical device are useless if the response is merely "usually fast".

Security consequences:

• Anything that introduces non-deterministic delay is unacceptable — which rules out most agents, on-access scanners and inline inspection.
• Resources are minimal. There may be no room for cryptographic libraries, logging or an agent, and no persistent storage for logs.
• Restarting to apply an update may not be possible while the process runs, and the update window can be a planned outage months away.
• Certification makes changes expensive: a medical or aviation device's software is certified as a whole, so patching it can require recertification. This is a genuine and legitimate reason a known vulnerability stays unpatched.

The mitigation pattern is consistent: put the control around the device rather than on it. Network segmentation, unidirectional gateways where appropriate, strict access control, and passive monitoring of the traffic it produces.

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 — which are applied by a tool rather than configured by hand.

The security benefits are substantial and worth being able to state:

• Consistency. Every environment is built from the same definition, so production and staging genuinely match and drift is detectable.
• Version control. Every change is a reviewed, attributable commit with a history — which is the change management evidence from Domain 1, produced automatically.
• Review before deployment. A firewall rule change becomes a pull request a human approves, and automated policy checks can 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. The blast radius of a bad template is the whole estate.
• Secrets in the repository. Credentials and keys committed into IaC files are one of the most common sources of cloud compromise. Secrets belong in a secrets manager and are referenced, never embedded.
• The pipeline is now privileged infrastructure. Whatever applies the code holds credentials that can create and destroy anything. Compromising the CI system is compromising the estate.
• Drift, where someone makes a manual change that the next apply silently reverts — or does not, leaving reality and definition disagreeing.

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

Air gap, and the assumptions that quietly break it

An air gap is physical isolation: no network connection whatsoever between a system and 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, and the exam does test the failure modes:

• Removable media. Data has to get in and out somehow. USB drives are the standard route and the standard bypass; the most famous ICS attack in history 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 temporary remote access for support, a cellular modem in an RTU, a wireless link added for convenience — each is a permanent hole that nobody recorded.
• Shared infrastructure. Two "isolated" networks on the same physical switch, separated only by VLAN configuration, are one misconfiguration from being one network.

So an air gap is a control that requires continuous verification, not a one-time design decision. The honest exam answer when a scenario claims an air gap and describes a USB workflow is that the gap is not what protects them, and media control plus monitoring is what does.

What to take into the exam

• Embedded and IoT devices outlive their support, so compensating controls — segment, restrict, monitor, accept and review — are the expected answer.
• In ICS/OT, availability and safety come first and confidentiality last, which is why active scanning and immediate patching are often wrong.
• OT protocols such as Modbus have no authentication, so network position is the control.
• An RTOS cannot accept non-deterministic delay, which rules out most agents and inline inspection.
• IaC gives consistency, reviewable change and reproducibility, and concentrates risk in the repository, the secrets and the pipeline.
• Air gaps are broken by removable media, dual-homed machines and forgotten maintenance links.