Example 1 · IoT Network Breach — Smart Thermostat as Entry Point
A mid-sized law firm deploys 12 smart thermostats across its offices to enable remote temperature management from a facilities management app. The thermostats are Wi-Fi connected and placed on the same corporate network as employee workstations, servers, and the document management system containing privileged legal files.
The thermostat manufacturer is a HVAC hardware company. Their thermostats ship with a default admin interface accessible on port 80, using the default credential admin/admin. The firmware has not been updated since the device shipped 18 months ago. The manufacturer published a firmware update 6 months ago patching a remote code execution vulnerability, but the law firm's IT team was not subscribed to manufacturer security advisories and was unaware of the update.
Thermostat discovery:
Attacker runs internet scan for port 80 on corporate IP range
Thermostat management interface found at 192.168.1.47:80
Login attempt: admin / admin → success
Exploitation:
Attacker applies known RCE exploit for CVE-XXXX-XXXX (patched firmware available)
Gains shell on thermostat's embedded Linux OS
Thermostat is on same VLAN (192.168.1.0/24) as file servers
Lateral movement:
Nmap scan from thermostat → discovers 192.168.1.20 (file server, SMB port 445 open)
File server has no host firewall; SMB accessible from any device on VLAN 1
Mounts SMB share → accesses 340 GB of client case files
Exfiltrates 14,000 privileged legal documents over 3 days
Thermostat continues operating normally — no one suspects the breach
Why the attack succeeded — three compounding failures:
- IoT device on corporate network: The thermostat should have been on a dedicated IoT VLAN with ACLs blocking all communication to corporate systems. On the corporate VLAN, the thermostat had a direct Layer 2 path to every server.
- Default credentials never changed: The IT team treated the thermostat as facility equipment, not a network device requiring security configuration. The admin/admin credential was never changed before deployment.
- No firmware update process: No subscription to manufacturer security advisories meant a patched RCE vulnerability sat unpatched for 6 months. An inventory management process with end-of-support tracking would have flagged the outdated firmware.
Example 2 · VM Escape vs. Container Escape — Isolation Boundary Comparison
A hosting provider runs customer workloads on its infrastructure. Two customers, Customer A and Customer B, each have an application running on the provider's platform. A security researcher discovers a critical vulnerability in the platform and analyzes its impact under both a virtualized and containerized deployment model.
Scenario A — Virtualized (VM per customer):
Infrastructure: Physical server
Hypervisor: VMware ESXi 8.0
VM-A: Customer A's application (Guest OS: Ubuntu 22.04)
VM-B: Customer B's application (Guest OS: Windows Server 2022)
Vulnerability found: Critical RCE in Customer A's application (Guest OS level)
Attacker compromises Customer A's application → has access to VM-A guest OS
Attacker attempts to reach VM-B or the hypervisor from VM-A:
→ Cannot — the hypervisor enforces a hardware-abstraction boundary between VMs
→ VM-A has no network path to VM-B except through a deliberately configured network
→ VM-A cannot read VM-B's memory or storage — the hypervisor enforces this
Impact: Customer A's data compromised. Customer B: unaffected.
To affect Customer B, attacker needs a separate hypervisor vulnerability (VM escape) —
a much harder, rarer exploit class.
Scenario B — Containerized (container per customer):
Infrastructure: Physical server
Host OS: Ubuntu 22.04 (shared by all containers)
Container Engine: Docker
Container-A: Customer A's application
Container-B: Customer B's application
Vulnerability found: Critical RCE in Customer A's application (container level)
Attacker compromises Customer A's application → has access to Container-A
Attacker finds a container escape vulnerability in the host kernel (CVE in Linux namespace handling):
→ Escapes from Container-A to the host OS
→ Host OS = the foundation that Container-B also runs on
→ Attacker now has root on host → can read Container-B's filesystem and processes
Impact: Customer A AND Customer B data compromised.
Root cause: containers share the host OS kernel — a host kernel vulnerability affects all tenants.
The lesson: Containers provide strong application-level isolation for normal conditions, but the shared host kernel is a common attack surface for all containers on the same host. VMs have stronger isolation boundaries because each VM has its own OS — but the hypervisor itself remains the high-value attack target. For multi-tenant environments with strong isolation requirements (hosting competing customers, sensitive workloads), VM-level isolation is the stronger model.
Example 3 · SCADA Attack Chain — The Physical Consequence
A water treatment facility uses a SCADA system to monitor and control chemical dosing pumps, filtration systems, and reservoir levels across three sites. The SCADA workstations run Windows and are connected to the same corporate network as the administrative IT systems — the IT/OT (Operational Technology) network boundary was never implemented. A remote access tool allows engineers to connect to SCADA workstations from home for after-hours monitoring.
Initial access:
Attacker sends phishing email to facilities engineer
Engineer clicks malicious link → credential harvested
Attacker uses harvested credentials to access remote access tool
Lateral movement to SCADA:
Remote access tool connects to corporate network
SCADA workstations on same network segment → directly reachable
Attacker connects to SCADA workstation WST-01
SCADA manipulation:
Attacker opens chemical dosing control interface
Sodium hypochlorite (chlorine) pump: normal set point = 1.7 mg/L
Attacker increases set point to 111 mg/L (65× normal dose)
Attacker disables low-level alarms that would alert operators to the change
Physical consequence (prevented by operator intervention 6 hours later):
Water at 111 mg/L chlorine is unsafe for consumption
Had the contaminated water reached distribution: public health emergency
Recovery: shut down affected pumps, flush reservoir, re-test water supply
Downtime: 3 days; cost: $400,000
This scenario is based on the 2021 Oldsmar, Florida water treatment attack. An attacker remotely accessed SCADA systems and attempted to increase sodium hydroxide levels to dangerous concentrations. An alert operator noticed the cursor moving on the screen and reversed the change within minutes.
Controls that would have prevented or limited this attack:
- IT/OT network segmentation (air gap): SCADA workstations should have had no network connection to corporate IT systems. The attacker used corporate credentials to pivot to the SCADA network — which should not have been reachable from corporate at all.
- No direct remote access to SCADA: Remote access, if required, should be through a hardened jump server with full session recording, MFA, and time-limited access — not a direct connection to the SCADA workstation.
- Alarm protection: Critical safety alarms should not be modifiable from the same workstation that controls set points — or should require a separate physical key or secondary confirmation.
Example 4 · RTOS Security Constraint — Why You Can't Install EDR on a Pacemaker
A hospital's biomedical engineering team receives a security advisory: a vulnerability has been discovered in the firmware of a cardiac pacemaker model deployed in 200 patients. The advisory recommends applying an EDR (Endpoint Detection and Response) agent to detect exploitation attempts, patching the firmware, and monitoring network traffic from the device.
The biomedical team's analysis — why standard IT security recommendations don't apply:
Recommendation 1: Install EDR agent
Result: Cannot implement
Reason: Pacemaker runs an RTOS. The RTOS firmware is a closed, purpose-built system —
there is no mechanism to install arbitrary software. The hardware has no available CPU
headroom or memory capacity for a monitoring agent. An EDR agent's background
processing would violate the RTOS deterministic timing guarantee — the pacemaker
must deliver electrical impulses within exact millisecond windows; latency is unacceptable.
Recommendation 2: Patch the firmware
Result: Partially implemented
Reason: Firmware update requires a programmer device held by the cardiologist during
a patient encounter. Updates cannot be pushed remotely over-the-air (OTA) for this model
— each of 200 patients must have a scheduled appointment. Timeline: 6–8 months to
update all deployed devices.
Recommendation 3: Monitor network traffic from the device
Result: Partially implemented
Reason: The pacemaker communicates with a bedside monitor and the provider's cloud
service. Network-level anomaly detection can be applied at the network boundary —
but the device itself produces no logs and cannot be queried for its network activity.
What the hospital can actually do:
- Compensating network controls: Segment the medical device network so pacemaker communicators can only reach the approved manufacturer cloud endpoint — no other internet destinations. Any traffic to unexpected destinations triggers an alert.
- Accelerated patch scheduling: Prioritize the firmware update for higher-risk patients. For devices that cannot be updated within the risk window, document compensating controls and risk acceptance with sign-off.
- Manufacturer liaison: Engage the manufacturer for a timeline on an OTA update capability in future firmware versions. Require contractually that future devices support remote update.
The key lesson: RTOS and embedded system security is primarily solved at the network boundary — not at the device itself. Traditional endpoint security tools (EDR, AV, vulnerability scanners) cannot be deployed on deterministic real-time systems. Security must be designed in at manufacture time or enforced externally.
Exam Scenario · Infrastructure Architecture Review
Scenario: A manufacturing company runs three separate infrastructure environments: (1) a corporate IT network with employee workstations and business applications; (2) a factory floor with SCADA-controlled assembly robots and conveyor systems; (3) a public cloud environment for its customer ordering portal. The CISO is reviewing the security architecture. Answer the following:
A. The SCADA system currently shares a network segment with corporate IT. An engineer argues that a firewall between them is sufficient. The CISO recommends a physical air gap. Who is correct, and why?
The CISO is correct for a manufacturing SCADA environment. A firewall between segments is better than no separation, but it is still a logical boundary — a misconfigured firewall rule, a compromised firewall, or a software vulnerability in the firewall could create an unintended path. SCADA systems control physical processes: unauthorized commands to the assembly robots could cause equipment damage or worker safety incidents. When the consequence of any unintended cross-segment communication is physical — not just a data breach — a physical air gap (no network connection between environments) is the appropriate control. The firewall also becomes a management target: an attacker who compromises the corporate IT network and then the firewall management interface can remove the ACL rules. An air gap removes this attack path entirely.
B. The factory floor also has 30 IoT sensors monitoring temperature and humidity in the production environment. Should these be on the same network as the SCADA systems?
No. IoT sensors have weak default security configurations and may have unpatchable firmware vulnerabilities. Placing them on the same network as SCADA systems would give a compromised IoT sensor a direct path to SCADA workstations and PLCs. IoT sensors should be on their own dedicated IoT VLAN, isolated from the SCADA network. They should communicate sensor data only to an authorized aggregation system, not have direct access to SCADA control interfaces. If the SCADA network is air-gapped from corporate IT, the IoT VLAN should also be separate from the SCADA network — IoT is not trusted infrastructure.
C. The cloud ordering portal currently runs on VMs. The development team proposes migrating to containers for faster deployment cycles. What is the key security tradeoff the CISO should evaluate?
The key tradeoff is isolation boundary strength. VMs provide strong isolation — each VM has its own OS, and a compromise of one VM does not automatically affect neighboring VMs (a hypervisor escape is required). Containers share the host OS kernel — a vulnerability in the host kernel is a shared vulnerability across all containers on that host. For the ordering portal, which processes customer data including potentially payment information, the CISO should evaluate: (1) whether the container host OS will be patched aggressively; (2) whether container images use non-root users and have appropriate seccomp/AppArmor profiles; (3) whether the faster deployment cycle actually improves security by enabling faster patching cycles. Containers are a reasonable choice for this workload, but the shared kernel risk must be explicitly acknowledged and mitigated.
D. The company is evaluating adding a hot standby for the corporate file server. What is the difference between a redundant cold spare and an active/passive HA configuration, and when would the more expensive active/passive option be justified?
A cold spare is a hardware unit sitting in storage — it must be physically deployed, powered on, configured, and have data restored before serving requests. Recovery time: potentially hours. An active/passive HA configuration maintains a continuously synchronized standby that is already powered on, configured, and waiting. Failover is automatic — seconds. The active/passive option is justified when the cost of hours of downtime on the file server exceeds the cost of the HA infrastructure. For a manufacturing company, if the file server hosts engineering documents that assembly line workers access in real time, hours of downtime could halt production — a cost that likely exceeds the HA investment. For an archive server accessed weekly, a cold spare may be acceptable.