14.4 Secure and Monitor Internet of Things
Key Takeaways
- SSCP Knowledge Area 6.7 is secure and monitor Internet of Things (IoT): configuration, network isolation, firmware updates, and End of Life (EOL) management.
- Default passwords on cameras, badges, HVAC, and pumps are live credentials. Inventory and unique secrets are day-zero work, not a later hardening project.
- Isolation is the control that saves the EHR: IoT/OT VLANs and firewall zones must not initiate sessions to clinical databases. Cameras talk to the video management system, not to the chart.
- Firmware updates need a signed source, a change window, and a path that does not require exposing the device to the whole Internet via Universal Plug and Play.
- Vendor cloud connectivity and EOL are risk decisions: know what leaves the building, and replace or isolate devices the vendor will no longer patch.
Secure and monitor Internet of Things
Knowledge Area 6.7 is a single outline sentence with a dense example list: Secure and monitor Internet of Things (IoT) — configuration, network isolation, firmware updates, End of Life (EOL) management. Domain 6 remains 16% of the SSCP. IoT is how a $40 camera becomes a foothold on a network that also runs the electronic health record (EHR).
IoT here is any networked device that is not a general-purpose, actively managed workstation: cameras, badge readers, HVAC controllers, smart TVs in waiting rooms, printers, time clocks, consumer "smart" plugs a well-meaning staff member bought, and many operational technology (OT) boxes (building management, lab instruments) that share the same failure modes. Medical devices add vendor-change-control and safety constraints; they do not get a pass on default passwords. You are not being asked to design a full Purdue industrial model. You are being asked to keep a camera from talking to an EHR database.
Configuration: defaults, inventory, and the vendor cloud
Unconfigured IoT is an account you published.
| Configuration item | What to do | What goes wrong if you skip it |
|---|---|---|
| Inventory | Asset tag, owner, VLAN, IP, firmware, data classification, vendor | You cannot isolate or patch a device you do not know is on the switch |
| Default credentials | Unique passwords or certificates; vault them; disable anonymous | admin/admin, root/pass, printed default on a sticker — internet-wide scanners know these |
| Unused services | Disable Telnet, Universal Plug and Play (UPnP), unused HTTP, Server Message Block (SMB) file shares, guest Wi-Fi on the camera | UPnP punches holes in consumer-grade NAT; SMB on a printer is ransomware adjacency |
| Management path | HTTPS/SSH from a jump host on the IoT management VLAN; no WAN management | In-band admin on the clinical VLAN is 6.4's mistake applied to cameras |
| Time and logs | NTP; syslog to a collector the camera cannot wipe | After an incident you will not have a timeline |
| Vendor cloud | Know whether the device phones home, what it sends, where the tenant lives, and who has the cloud admin password | A camera "in the hallway" is also a stream in a vendor Software as a Service (SaaS) region you never reviewed |
Default passwords are the 6.7 item that shows up as a scenario, not a definition. New cameras, a cheap NVR, a networked badge panel — they ship with a published default. Changing it is configuration, not "advanced hardening." So is turning off the feature that lets the device register itself to a consumer cloud with the installer's personal email.
Vendor cloud is a third-party connection (Domain 2 trust architectures) that 6.7 forces you to notice. Many cameras will not record without a vendor account. That account is an identity with a password reset path, often multi-factor authentication (MFA)-optional, that can pan-tilt-zoom a clinic. Data residency, Business Associate Agreement (BAA) for anything that might capture patients, and whether the device still works if you firewall the cloud (it often does not) belong in procurement, not in a panicked ACL after the first breach article. If the vendor requires cloud, isolate so the camera can reach only that vendor and the video management system (VMS), not the EHR, and put the vendor destination in the firewall log.
Scenario — default admin and a helpful cloud. Facilities hangs eight cameras on the nearest switch "so security can see the loading dock." They leave admin/12345, enable UPnP, and scan a QR code that attaches the cameras to a consumer vendor cloud. The cameras get DHCP on the same VLAN as EHR workstations. That is a 6.7 configuration failure and a 6.4/6.7 isolation failure. Before anyone talks about AI analytics on the video, change the secrets, inventory the MAC addresses, disable UPnP, and move the ports.
Network isolation: IoT/OT VLANs are not a clinical integration
Network isolation is the control that makes a compromised camera boring. It is 6.4 segmentation applied to a class of devices that cannot run your endpoint detection and response (EDR) agent.
| Isolation pattern | Allowed flows | Explicitly denied |
|---|---|---|
| IoT VLAN + firewall zone | Camera → VMS (for example RTSP/TCP 554 or the vendor's ports); jump host → camera HTTPS | Camera → EHR, camera → domain controller, camera → Internet except the vendor update/cloud destinations you named |
| OT VLAN | Building system → its server; historian as designed | OT → EHR, OT → guest Wi-Fi, unrestricted OT → Internet |
| Printer VLAN | Workstations → print; print → syslog | Printer → file servers with SMB write, printer → Internet firmware "phone home" unless you allow a proxy |
| Medical device VLAN | Device → its approved clinical server | Device → general workstation VLAN, device → email |
| Air-gap / physically separate switch | Only when the risk and the workflow truly require it | Fake air-gap: two VLANs on one core with permit ip any any |
Micro-segmentation still helps: two cameras should not Secure Shell (SSH) to each other. Network Access Control (NAC) (6.5) can fingerprint a camera and dump it into the IoT VLAN automatically — if you built that policy. If NAC is "allow if it has an agent," the camera has no agent and lands on guest or, worse, on voice.
Scenario — camera VLAN talking to the EHR. A week after install, firewall logs show 10.70.12.0/24 (cameras) SYN-scanning 10.30.8.40:1433 (EHR database). That is not HL7. That is not "the VMS needs SQL." That is a segmentation failure: the IoT zone has a route and a permit to a PHI database. Containment is an ACL/zone change today: cameras may speak only to the VMS and, if required, a patch proxy. Investigation is 6.7 plus Domain 4: was a camera already owned (default password, old firmware), and what else did it scan? Do not open 1433 "to complete the clinical workflow." Do not assume the vendor cloud NAT will drop scans that never left the hospital.
Isolation is also how you monitor. A zone that should be quiet (cameras to one VMS subnet) makes security information and event management (SIEM) detections cheap: any camera-to-EHR, camera-to-DNS-Internet, or camera-to-SMB is an event of interest (Domain 3). A flat network makes those events indistinguishable from "Tuesday."
Firmware updates and End of Life management
IoT fails on a different patch clock than Windows.
Firmware updates are how you close the CVE that default-password scanners did not already use. The operations bar:
- Know the version. Inventory is the prerequisite. "The cameras are fine" is not a version.
- Get it from the vendor, signed if they offer signing. Random firmware from a forum is how you brick a fleet or install a backdoor.
- Test on one device in a window that does not take down every hallway at once.
- Use a controlled path. A jump host or update proxy pulls the file; the camera does not need general Internet. UPnP port-forward "so the vendor can push" is not a patch program.
- Change-control medical and safety devices. A pump firmware update is a clinical change, not only an IT change. The SSCP still owns the network isolation while that process runs; you do not skip isolation because the FDA-cleared device is "validated" on an old stack.
If a device cannot be patched (no vendor path, no window, no signing), it is already in the EOL conversation even if marketing still sells it.
End of Life (EOL) management is the last outline example and the one organizations skip because the camera still produces video. EOL means the vendor will not ship security firmware. Every new CVE in that chipset is now yours forever.
| EOL decision | When it is acceptable | When it is not |
|---|---|---|
| Replace | Default for anything that can reach PHI, payment, or identity, or that is Internet-facing | "Next fiscal year" with no isolation in the meantime |
| Isolate and compensate | Temporary: no route off the IoT zone except VMS, extra monitoring, disabled unused services, unique creds, maybe a bump-in-the-wire firewall | Leaving the EOL camera on the EHR VLAN because "it still works" |
| Accept | Only with a named risk owner, a date, and a scope that cannot touch PHI | Informal acceptance in a facilities Slack channel |
| Ignore | Never | The video is up, so security must be up |
EOL is the same lifecycle idea as Domain 1 asset management, applied to devices that outlive their vendor. A compensating control is time-boxed. "We will micro-segment later" is not a control.
Scenario — vendor declared EOL. The camera vendor's letter says support and firmware end in ninety days. The loading-dock views still work. Facilities wants to keep them through next winter. The SSCP answer is not "they still work." Treat EOL as replace or isolate: pull them off any path to EHR and identity, monitor the zone, and put replacement on a dated plan. Disabling logs so the unpatched cameras generate fewer tickets is concealment, not risk treatment. Moving them to a public DMZ with default passwords so the vendor cloud can still reach them is the opposite of isolation.
Monitor what you isolated
6.7 says secure and monitor. After isolation, watch:
- New MAC addresses on the IoT switch (rogue consumer plugs).
- Flows that violate the zone (camera → 1433, camera → 445, camera → unexpected countries).
- Vendor-cloud volume spikes (exfiltration disguised as "cloud backup").
- Authentication failures on the VMS and on the cameras themselves.
- Firmware version drift against the inventory.
NAC, firewall logs, and a lightweight network detector on the IoT SPAN are the 6.5 tools reused here. Do not put a full inline IPS in fail-closed on a safety-critical OT segment without an availability decision — 6.4 placement still applies. Do put something that will tell you when a camera scans the EHR.
Exam traps for 6.7
- "Cameras do not store PHI" as a reason to skip isolation (they sit on a path to PHI, and video of patients can be PHI).
- UPnP and Internet port-forwards as a firmware strategy.
- VLAN ID without an ACL as isolation.
- Treating vendor cloud as out of scope because the camera is "on prem."
- EOL devices as acceptable because the picture still moves.
When you sit the item, ask: did we change the default, can this thing route to the EHR, how does firmware get here, and who owns the day the vendor quits?
New IP cameras still use the vendor default admin password and received DHCP on the same virtual local area network as electronic health record workstations. What should the SSCP do first under Knowledge Area 6.7?
The camera vendor sends an End of Life notice: no further firmware. The loading-dock views still work. What is the SSCP risk decision?
Firewall logs show hosts in the camera subnet SYN-scanning the electronic health record database on TCP/1433. What does that indicate, and what is the correct network response?