Cloud Deployment Models
| Model | Who Manages Infrastructure | Use Case | Security Concern |
|---|---|---|---|
| Public Cloud | Cloud provider (AWS, Azure, GCP) | Startups, dev/test, variable workloads | Shared responsibility confusion; multi-tenancy |
| Private Cloud | Organization itself | Regulated industries (healthcare, finance) | Higher cost; internal management complexity |
| Hybrid Cloud | Both — on-prem + public cloud | Burst capacity; data sovereignty | Complex security boundaries; data transit risks |
| Community Cloud | Shared among similar orgs | Government agencies, research institutions | Shared risk across organizations |
Cloud Service Models
| Model | You Manage | Provider Manages | Example |
|---|---|---|---|
| IaaS (Infrastructure as a Service) | OS, apps, data, runtime | Physical hardware, networking, storage | AWS EC2, Azure VMs |
| PaaS (Platform as a Service) | Application code, data | OS, runtime, middleware, infrastructure | AWS Elastic Beanstalk, Heroku |
| SaaS (Software as a Service) | Data configuration only | Everything else | Microsoft 365, Salesforce, Gmail |
| FaaS (Function as a Service) | Function code only | Execution environment, scaling | AWS Lambda, Azure Functions |
• IaaS: Provider secures hardware → you patch the OS
• SaaS: Provider secures everything → you manage user access and data classification
Exam Tip: Misconfiguring cloud settings (open S3 bucket, excessive IAM permissions) is the customer's responsibility — not the cloud provider's.
Virtualization Concepts
- Hypervisor Type 1 (Bare-metal): Runs directly on hardware (VMware ESXi, Microsoft Hyper-V, KVM) — more efficient and secure
- Hypervisor Type 2 (Hosted): Runs on a host OS (VirtualBox, VMware Workstation) — less efficient; double attack surface
- VM Sprawl: Unmanaged proliferation of VMs; orphaned VMs accumulate unpatched vulnerabilities
- VM Escape: Malicious code in one VM breaks out of isolation to affect the hypervisor or other VMs
- Snapshot: Point-in-time copy of a VM — useful for recovery but can contain stale credentials if restored
Containerization
Containers share the host OS kernel (unlike VMs which have separate kernels). Key technologies: Docker, Kubernetes (K8s).
- Containers are lighter than VMs but have a larger shared attack surface (shared kernel)
- Container escape: Similar to VM escape — exploiting container runtime to access the host
- Security practices: Run as non-root, use read-only filesystems, scan images for vulnerabilities, use network policies in K8s
- Ephemeral nature: Containers spin up/down frequently — traditional perimeter security is insufficient; use microsegmentation
Internet of Things (IoT)
IoT devices include smart thermostats, cameras, medical devices, industrial sensors, smart TVs, and more.
- Weak default credentials (often hardcoded, never changed)
- No security update mechanism or end-of-life quickly
- Constrained resources (no CPU/memory for full TLS or EDR agents)
- Physical accessibility — devices deployed in uncontrolled environments
- Wide variety of protocols (MQTT, CoAP, Zigbee, Z-Wave) with varying security
Countermeasures: Network segmentation (IoT VLAN), change default credentials, firmware updates, network monitoring, disable unused features.
SCADA / ICS (Industrial Control Systems)
- SCADA: Supervisory Control and Data Acquisition — monitors/controls industrial processes (power grids, water treatment, oil pipelines)
- ICS: Broader category including SCADA, DCS (Distributed Control Systems), and PLCs (Programmable Logic Controllers)
- Security Challenges: Legacy systems (20–30 year lifespans), availability over security (can't patch/restart a running power grid), proprietary protocols
- Notable Attack: Stuxnet — targeted Iranian nuclear centrifuges via PLCs; Ukrainian power grid attacks (2015/2016)
- Countermeasures: Air gapping, network segmentation, unidirectional data diodes, strict change control, out-of-band management
Embedded Systems
Purpose-built computing systems integrated into a device (HVAC controllers, medical devices, vehicle ECUs, smartcards).
- Limited resources constrain security tooling
- Real-Time Operating Systems (RTOS) — must be deterministic, often lack security features
- Long operational lifespans with infrequent updates
- SoC (System on a Chip) — entire computer on a single chip; attack surface includes the chip itself
Serverless / Microservices Architecture
- Serverless: Code runs as functions triggered by events; no server to manage (but not truly serverless — someone else manages it)
- Microservices: Application broken into many small, independently deployable services communicating via APIs
- Security concerns: Inter-service authentication, API security, function injection, insecure function triggers, excessive permissions
Zero Trust Architecture (Revisited — Architecture Perspective)
ZTA moves security from perimeter-based to identity-and-context-based:
- Never Trust, Always Verify: Every access request must be authenticated and authorized
- Least Privilege: Minimum access required for the specific task
- Microsegmentation: Workloads protected individually, not by network zone
- Continuous Validation: Re-verify access during a session, not just at login
- Policy Enforcement Point (PEP): Gateway that enforces access decisions
- Policy Decision Point (PDP): Brain of ZTA — evaluates context and policy to make access decisions