Security Architecture Models

On-Premises vs. Cloud

On-premises keeps infrastructure local for maximum control and data custody, but the organization absorbs all capital cost, maintenance, and scaling. Cloud shifts provisioning to a provider for elastic scaling and lower upfront cost, while adding multi-tenancy and shared-responsibility risk.

Cloud Security: Shared Responsibility

Cloud security is shared: the provider secures the underlying infrastructure, while the customer secures its own data, user access, and applications. Misconfigured access or unprotected data stays the customer's liability, not the provider's.

Cloud Security Threats and Mitigations

Core cloud threats and their primary controls:

• →Shared physical server vulnerabilities — multi-tenant hardware; apply strong isolation (hypervisor protection, secure multi-tenancy) plus regular vulnerability scanning and patching.
• →Inadequate virtual environment security — weak VM hardening invites breaches; use secure VM templates, patching, monitoring, and network segmentation to block lateral movement.
• →User access management — weak passwords or excessive permissions; enforce strong password policy, multi-factor authentication, least privilege, and activity monitoring.
• →Lack of up-to-date security measures — environments evolve constantly; keep systems patched, review and update policies, and track current threats.
• →Single point of failure — one resource failing halts service; build redundancy and tested failover across servers, data centers, or providers.
• →Weak authentication and encryption — exposes access and data in transit or at rest; require multi-factor authentication, strong algorithms, and secure key management.
• →Unclear policies — missing guidelines cause inconsistent security; maintain clear, communicated, regularly reviewed policies with staff training.
• →Data remnants — deleted data may remain recoverable; use secure overwrite or erasure, manage backups securely, and verify removal.

Responsibility by Service Model

In IaaS the customer manages the operating system, middleware, runtime, data, and applications while the provider runs the infrastructure. Moving up to PaaS and then SaaS the provider assumes progressively more, but the customer always retains responsibility for its own data and user access.

Hybrid Decision Factors

When adopting hybrid, weigh data security, regulatory compliance (such as HIPAA for protected health information), interoperability between environments, and cost. The common pattern keeps sensitive or regulated data on-premises or private and bursts less-sensitive, high-volume workloads to the public cloud.

Key Considerations When Choosing a Deployment Model

Heavily tested factors for cloud-versus-on-premises decisions:

• →Availability — reachable when needed; distributed cloud infrastructure can stay up even if one data center fails.
• →Resilience — recovers from failures and keeps running via redundant infrastructure.
• →Cost — cloud lowers upfront cost but ongoing usage-based costs accumulate; compare short- and long-term.
• →Responsiveness — how fast the system adapts to demand by scaling resources.
• →Scalability — ability to handle larger workloads; cloud scales with little infrastructure limit.
• →Ease of deployment — no physical install; cloud can be provisioned in minutes.
• →Risk transference — some risk shifts to the provider, but the customer still secures its data, access, and applications.
• →Ease of recovery — built-in backup and restore reduce data-loss impact.
• →Patch availability — providers push regular patches, often applied automatically.
• →Inability to patch — compatibility limits or lack of control (e.g., legacy apps) can block patching.
• →Power — the provider supplies and manages power; the customer does not.
• →Compute — available CPU, memory, and storage; providers offer a range of instance sizes.

Type 1 vs. Type 2 Hypervisors

Type 1 (bare-metal) runs directly on hardware as a specialized OS, so it is faster and more efficient and is used for production and data-center virtualization. Type 2 (hosted) runs as an app inside a desktop OS—convenient for labs and testing but slower because the host OS consumes resources first.

Containers vs. Virtual Machines

Each VM bundles a full guest OS isolated by the hypervisor: strong isolation, higher overhead. Containers share the host OS kernel and package only the app and its dependencies: lighter and portable, but a single kernel exploit can compromise every container on that host.

Virtualization Vulnerabilities

Threats unique to virtualized hosts:

• →VM escape — breaking out of a VM to the hypervisor, then potentially into other guest VMs.
• →Privilege escalation — gaining root or administrator rights; catastrophic on the hypervisor itself.
• →Live migration interception — capturing unencrypted VM data moved between hosts via an on-path attack.
• →Resource reuse — reading another tenant's data from memory or storage not cleared before reassignment.
• →Data remnants — residual data left in reassigned VM storage or memory.
• →VM sprawl — unmanaged VMs that drift out of patching and oversight.

Securing Virtual Machines

Harden VMs like physical servers, plus virtualization-specific steps:

• →Patch the hypervisor promptly whenever the vendor releases a security update.
• →Patch and update each guest OS and its applications.
• →Install antivirus and a host-based firewall, and enforce strong passwords and policies on every VM.
• →Preserve isolation—limit VM-to-VM and VM-to-shared-resource connections such as network shares.
• →Reduce the attack surface by removing unneeded features and services.
• →Distribute VMs across multiple physical hosts so one compromised VM cannot starve others (denial of service).
• →Track all VMs to prevent VM sprawl and missed patches.
• →Encrypt the VM host files to protect them from unauthorized access on the server.

Serverless Does Not Mean No Servers

Serverless still runs on servers; the provider fully manages the servers, databases, and scaling so developers deploy only function code. Functions are event-triggered and run only on demand, unlike traditional applications that run continuously regardless of load.

Serverless Benefits

Why teams adopt serverless:

• →Cost — pay only for compute time consumed; no charge while functions are idle.
• →Automatic scaling — the provider scales execution precisely to the event or workload volume.
• →Developer focus — no server or runtime management, lowering operational burden and time to market.

Serverless Risks

Trade-offs to weigh:

• →Vendor lock-in — proprietary provider interfaces make switching or multi-provider use difficult.
• →Provider dependency — availability and security rely heavily on the cloud provider.
• →Immature best practices — serverless security patterns are still evolving.

Microservices vs. Monolithic

A monolith bundles all functionality into one interdependent unit—simple to start but hard to scale, and a single failure can take down the whole system. Microservices split the app into small, independent services that communicate over lightweight APIs, each deployable and scalable on its own.

Microservices Benefits

Advantages over a monolith:

• →Scalability — each service scales independently based on its own demand.
• →Flexibility — services can use different languages, data stores, and teams, choosing the best tool per service.
• →Resilience — one service failing does not bring down the whole system (fault isolation).
• →Faster deployment — services deploy and update independently, reducing release risk.

Microservices Challenges

Trade-offs the exam tests:

• →Complexity — managing inter-service communication, data consistency, and distributed testing.
• →Data management — each service may own its database, complicating consistency across services.
• →Network latency — more inter-service calls over the network can slow response times.
• →Security — many services communicating over the network enlarge the attack surface.

Physical vs. Logical Separation

Physical separation (air gap) fully isolates a system from other networks—the most secure option but rigid and costly. Logical separation (firewalls, VLANs, screened subnets) partitions a shared network—more flexible and easier to deploy, but only as strong as its configuration.

Air Gap Limits

An air gap sharply reduces remote attack exposure but is not infallible—Stuxnet showed an air-gapped industrial network can be breached through removable media (USB). Air gaps still depend on strict physical security to be effective.

SDN Separates Control from Forwarding

SDN decouples the control plane (decisions) from the data plane (forwarding) and centralizes control in a programmable controller. This replaces traditional networks where each device runs its own control plane, making the network centrally managed, programmable, and more flexible.

The Three SDN Planes

SDN divides the network into three planes:

• →Data (forwarding) plane — moves packets between devices based on IP/Ethernet.
• →Control plane — decides where traffic goes; centralized in the SDN controller.
• →Application plane — network apps that tell the controller what the network should do.

IaC Eliminates Snowflakes

IaC defines infrastructure in version-controlled, testable, auditable code (YAML, JSON, or HCL) so every environment is provisioned identically. This replaces manual configuration that drifts into inconsistent snowflake systems.

IaC Benefits

Why organizations adopt IaC:

• →Speed and efficiency — rapid provisioning and deprovisioning of resources.
• →Consistency and standardization — every environment is built the same way, reducing errors.
• →Scalability — infrastructure setups are easy to replicate when scaling up.
• →Cost savings — automation cuts manual configuration and troubleshooting effort.
• →Auditability and compliance — code is versioned and audited, so changes are tracked.

IaC Challenges

Trade-offs to manage:

• →Learning curve — teams must learn to write, test, and maintain infrastructure code.
• →Complexity — large IaC bases grow hard to manage without modularization and documentation.
• →Security risks — secrets exposed in code files or insecure configurations committed by mistake.

Centralized Architecture: Benefits and Risks

One authority manages everything:

• →Benefit: efficiency and control — the central authority allocates and manages resources easily.
• →Benefit: consistency — a single data store keeps information accurate across the organization.
• →Benefit: cost — only one system to maintain.
• →Risk: single point of failure — central server failure can disrupt the whole network.
• →Risk: scalability limits — the central system can struggle under growing load.
• →Risk: high-value target — compromising the central server exposes all data and applications.

Decentralized Architecture: Benefits and Risks

Function is distributed across independent nodes:

• →Benefit: resiliency — one node failing does not stop the system.
• →Benefit: scalability — add nodes as the organization grows.
• →Benefit: flexibility — supports remote work and distributed teams.
• →Risk: security — each node and remote connection is another potential entry point.
• →Risk: management complexity — coordinating many nodes is harder.
• →Risk: data inconsistency — synchronizing data across nodes is challenging.

IoT Security Risks

Why IoT devices are commonly exploited:

• →Weak defaults — default usernames and passwords that are well-known or easy to guess if left unchanged.
• →Poorly configured network services — open ports, unencrypted communication, or unnecessary services that enlarge the attack surface.

ICS/SCADA Risks

Built for isolated networks, now exposed to cyber threats:

• →Unauthorized access — weak protection lets attackers manipulate physical operations.
• →Malware — can disrupt or damage industrial processes.
• →Lack of updates — legacy, outdated software with unpatched vulnerabilities.
• →Physical threats — damage to the hardware or infrastructure itself.

Securing ICS/SCADA

Layered controls:

• →Strong access control — multi-factor authentication and least privilege.
• →Regular patching and updates against known vulnerabilities.
• →Firewall and intrusion detection system (IDS).
• →Regular security audits to find and fix weaknesses.
• →Employee security awareness training.

Embedded System Risks

Common weaknesses in embedded devices:

• →Hardware failure — devices often run in harsh physical environments.
• →Software bugs — defects can cause malfunctions with real safety impact.
• →Security vulnerabilities — embedded devices are targets for cyberattacks.
• →Outdated systems — long operational lifespans leave old, unpatched software and hardware.

Securing Embedded Systems

Layered protection strategies:

• →Network segmentation — isolate segments so a breach of one device cannot spread.
• →Wrappers (e.g., IPsec) — protect data in transit so an interceptor sees only the IPsec header, not the payload.
• →Firmware code control — secure coding, code reviews, automated testing, plus secure boot and cryptographic signatures.
• →Patching challenge — devices that cannot go offline or be reached use over-the-air (OTA) updates, applied carefully.