4.5 Lab: IoT Architecture Triage Desk
Lab: IoT Architecture Triage Desk
Applied analysis · 3 IoT deployment reviews · Simulated architecture team shift · 35–45 min
You are the IoT architect on a security engineering team. Three IoT or embedded deployments have come across your desk for pre-deployment review. For each deployment you will: (1) identify the TWO most serious architecture gaps, (2) map each gap to the structural constraint it represents, and (3) recommend the specific compensating control that addresses each gap without requiring the device’s cooperation.
Commit your answer BEFORE clicking Reveal. That is the point of the lab.
Case 1: The Smart-Campus Cameras
Organization: Large public university
Deployment summary:
Device: IP security cameras (model "SafeWatch-Pro 1000")
Fleet size: 620 cameras across 42 buildings
Firmware: v3.1 (released 2017); vendor confirmed no further updates
Admin account: "admin" / "safewatch1000" (model default in manuals)
Network: Connected to the main campus-office VLAN
so facilities staff can view any camera from any workstation
Auth to NVR: Cameras push video to central recorder via HTTP (not HTTPS)
Inventory: Managed in a shared spreadsheet; "mostly accurate"
according to facilities; last full audit 2 years ago
Ports open: 80 (web UI), 554 (RTSP), 23 (Telnet, "for vendor support")
1. Two most serious architecture gaps:
2. Which structural constraint does each gap represent:
3. Compensating control for each gap:
(1a) Gap: Cameras are on the main campus-office VLAN. A compromise of any of 620 unhardenable cameras reaches every staff workstation, server, and database reachable from that VLAN. Constraint: constraint #3 (no patch channel — firmware frozen at 2017) combined with constraint #4 (default credentials still in place). Fix: Move all 620 cameras to a dedicated IoT / surveillance VLAN, and configure the firewall to permit ONLY the specific flows needed (camera → NVR on the required ports, named NVR and admin hosts → cameras for viewing and configuration). Deny everything else.
(1b) Gap: Default credentials (“admin / safewatch1000”) on 620 cameras that face the network, combined with Telnet (port 23) open for vendor support. This is the exact Mirai pattern at university scale. Constraint: constraint #4 (default credentials). Fix: Rotate every camera’s admin password to a unique value stored in the enterprise credential vault, and disable Telnet permanently — replace with SSH over the management network only. If the vendor demands Telnet for support, the vendor is providing unacceptable support.
Other acceptable gaps to flag: HTTP instead of HTTPS for video push (eavesdropping risk), inventory in a shared spreadsheet (pillar 5 gap), 2-year-old audit (drift), no egress filtering described. Full credit for any two serious gaps with correct constraint attribution and an architectural fix.
Case 2: The Greenfield Smart Factory
Organization: Tier-1 automotive parts supplier
Situation: Breaking ground on a new factory; 180 networked industrial controllers (PLCs, robotic-arm controllers, vision systems) are being purchased and installed. The security team has a clean slate and wants to build the IoT architecture correctly from day one.
Architect’s proposed baseline architecture:
1. All 180 controllers placed on dedicated OT VLAN 300. 2. No direct internet access from VLAN 300; outbound traffic traverses a jump-host on an adjacent management VLAN. 3. Every controller provisioned at manufacture with a unique cryptographic certificate from the vendor's PKI; no shared administrative password. 4. Secure boot enabled on every controller; signed firmware updates required. 5. Device inventory: every controller registered in the CMDB at deployment with firmware version, cert fingerprint, support end date, and owner. 6. SIEM alerts configured for: unexpected outbound destinations from VLAN 300, unsigned firmware attempts, certificate revocations.
1. Which Lesson 4.5 concepts are already addressed in the baseline (name at least three):
2. What is the MOST important remaining gap the design does not mention:
3. Over a 30-year controller lifetime, which single risk will this design struggle with MOST:
(1) Already addressed: (a) Network segmentation (dedicated OT VLAN with no direct internet); (b) Egress filtering (outbound via jump host, destination restrictions); (c) Per-device PKI certificates instead of shared passwords; (d) Secure boot + signed firmware; (e) Device inventory with firmware, cert fingerprint, support end date; (f) SIEM monitoring of anomalous outbound traffic. This is a strong starting architecture — most Lesson 4.5 concepts are explicit.
(2) Most important remaining gap: The proposal does not specify a lifecycle plan for what happens when the vendor eventually abandons firmware support. Automotive factories run 25–30 year cycles; the vendor’s commitment almost certainly ends earlier. Before the vendor abandons support, the organization needs a documented decision point: replace, tighten segmentation further, or accept residual risk with compensating monitoring. This plan should be in place at procurement, not improvised a decade later.
(3) Biggest long-term risk: Configuration drift and certificate rotation over 30 years. Even with a strong baseline, things like PKI roots (CA key rotation), firewall rule decay as people add “just one more” allow, and slow accumulation of undocumented temporary exceptions are the real failure mode. Continuous compliance scanning against the baseline, scheduled certificate rotation, and quarterly firewall-rule review are the practical long-term defenses.
Scoring rubric: 1 pt for three or more correctly named present concepts, 1 pt for identifying end-of-life / lifecycle planning as the missing piece, 1 pt for any reasonable long-term risk (drift, cert rotation, rule decay, vendor abandonment). 2+/3 = passing.
Case 3: The School-District Smart Locks
Organization: Mid-size K-12 school district
Situation: After a district-wide threat assessment, the school board approved installing 4,200 networked smart locks on classroom doors so that administrators can initiate a district-wide lockdown from a central console. The vendor requires each lock to have internet access for firmware updates and to receive lockdown commands from their cloud service.
Key facts:
- Each lock runs an embedded Linux OS on a small ARM microcontroller (limited CPU / RAM). - Vendor supports firmware updates for 7 years, then warranty and patches end. - Each lock authenticates to the vendor cloud via a unique per-device certificate. - The vendor will NOT support on-premises command-and-control; the cloud is mandatory. - If the cloud is unreachable, locks fall back to local keypad / keycard operation. - Local school IT has no direct network access to the locks or to the vendor cloud. - The district's insurance requires documented lockdown capability with a 5-second response time.
1. Which two IoT constraints create the MOST tension in this deployment:
2. The insurer requires lockdown capability; the vendor requires cloud connectivity. Describe the architectural tradeoff and ONE recommended middle-ground control:
3. What specific planning item should be in place BEFORE the 7-year firmware support window ends:
(1) Two constraints in tension: (a) Limited resources — the microcontroller cannot run additional on-device defenses, so protection must be network-level. (b) Long lifecycle — school infrastructure is typically budgeted for 10–15 years, but the vendor only guarantees firmware support for 7. That gap is the planning problem.
(2) Tradeoff and middle-ground control: The insurer wants cloud-dependent reliable lockdown; the vendor will not sell on-prem control. The genuine architectural tradeoff is cloud availability vs. local survivability. A reasonable middle-ground: require the vendor to support a local lockdown fallback triggered by a keyed admin console on district premises, independent of cloud reachability. Pair it with strict egress filtering so each lock can ONLY reach the vendor cloud endpoint and nothing else; monitor SIEM for unexpected destinations. This preserves the insurer’s lockdown SLA even during cloud outages and limits damage if a lock is ever compromised.
(3) Planning before the 7-year end-of-support: Document a concrete decision checkpoint at year 5 with three pre-approved paths: (1) renew vendor support if available, (2) replace the fleet with a successor product, or (3) reclassify the locks as legacy, re-segment them more tightly, and plan for phased replacement — with budget already earmarked. The failure mode you want to avoid is arriving at year 7 with no plan and 4,200 unpatchable locks controlling classroom security.
Scoring rubric: 1 pt for naming any two of the four constraints with clear reasoning, 1 pt for a plausible middle-ground control (local lockdown fallback, egress filtering, or documented cloud-dependency acceptance), 1 pt for a concrete end-of-support plan. 2+/3 = passing.
Each case reinforces a different AP Cyber question archetype: Case 1 is the classic “find the gaps in a sloppy IoT rollout.” Case 2 is the harder “evaluate a strong design and identify what’s still missing,” which AP FRQ-style questions increasingly favor. Case 3 tests your ability to reason about tradeoffs rather than “pick the one right answer,” which is a skill the AP exam rewards on its higher-complexity items.
Get in Touch
Whether you're a student, parent, or teacher — I'd love to hear from you.
Just want free AP CS resources?
Enter your email below and check the subscribe box — no message needed. Students get daily practice questions and study tips. Teachers get curriculum resources and teaching strategies.
Message Sent!
Thanks for reaching out. I'll get back to you within 24 hours.
Prefer email? Reach me directly at [email protected]