Simple explanation
Where and how a system is built changes what security looks like. This lesson covers the major deployment/architecture models you'll be asked to compare — cloud, on-premises, hybrid, containerized, and specialized environments like ICS/SCADA and IoT.
Technical explanation
- Cloud service models: IaaS (Infrastructure as a Service — you manage the OS up; provider manages hardware), PaaS (Platform as a Service — you manage just the application/data; provider manages the runtime), SaaS (Software as a Service — provider manages everything, you just use it). The shared responsibility model shifts as you move from IaaS to SaaS: the provider takes on more security responsibility as they control more of the stack.
- Cloud vs. on-premises vs. hybrid — trade-offs in control, cost model (capex vs. opex), and who's responsible for what.
- Third-party vendors — any external party managing part of your infrastructure inherits some of your risk.
- Infrastructure as Code (IaC) — defining infrastructure through version-controlled configuration files rather than manual setup, enabling repeatable, auditable deployments.
- Serverless — code runs in provider-managed, ephemeral compute without you managing servers at all.
- Microservices — an application broken into many small, independently deployable services rather than one large monolith; each has its own attack surface.
- Network infrastructure: physical isolation (air-gapped — no network connection to anything else at all), logical segmentation (separated via VLANs/software while sharing physical infrastructure), Software-Defined Networking (SDN) (network control decoupled from hardware, managed centrally through software).
- On-premises — infrastructure physically owned and operated by the organization.
- Centralized vs. decentralized — a single point of control/failure vs. distributed control.
- Containerization — packaging an application with its dependencies (Docker-style) for consistent deployment; lighter-weight than full virtualization since containers share the host OS kernel.
- Virtualization — running multiple isolated virtual machines on shared physical hardware via a hypervisor.
- IoT — internet-connected devices, often with limited built-in security and long deployment lifespans.
- ICS/SCADA — Industrial Control Systems / Supervisory Control and Data Acquisition, used to manage physical industrial processes (power grids, water treatment); often prioritize availability so heavily that security patching is deferred, since downtime has real-world physical consequences.
- RTOS — Real-Time Operating System, used where processing must happen within a guaranteed, predictable time window (medical devices, industrial control).
- Embedded systems — purpose-built computers inside another device (a smart thermostat, a car's engine control unit).
- High availability — architecture designed to minimize downtime through redundancy.
Considerations when choosing an architecture: availability, resilience, cost, responsiveness, scalability, ease of deployment, risk transference (shifting risk to a cloud provider via contract), ease of recovery, patch availability, inability to patch (some embedded/ICS systems simply can't be patched without replacing hardware), power, and compute requirements.
Synonyms / related terms
| Term | Means | |---|---| | Air-gapped | Physically isolated, no network connection | | Hypervisor | Software that creates and manages virtual machines | | SCADA | Often used interchangeably with ICS, though SCADA is technically a subset focused on data acquisition/monitoring |
Concept Check
"A water treatment facility's control system has known vulnerabilities but hasn't been patched in three years. Why might this be an accepted risk rather than a failure?" It's tempting to call this simple negligence, but ICS/SCADA environments often prioritize continuous availability so strongly that any patch requiring downtime is deferred — a legitimate (if uncomfortable) architecture trade-off, not automatically a mistake.
Interview-style Q&A
Q: When would you choose containers over full virtual machines? A: "When I need faster startup times and higher density — containers share the host kernel instead of each running a full guest OS, so they're lighter weight. I'd still choose full VMs when I need stronger isolation between untrusted workloads, since containers share more of the underlying OS."
Memory trick
"I Paas the Saas" — say IaaS → PaaS → SaaS in that order and picture control shifting away from you at each step, toward the provider.