4.4.2. Cloud, ICS, and IoT Vulnerabilities

💡 First Principle: The further a system deviates from a traditional managed IT environment — in terms of physical control, update capability, and operational constraints — the more its vulnerability profile diverges from standard assessment frameworks, requiring domain-specific analysis.

Cloud-Specific Vulnerabilities

The shared responsibility model creates a boundary that organizations frequently misunderstand. Misconfigured storage is the single most common cloud vulnerability. Overprivileged IAM roles represent the cloud equivalent of running services as root. Data sovereignty and residency create compliance vulnerabilities with no on-premises equivalent.

Deployment models (NIST SP 800-145): public (multi-tenant, rented by any customer), private (dedicated to one organization), community (shared by organizations with common requirements, e.g., hospitals under the same compliance regime), hybrid (two or more models bound together, e.g., a private cloud that bursts to public cloud at peak).

Cloud Security Posture Management (CSPM) continuously evaluates cloud resource configuration against policy and benchmarks (e.g., CIS) and alerts when a misconfiguration appears — a bucket made public, logging disabled. A SIEM correlates the events it receives; it does not assess configuration state, so it cannot flag a setting that generates no events.

Instance metadata and SSRF: a server-side request forgery flaw can make a cloud VM fetch its own metadata service and leak the temporary credentials of its IAM role. AWS IMDSv2 requires a session token obtained with a PUT request first, which a simple SSRF GET cannot perform; least-privilege instance roles limit what any stolen credentials can reach.

ICS/SCADA Vulnerabilities

The Purdue Model provides the architectural framework for ICS network segmentation — five levels from Enterprise (Level 5) down to Physical Process (Level 0). The critical security principle: traffic should only flow between adjacent levels, with a DMZ between Level 3 (OT) and Level 4 (IT).

Air-gapping limitations: Stuxnet demonstrated that air gaps are bridged through removable media, supply chain compromise, and maintenance laptops. Protocol vulnerabilities: Modbus, DNP3, and OPC Classic include no authentication, no encryption, and no integrity verification. Safety versus security trade-offs: In ICS, shutting down a running process can cause physical harm — safety instrumented systems must remain operational even during a security incident.

IoT Vulnerabilities

Constrained devices cannot run endpoint protection agents, cannot support TLS certificate validation, and frequently ship with default credentials and no patch mechanism. Network segmentation as a compensating control is the primary defense — because you cannot secure the devices themselves, you secure the network around them with dedicated VLANs, microsegmentation, IoT gateways, and NAC. Researchers and attackers assess these devices by dumping the firmware from the flash chip, unpacking it (e.g., with binwalk) and analyzing the binaries offline — routinely finding hardcoded credentials and cloud keys, years-old kernels and libraries, and undocumented or unauthenticated services, the signature of ship-and-forget development.

⚠️ Exam Trap: The shared responsibility model does NOT mean the cloud provider handles "cloud security." The customer is ALWAYS responsible for data classification, access management, and identity configuration regardless of the service model. Exam questions describing a data breach from a misconfigured S3 bucket are testing whether you understand this is a customer responsibility, not a provider failure.

Reflection Question: An energy company asks you to assess the security of their SCADA network controlling natural gas pipelines. The operations team insists the network is "air-gapped" and therefore immune to cyber threats. What specific evidence would you look for to validate or challenge this claim?