On-Premises vs. Cloud Security — Decision Matrix
| Factor | Cloud | On-Premises | Exam Tip |
|---|---|---|---|
| Physical infrastructure security | Provider's responsibility | Organization's responsibility | IaaS = customer owns OS up; physical = provider always |
| Hardware management | No hardware to manage — provider supplies it | Organization purchases, racks, maintains all hardware | Cloud eliminates hardware attack surface for customer |
| Data sovereignty | Requires provider selection + configuration controls | Full — data never leaves premises | Government/classified often requires on-prem |
| Security customization | Limited to platform options | Complete — any tool can be deployed | Niche security tools → on-prem advantage |
| Speed of change | Fast — API-driven, no procurement | Slow — procurement + deployment cycles | Emergency security patches faster in cloud |
| Cost model | OpEx — pay as you go | CapEx — large upfront hardware investment | Cloud = lower upfront; on-prem = lower long-term at scale |
| Multi-tenancy risk | Present — shared infrastructure | None — dedicated infrastructure | Side-channel attacks more relevant in cloud |
| Attacker perspective | Irrelevant — attackers target data regardless of location | Controls matter; location does not | |
Virtualization Stack vs. Containerization Stack
| Layer | Virtualization | Containerization |
|---|---|---|
| Top (Applications) | App A, App B, App C (one per VM) | App A through App G (many per host) |
| OS Layer | Guest OS per VM (full OS — Windows, Linux, etc.) | No per-container OS — containers share host kernel |
| Abstraction Layer | Hypervisor (VMware ESXi, Hyper-V, KVM) | Container Engine (Docker, containerd, Podman) |
| Host OS | No host OS for Type 1 hypervisor (bare-metal) | Host Operating System (single OS shared by all containers) |
| Bottom (Hardware) | Infrastructure (physical servers) | Infrastructure (physical servers) |
Virtualization vs. Containerization — Security Comparison
| Characteristic | Virtualization (VMs) | Containerization |
|---|---|---|
| OS per workload | Full guest OS per VM — high resource overhead | Shared host OS kernel — minimal overhead |
| Startup time | Minutes (full OS boot sequence) | Milliseconds (process launch) |
| Isolation boundary | Hardware abstraction — hypervisor enforces VM boundary | OS namespaces/cgroups — kernel enforces container boundary |
| Isolation strength | Strong — hypervisor separates at hardware level | Strong but narrower — all containers share one kernel |
| Worst-case security failure | VM escape — attacker breaks out of guest OS to hypervisor or other VMs | Container escape — attacker breaks out to host OS, affecting all containers |
| Kernel vulnerability impact | Isolated per VM — guest OS kernel vuln affects only that VM | Shared — host kernel vuln potentially affects all containers |
| Image size | Large (GB — includes full OS) | Small (MB — application + dependencies only) |
| Best use case | Mixed OS environments, strong isolation requirements, legacy apps | Cloud-native apps, microservices, rapid scaling |
Specialized Infrastructure Type Reference
| Type | Definition | Examples | Security Risk | Primary Control |
|---|---|---|---|---|
| IoT | Network-connected devices for sensing, automation, data collection — designed by domain specialists, not security engineers | Smart thermostats, video doorbells, wearables, facility automation, industrial sensors | Weak defaults, no update mechanism, unencrypted comms, single device = network foothold | Dedicated IoT VLAN; treat as untrusted endpoint; disable unused services; replace end-of-life devices |
| SCADA/ICS | Supervisory Control and Data Acquisition — monitors and controls industrial physical processes at scale | Power grids, oil refineries, water treatment, manufacturing lines, railways | Cyberattack = physical destruction, safety incident, critical service disruption | Physical air gap from IT network; no direct internet; strict change management; jump server with logging for any access |
| RTOS | Deterministic OS — guarantees task completion within strict time windows | ABS/airbags in cars, industrial robot controllers, pacemakers, military guidance | Security tools incompatible with timing requirements; disruption = safety failure; difficult to patch | Physical and network isolation; no general-purpose connectivity; physical security for device access |
| Embedded System | Purpose-built hardware+software for one function; no general-purpose OS; cannot load arbitrary software | Traffic light controllers, digital watches, MRI scanners, industrial actuators | Long lifecycle with unpatched firmware; no monitoring; minimal update mechanism | Network isolation; compensating controls at network boundary; lifecycle policy for end-of-support tracking |
High Availability — Redundancy vs. HA vs. Active/Active
| Concept | Definition | Failover | Downtime on Failure | Cost | Example |
|---|---|---|---|---|---|
| Redundancy | Spare system available in case primary fails | Manual — staff must bring spare online, configure, and connect | Minutes to hours (manual intervention) | Lower — spare hardware only | Spare switch in storage room; cold standby server |
| Active/Passive HA | Primary handles traffic; standby is synchronized and ready; automatic failover | Automatic — failover in seconds | Seconds (automatic failover) — brief interruption possible | Medium — standby hardware + synchronization infrastructure | Firewall HA pair; primary/standby database cluster |
| Active/Active HA | Both systems handle traffic simultaneously; load shared; neither is a "standby" | None needed — surviving node absorbs full load seamlessly | Zero — surviving node was already handling traffic | Highest — both nodes must handle full load individually | Active/active load-balanced web servers; clustered databases |
IoT Security Controls Checklist
| Control | Implementation | Addresses |
|---|---|---|
| Network isolation | Place all IoT devices on a dedicated VLAN with ACLs blocking access to corporate systems | Foothold-to-lateral-movement path — compromised device cannot reach corporate network |
| Default credential change | Change all factory default usernames and passwords before deployment; disable accounts that cannot be changed | Credential-based compromise — most IoT attacks use factory defaults |
| Firmware update management | Subscribe to vendor security advisories; apply firmware updates as released; replace devices with no update support | Known vulnerabilities in unpatched firmware |
| Disable unnecessary services | Audit open ports and services on IoT devices; disable any service not required for the device's function (Telnet, unused web interfaces) | Unnecessary attack surface on each device |
| Inventory and lifecycle tracking | Maintain a complete inventory of all IoT devices including model, firmware version, and end-of-support date | Unknown devices on network; continued use of end-of-life devices with no update path |
| Encrypted communications | Verify IoT devices use encrypted protocols for data transmission; avoid devices that transmit in plaintext | Network interception of sensor data or control commands |
Centralized vs. Decentralized Management Tradeoffs
| Aspect | Centralized | Decentralized |
|---|---|---|
| Alert visibility | Correlated across all systems — cross-source attack patterns visible | Siloed — events in one system invisible to another |
| Log analysis | Single query spans entire environment | Requires manual correlation across multiple interfaces |
| Patch management | Unified view of patch status across all systems | Each system managed independently — gaps easily missed |
| Failure impact | Console failure = loss of visibility across entire environment | Individual system failure affects only that system's visibility |
| Scalability | Console must scale with log and alert volume growth | Each system scales independently |
| Attack target value | High — compromising the console = visibility into everything | Lower — each system is a separate target |