Breakdown 1 — Two ways to slice an architecture (class, Chapter 9 Module B)
From class: Architectures divided by network structure — centralized, decentralized, embedded, mobile — and divided by physical location (on-premises, cloud, hybrid).
| Model | Security implication |
|---|---|
| Centralized | One place to secure and monitor; also one place to fail or attack (single point of failure) |
| Decentralized | Resilient, no single choke point; harder to enforce consistent policy and to monitor |
| On-premises | You own everything — full control, full responsibility (patching, physical security, power) |
| Cloud | Shared responsibility; scalable; you depend on the provider's controls and on third-party vendors |
| Hybrid | Both sets of concerns plus the secure link between them (VPN/direct connect, identity federation) |
Breakdown 2 — Cloud concepts you must know
From class — cloud characteristics: on-demand self-service, broad network access, resource pooling ("think of a buffet"), rapid elasticity (contracts and grows based on need), measured service. Multitenancy = many customers share the same hardware — a compromise or noisy neighbor can affect others ("fire in one apartment").
Service models and the responsibility matrix
| Model | Provider manages | You manage | Class examples |
|---|---|---|---|
| IaaS | Facility, hardware, network, hypervisor | Guest OS, middleware, apps, data, access | — |
| PaaS | + OS and runtime | Apps, data, access | "developers, programmers" |
| SaaS | Everything except your data/config/users | Data, user access, configuration | "Outlook, Office, Adobe" |
From class: On-premises → you're responsible for the most; SaaS → the least. Regardless of model, you always own your data and identity/access decisions.
Third-party vendors: cloud brokers, MSPs, SaaS integrations — every one is supply-chain exposure (5.3).
Breakdown 3 — Modern infrastructure patterns
| Concept | What it is | Security angle |
|---|---|---|
| Infrastructure as code (IaC) | Infrastructure defined in files (Terraform, CloudFormation) | Version-controlled, repeatable, auditable; but a bad template deploys the same hole everywhere |
| Serverless | Run functions without managing servers | Tiny attack surface per function, but heavy dependence on provider IAM/config |
| Microservices | App split into small services talking over APIs | More network surface (API security, service auth, east-west traffic) |
| Containerization | Apps packaged with dependencies, share the host kernel | Image vulnerabilities, registry security, weaker isolation than VMs |
| Virtualization | Type 1 (bare metal) vs. Type 2 (hosted) hypervisors | VM escape, sprawl, snapshot secrets |
| Physical isolation / air gap | "Nothing connected" (class) | Strongest isolation; removable media becomes the vector (sheep dip) |
| Logical segmentation | VLANs, subnets, firewalls | Limits lateral movement |
| Software-defined networking (SDN) | Control plane separated from data plane, programmable | Central policy; the controller is a high-value target |
| High availability | Redundant components, failover, clustering | Availability, at a cost |
Breakdown 4 — Specialized/embedded systems
★ Starred in your notes: "know this picture" (OT ⊃ ICS ⊃ SCADA) · "when the cloud gets compromised it can affect others."
From class — know this picture: OT (operational technology) is the big circle; inside it is ICS (industrial control systems); inside ICS is SCADA (supervisory control and data acquisition) with PLCs and DCS components. "Questions on this topic."
| System | Traits | Security implication |
|---|---|---|
| IoT | Cheap, many, rarely patched, default creds | Segment them; change passwords; NAC |
| ICS / SCADA | Runs factories, utilities; availability is king; legacy protocols (Modbus) | Air-gap or segment; patch windows are rare; monitor passively |
| RTOS (real-time OS) | Deterministic timing (medical, automotive) | Can't tolerate latency from security agents; inability to patch |
| Embedded systems | Fixed-function firmware devices | Firmware updates, long life, limited crypto |
Breakdown 5 — Considerations (the trade-off vocabulary)
Availability · Resilience · Cost · Responsiveness · Scalability · Ease of deployment · Risk transference (cloud/insurance shifts some risk) · Ease of recovery · Patch availability · Inability to patch (OT/RTOS) · Power · Compute.
From class — defense in depth layers: Data → Application → Host → Internal network → Perimeter network (DMZ) → Physical facility → Users and organization. Security by design: secure by design, secure by default, secure in deployment (should be easy to deploy securely), plus communication.
Exam tip: "Who patches the OS in IaaS?" → you. "Provider outage took down a tenant that wasn't attacked" → multitenancy. "Deploy the same secure config 200 times" → IaC. "Can't install an agent because timing is critical" → RTOS. "Nested acronyms" → OT ⊃ ICS ⊃ SCADA.
Quick self-check
- Name the five cloud characteristics. (On-demand, network access, resource pooling, rapid elasticity, measured service.)
- IaaS vs. PaaS: who manages the OS? (IaaS: you. PaaS: provider.)
- What's the risk of centralization? (Single point of failure/attack.)
Sources: 20260917_173221.jpg, 20260917_182442.jpg, 20260917_182448.jpg, 20260917_182454.jpg, 20260917_182502.jpg