1

IoT Vulnerabilities — Smart Devices & Embedded OS

The Internet of Things (IoT) is a group of objects — electronic or not — that are connected to the wider internet through embedded electronic components. Smart TVs, door locks, cameras, smart speakers, thermostats, lighting systems, industrial sensors — all IoT. And nearly all of them have security as an afterthought to convenience.

Embedded OS — the core problem
Most IoT devices run embedded versions of Linux or Android. A Linux vulnerability can directly affect your smart speaker, smart TV, or any IoT device running that Linux version. Manufacturers rarely ship updates, and users almost never apply them — devices run vulnerable OS versions for years.
Default credentials
IoT devices ship with default admin passwords (admin/admin, root/password). A majority are never changed by end users. Attackers scan for IoT devices using tools like Shodan, then log in with factory defaults. This was the mechanism behind the Mirai botnet — hundreds of thousands of IoT devices with default credentials used for DDoS attacks.
No update mechanism
Many IoT devices have no way to receive security patches — either the manufacturer doesn't provide them, or the update mechanism itself is insecure. A device purchased today may run the same vulnerable OS version in five years. There's no equivalent of Windows Update for most IoT hardware.
Corporate IoT risk: Smart TVs in conference rooms, smart speakers, IP cameras — all IoT devices connected to the corporate network are potential pivot points. They run vulnerable OS versions, rarely get patched, and have full network access. Segment all IoT devices onto a dedicated VLAN with no access to the corporate data network. Treat them like untrusted guest devices.

IoT security best practices

Segmentation
Place all IoT devices on a dedicated, isolated VLAN. No direct routing between the IoT VLAN and the corporate network. Any access should go through a firewall with strict ACLs. An attacker who compromises a smart TV should not be able to reach your file servers.
Inventory
Know every IoT device on your network. Use network scanning to identify all connected devices — particularly embedded Linux systems. If you don't know it's there, you can't protect it. Shadow IoT (devices connected without IT knowledge) is a major risk.
Updates
Apply firmware updates when available. Check manufacturer websites periodically for security advisories. If a device has reached end-of-support with no update mechanism, assess whether it should remain on the network.
2

Embedded System Types — PLC, SoC, RTOS, FPGA

An embedded system is a computer system designed to perform a specific, dedicated function — typically with its own dedicated operating system or microprocessor. Unlike general-purpose computers, embedded systems are static: they don't receive frequent changes, updates, or patches. They're built to last, not to evolve.

PLC
Programmable Logic Controller
Computer designed for deployment in industrial or outdoor settings — automates and monitors mechanical systems. Runs on firmware. Patches are rare (6-month to 2-year cycles). Opens and shuts valves, starts and stops motors, controls manufacturing processes.
Example: valve control in a water treatment plant
SoC
System on a Chip
A processor that integrates multiple platform functions onto a single chip. Power-efficient and compact — used in small embedded devices. The programming is done at manufacture and cannot be changed by the end user. Minimises physical size.
Example: robot vacuum cleaner, smart home controller
RTOS
Real-Time Operating System
An OS that prioritises deterministic execution — guarantees consistent response times for time-critical tasks within milliseconds. Cannot tolerate reboots or crashes. Used where the OS must respond predictably and continuously without interruption.
Example: autopilot flight control, nuclear plant valve control
FPGA
Field Programmable Gate Array
A processor that can be programmed by the end customer (not just the manufacturer) to perform a specific function. Unlike SoC (factory-programmed), FPGA is customer-configurable. More flexible than SoC but requires programming expertise. Also used as an anti-tamper mechanism (Chapter 28).
Example: custom control timing for industrial valve cycles
Embedded system security reality: These systems are static environments — frequent changes are not made or allowed. Many cannot receive security updates at all. Even when updates exist, applying them requires maintenance downtime that industrial operations can't always absorb. Compensating controls (network isolation, strict ACLs, passive-only monitoring) are the primary defence.
3

ICS & SCADA Architecture — OT vs. IT

IT vs. OT — a fundamental distinction

IT — Information Technology
Windows servers, desktops, networks, applications. Primary concern: CIA triad (Confidentiality first). Internet-connected by design. Standard protocols: TCP/IP. Reboots, patches, and downtime are manageable. Your Nessus, SCCM, and standard security tools work here.
OT — Operational Technology
PLCs, sensors, industrial controls, manufacturing equipment. Primary concern: AIC triad (Availability first). Originally isolated from internet. Proprietary protocols: Modbus, fieldbus. Cannot tolerate reboots or downtime. Your standard IT tools may crash OT devices if used on the OT network.

ICS/SCADA architecture (top to bottom)

OT Network Hierarchy — ICS/SCADA Architecture
Enterprise
→
SCADA Server
Supervisory Control and Data Acquisition — manages multi-site, geographically distributed systems. Connects via WAN (cellular, microwave, satellite). Aggregates data from all sites. Software running on an ordinary computer.
Control
→
Control Server + Data Historian
Control server manages the local ICS. Data historian aggregates and catalogs operational data from all sources for audit, incident response, and trend analysis. Single-site versus SCADA's multi-site scope.
Interface
→
HMI — Human Machine Interface
Input/output controls that allow operators to configure and monitor the system. Can be physical buttons/dials on a cabinet, a touchscreen panel, or a flat-panel display. This is how humans interact with the OT network.
Network
→
Fieldbus / Modbus
Digital serial data communications linking PLCs together. Fieldbus = the physical/data link network. Modbus = the communications protocol (not TCP/IP). Links PLCs to each other and to the control server. Different from IT networking protocols.
Devices
→
PLCs — Programmable Logic Controllers
Individual controllers for each physical process. Each PLC has one job: control this valve, monitor this flow, operate this breaker. Connected in a control loop. Firmware-based, rarely patched.
Physical
→
Physical Processes
Valves, motors, pumps, breakers, turbines, conveyor belts. What OT is actually controlling in the real world. Changes to this layer have physical, real-world consequences — including safety-critical ones.

Key ICS/SCADA terminology

ICS
Industrial Control System — a network that manages embedded devices within a single facility. Examples: power station, water supplier, hospital systems, manufacturing floor. One plant, one ICS.
SCADA
Supervisory Control and Data Acquisition — a type of ICS that manages large-scale, multi-site systems across a geographic region. Uses WAN connections (cellular/microwave/satellite). Examples: utility grid management, smart meter reading. Multiple plants, one SCADA.
Fieldbus
The digital serial data communications network that links PLCs together within an OT network. The OT equivalent of Ethernet — but for operational technology, not information technology.
Modbus
The communications protocol used in OT networks — the OT equivalent of TCP/IP. Used by control servers and SCADA hosts to query and change PLC configurations. If you're doing an incident response on an OT network and expecting TCP/IP, you'll be reading the wrong language.
Data historian
Software that aggregates and catalogs data from multiple sources within an ICS. The forensic goldmine for incident responders working on OT incidents. Find it first — it has the operational audit trail.
AIC triad (OT)
OT networks prioritise Availability → Integrity → Confidentiality (AIC), not CIA. The factory must keep running — downtime costs money and can create safety hazards. Confidentiality was secondary because OT was originally air-gapped.
4

ICS/SCADA Mitigation — NIST SP 800-82, Four Controls

Reference guide: NIST Special Publication 800-82 (Guide to Industrial Control Systems Security). Essential reading for anyone who works in a manufacturing, utilities, or industrial environment. For the exam, know these four key controls.

1
Establish administrative control over OT networks by recruiting OT-specialist staff. OT is not IT. Standard IT knowledge is insufficient — an IT administrator applying normal procedures to an OT network can damage equipment or cause safety hazards. Hire people who understand PLCs, fieldbus, SCADA, and Modbus. They are specialists and worth it.
2
Implement minimum network links — disable all unnecessary links, services, and protocols. OT networks should be as isolated as possible. If there's any connection between the IT network and the OT network, it should be minimal, strictly controlled, and heavily monitored. Every unnecessary connection is an attack path.
3
Develop and test a patch management programme specifically for OT networks. Standard IT patch management tools (SCCM, WSUS) don't work on OT systems. PLC firmware updates require specific vendor processes, maintenance windows, and careful planning — because patching a PLC may shut down the physical process it controls. Develop, test, and document a separate OT patch management programme.
4
Perform regular audits of logical and physical access using OT-aware passive analysis. Don't use active scanning tools (Nessus, Nmap) on OT networks — they can crash PLCs or disrupt physical processes. Use passive monitoring only: connect Wireshark or a passive tap, capture traffic, analyse it offline. Use OT-specialist auditors who know what abnormal Modbus traffic looks like.
Never use active scanning tools on OT networks. A vulnerability scan that sends probe packets to a PLC can overload its processor, cause it to crash, or trigger unexpected physical actions (opening a valve, tripping a breaker). Passive-only analysis — packet capture and offline analysis — is the safe approach for OT network assessment. Standard IT security tools can cause real-world physical damage in OT environments.
5

Premise System Vulnerabilities — BAS, PACS & HVAC Attacks

A premise system is any system used for building automation and physical access security — typically a third network in an organisation (alongside IT and OT). Door access control, security cameras, HVAC, lighting, elevators, and power are all premise systems. And they're frequently connected to the internet or the corporate network — which makes them attack vectors.

BAS — Building Automation Systems
Components and protocols facilitating centralised control and monitoring of mechanical and electrical systems (HVAC, lighting, elevators, power, fire suppression). Often web-managed for remote monitoring. Use PLCs for control. Common vulnerabilities: plain-text credentials in code, web UI injection (SQL/XML/XSS), and unpatched firmware.
PACS — Physical Access Control Systems
All components managing physical security — badge readers, door locks, security cameras, alarm systems. Centralised monitoring of access events. Often installed and maintained by a third-party contractor. Risk: because it's a third-party system, it's frequently excluded from vulnerability assessments — but if it connects to the corporate network, it's still an attack path.

Premise system attack scenarios

HVAC as pivot point
The 2013 Target breach: attackers compromised a third-party HVAC contractor, pivoted through the HVAC system's network connection into Target's payment network, and stole credit card data from 40 million customers. HVAC systems connected to the corporate network are a classic pivot path — they're usually poorly secured and overlooked in risk assessments.
Physical DoS via HVAC
An attacker who controls the building automation system can turn off HVAC in a data centre. Without cooling, servers overheat and shut down — an electronic attack achieved through a physical mechanism. Physical DoS can shut down business operations without touching a single server directly.
Web UI injection
Many BAS and PACS systems expose web management interfaces locally or over the internet. These interfaces are often poorly tested for injection vulnerabilities. SQL injection, XML injection, or XSS can give an attacker control of the building automation system — including door locks and cameras.
Outsourcing premise systems doesn't remove responsibility. If a third-party contractor's BAS system is connected to your network and they get hacked, attackers can pivot into your systems. You can outsource the task but not the responsibility. Require contractors to provide regular vulnerability assessments, maintain network segmentation, and be covered by your SLA. The Target breach is the canonical example of this failing.
6

Vehicular Vulnerabilities — CAN Bus, OBD-II & Three Attack Vectors

Modern vehicles are computers on wheels. A Controller Area Network (CAN) connects all subsystems — HVAC, steering, cruise control, braking, entertainment. The CAN was designed in the 1980s/90s when security wasn't a concern: any message on the CAN bus is automatically trusted. There is no source address authentication, no message authentication, no way to verify a command is legitimate. If a message reaches the CAN, it executes.

CAN bus fundamentals

CAN bus
Controller Area Network — digital serial data communications network within a vehicle. Similar to Ethernet in design (contention-based, collision detection). All subsystems communicate over it. Zero authentication — designed when these were isolated systems with no external connectivity. Now connected to cellular and WiFi, so external actors can reach it.
OBD-II
On-Board Diagnostics port — the primary external interface to the CAN bus. Added to all cars from ~1996. Originally for mechanics to read fault codes ("check engine"). Located under the dashboard where it's not easily visible. Any device plugged into OBD-II has access to the CAN bus and can send trusted commands.

Three CAN attack vectors

🔌
Local (OBD-II)
Plug a rogue device into the OBD-II port. The attacker doesn't need to be in the car — a hidden plug installed by a valet, mechanic, or anyone with brief access can provide a wireless bridge into the CAN. The device is invisible under the dashboard.
📱
Cellular
Cars with built-in cellular modems (infotainment systems) can be attacked if the entertainment network and the CAN are not properly separated. Best practice: keep these as two entirely separate networks with no bridge between them.
📶
WiFi
Cars with built-in WiFi hotspots can be attacked by an adjacent vehicle or person in range if there is any link between the WiFi and the CAN. An attacker driving near you could reach your car's CAN through its wireless network.
Jeep Cherokee hack (2015 — Wired magazine): Security researchers demonstrated remote control of a Jeep Cherokee at 70 mph — taking over the HVAC, radio, windshield wipers, and eventually the transmission and brakes — using a cellular connection and a bug in Uconnect. This led to a 1.4-million-vehicle recall by Fiat Chrysler. Real-world demonstration that automotive CAN vulnerabilities have physical safety consequences. Exam: remember the three attack vectors — local OBD-II, cellular, and WiFi.
Exam

Quick Reference Cheat Sheet

IoT vulnerabilities
Run embedded Linux/Android — vulnerable to OS-level CVEs. Rarely patched or updated. Default credentials almost never changed. No update mechanism on many devices. Corporate risk: smart TVs, cameras, speakers as pivot points. Mitigation: dedicated isolated IoT VLAN, inventory all devices, apply firmware updates when available.
Embedded system types
PLC = Programmable Logic Controller (industrial control, firmware, rare patches). SoC = System on a Chip (factory programmed, compact, single function). RTOS = Real-Time Operating System (deterministic response, no reboots tolerated, safety-critical systems). FPGA = Field Programmable Gate Array (customer-programmable, flexible). Static environments = infrequent updates, compensating controls primary defence.
IT vs. OT
IT = information technology (Windows/networks, CIA triad, internet-connected, standard protocols TCP/IP). OT = operational technology (PLCs/ICS/SCADA, AIC triad [Availability first], originally isolated, Modbus/fieldbus protocols). Keep IT and OT networks separate with minimal monitored connections. Standard IT security tools can damage OT equipment.
ICS/SCADA architecture
ICS = one plant. SCADA = multi-site geographic (connects over WAN). Fieldbus = links PLCs. Modbus = protocol (not TCP/IP). HMI = human input/output to PLCs. Data historian = aggregates operational data (forensic goldmine). Control server = manages local ICS. PLCs → physical processes (valves/motors/breakers). AIC triad. Passive monitoring only — active scanning crashes OT devices.
ICS/SCADA mitigation (NIST 800-82)
1 Admin control via OT-specialist staff (not IT generalists). 2 Minimum network links — disable all unnecessary connections between IT and OT. 3 OT-specific patch management programme (not SCCM). 4 Regular audits using passive analysis only (Wireshark/packet capture — NO active scanning). Standard vulnerability scanners can crash PLCs or trigger physical actions.
Premise systems
BAS = Building Automation Systems (HVAC/lighting/elevators/power, PLCs, web UI). PACS = Physical Access Control Systems (badge readers/cameras/alarms, often third-party maintained). Vulnerabilities: plaintext credentials in code, web UI injection (SQL/XML/XSS), unpatched firmware. Target breach 2013 = HVAC contractor → pivoted into payment network. HVAC → data centre cooling off = physical DoS. Outsource task not responsibility.
Vehicular vulnerabilities
CAN = Controller Area Network (all vehicle subsystems, 1980s design, no authentication). OBD-II = external diagnostic port → access to CAN. Any CAN message is automatically trusted — no source verification. Three attack vectors: Local (OBD-II plug — hidden under dashboard), Cellular (if infotainment connects to CAN), WiFi (if hotspot connects to CAN). Jeep Cherokee hack 2015 = remote control via cellular at 70 mph.