Compare and contrast security implications of different architecture models
Every architecture model has different security tradeoffs. The exam tests whether you can evaluate which model fits a given scenario and what security controls each requires.
Cloud Models
Infrastructure as a Service (IaaS)
Provider manages: physical hardware, networking, virtualization. Customer manages: OSOperating System — System software managing hardware and applications, middleware, runtime, applications, data.
- Most control, most responsibility. You patch the OSOperating System — System software managing hardware and applications, configure firewalls, manage access.
- Examples: AWS EC2, Azure VMs, Google Compute Engine
- Security implication: Misconfiguration is on you. A misconfigured security group is your problem, not the provider’s.
Platform as a Service (PaaS)
Provider manages: everything in IaaSInfrastructure as a Service — Cloud: provider manages hardware, you manage OS and up + OSOperating System — System software managing hardware and applications, middleware, runtime. Customer manages: applications and data.
- Less control, less operational burden. Provider handles patching the underlying platform.
- Examples: AWS Elastic Beanstalk, Azure App Service, Heroku
- Security implication: You can’t harden the OSOperating System — System software managing hardware and applications directly. Trust the provider’s security or don’t use the platform.
Software as a Service (SaaS)
Provider manages: everything. Customer manages: data and user access configuration.
- Least control. You configure the application; the provider runs everything underneath.
- Examples: Microsoft 365, Salesforce, Google Workspace
- Security implication: Your security levers are limited to access controls, data policies, and APIApplication Programming Interface — Interface for software-to-software communication integrations. Shadow ITInformation Technology — Broad term for computing infrastructure and services risk — users adopt SaaSSoftware as a Service — Cloud: provider manages everything, you configure without ITInformation Technology — Broad term for computing infrastructure and services approval.
Anything as a Service (XaaS)
Catch-all for other service models: Security as a Service (SECaaSSecurity as a Service — Cloud-delivered security services), Desktop as a Service (DaaSDesktop as a Service — Cloud-hosted virtual desktops), etc.
Shared Responsibility Model
The single most important concept in cloud security:
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Data | Customer | Customer | Customer |
| Application | Customer | Customer | Provider |
| OSOperating System — System software managing hardware and applications/Runtime | Customer | Provider | Provider |
| Infrastructure | Provider | Provider | Provider |
| Physical | Provider | Provider | Provider |
Exam trap: Questions will describe a cloud security incident and ask who’s responsible. Data classification and access control are ALWAYS the customer’s responsibility regardless of model.
Deployment Models
Public Cloud
Shared infrastructure operated by a third-party provider. Multi-tenant — your workloads run alongside other customers’.
- Cost-effective, scalable, but you share the physical infrastructure
Private Cloud
Dedicated infrastructure for a single organization. Can be on-premises or hosted.
- More control, higher cost. May be required for compliance (HIPAAHealth Insurance Portability and Accountability Act — US healthcare data protection law, classified data)
Hybrid Cloud
Combination of public and private. Workloads move between them based on requirements.
- Sensitive data stays private; burstable/scalable workloads go public
- Security challenge: Consistent policy enforcement across both environments
Community Cloud
Shared infrastructure for organizations with common requirements (e.g., government agencies, healthcare providers).
On-Premises
All infrastructure owned, operated, and maintained in your own facilities.
- Full control, full responsibility. You own every layer of the stack.
- Security advantage: Data never leaves your physical control
- Security disadvantage: You need the expertise and budget for every aspect of security
- Increasingly rare as a pure model — most orgs are hybrid
Edge and Fog Computing
Edge Computing
Processing data near the source (IoTInternet of Things — Connected devices (cameras, sensors, appliances) devices, local gateways) rather than in a central data center.
- Reduces latency, reduces bandwidth to central systems
- Security challenge: Many distributed nodes, each a potential attack surface. Physical security of edge devices is often weak.
Fog Computing
Intermediate layer between edge devices and the cloud. Local processing with cloud coordination.
- Aggregates and pre-processes edge data before sending to cloud
Containerization and Microservices
Containers
Lightweight, isolated environments that package an application with its dependencies.
- Docker, Podman, containerd
- Share the host OSOperating System — System software managing hardware and applications kernel (unlike VMs which have their own OSOperating System — System software managing hardware and applications)
- Security considerations:
- Container escape vulnerabilities (breaking out to the host)
- Image security — base images may contain vulnerabilities
- Registry security — only pull from trusted registries
- Least privilege — containers shouldn’t run as root
- Immutable deployments — don’t patch running containers, replace them
Microservices
Architecture pattern where an application is composed of small, independent services communicating via APIs.
- Each service can be developed, deployed, and scaled independently
- Security considerations:
- Service-to-service authentication (mTLSMutual TLS — Both client and server authenticate via certificates, service mesh)
- APIApplication Programming Interface — Interface for software-to-software communication security for every service boundary
- Increased east-west traffic that must be monitored
- More components = larger attack surface to manage
Serverless
Functions that run on-demand without managing servers. Provider handles all infrastructure.
- AWS Lambda, Azure Functions, Cloudflare Workers
- Security considerations: Execution environment is ephemeral. You control the code; the provider controls everything else. Function permissions must follow least privilege. Cold-start timing can leak information.
Infrastructure as Code (IaC)
Defining infrastructure through machine-readable configuration files rather than manual setup.
- Terraform, CloudFormation, Pulumi, Ansible
- Security benefit: Repeatable, auditable, version-controlled deployments. Drift detection catches unauthorized changes.
- Security risk: IaCInfrastructure as Code — Defining infrastructure through configuration files templates with hardcoded secrets or overly permissive defaults become a vulnerability at scale.
Software-Defined Networking (SDN)
Separating the control plane (routing decisions) from the data plane (packet forwarding).
- Centralized network management, programmable policies
- Security benefit: Granular microsegmentation, rapid policy changes, consistent enforcement
- Security risk: The SDNSoftware-Defined Networking — Separating network control plane from data plane controller is a high-value target — compromise it and you control the entire network
Centralized vs. Decentralized Architecture
| Aspect | Centralized | Decentralized |
|---|---|---|
| Processing | Single location / data center | Distributed across multiple locations |
| Control | Central authority manages all components | Individual nodes operate semi-autonomously |
| Latency | Higher for remote users | Lower (processing closer to users) |
| Single point of failure | Yes — central system down = everything down | No — individual node failure is localized |
| Security management | Easier — one place to secure, monitor, patch | Harder — many locations to secure and monitor |
| Consistency | Uniform policy enforcement | Policy enforcement may vary by node |
| Examples | Mainframe, centralized SIEMSecurity Information and Event Management — Centralized log collection, correlation, and alerting, single-DC architecture | CDN, blockchain, edge computing, mesh networks |
Exam tip: Centralized is easier to secure but has availability risk. Decentralized is more resilient but harder to secure consistently. Most real architectures are hybrid.
Real-Time Operating Systems (RTOS)
An RTOSReal-Time Operating System — OS for time-critical embedded/industrial systems guarantees that operations complete within a defined time constraint. “Real-time” means deterministic — the system will respond within a guaranteed deadline, every time.
Where RTOS Is Used
- Industrial control systems (PLCs, robotic arms)
- Medical devices (pacemakers, infusion pumps)
- Automotive systems (ABS, engine management, autonomous driving)
- Aerospace and defense (flight control, weapons systems)
- Network equipment (some router/switch firmware)
Security Implications
- Limited patching: RTOSReal-Time Operating System — OS for time-critical embedded/industrial systems devices often can’t be updated without recertification (medical, aerospace). Known vulnerabilities may persist indefinitely.
- No traditional security tools: Can’t install AV, EDREndpoint Detection and Response — Monitors endpoints for threats and enables response, or agents on an RTOSReal-Time Operating System — OS for time-critical embedded/industrial systems — not enough resources, and any added overhead could violate timing guarantees.
- Long lifecycles: RTOSReal-Time Operating System — OS for time-critical embedded/industrial systems devices may run for 15-25 years. The security landscape will change dramatically during that period.
- Network exposure increasing: Devices originally designed for isolated environments are increasingly network-connected for monitoring and management.
- Compensating controls: Segment aggressively, monitor network traffic for anomalies, restrict physical access, implement protocol-aware firewalls for OTOperational Technology — Hardware/software monitoring and controlling physical processes traffic.
SCADA/ICS and Embedded Systems
Industrial Control Systems (ICS)
Systems that manage physical processes — power grids, water treatment, manufacturing.
SCADA (Supervisory Control and Data Acquisition)
Specific type of ICSIndustrial Control System — Systems managing physical industrial processes for remote monitoring and control of industrial processes.
- Often legacy systems with long lifecycles (15-25 years)
- May run outdated, unpatched operating systems
- Originally designed for isolated networks, now increasingly connected
- Security considerations:
- Air gapping (physical isolation) where possible
- Network segmentation between ITInformation Technology — Broad term for computing infrastructure and services and OTOperational Technology — Hardware/software monitoring and controlling physical processes (Operational Technology)
- Availability is the priority — downtime can cause physical damage or safety hazards
- Patching is complex — requires maintenance windows and vendor coordination
IoT (Internet of Things)
Connected devices: cameras, sensors, smart appliances, medical devices.
- Often have weak default credentials, limited update mechanisms, minimal security features
- Massive attack surface — billions of devices, many unmanaged
Offensive Context
Architecture choices determine the attack surface before a single line of code is written. An attacker evaluating a target asks: cloud or on-prem? What’s the shared responsibility boundary? Are containers hardened or running default Docker Hub images as root? Is the ICSIndustrial Control System — Systems managing physical industrial processes network truly air-gapped or is there a forgotten VPNVirtual Private Network — Encrypted tunnel over public networks bridge? The architecture model you choose doesn’t just affect how you defend — it determines what the attacker targets first.