Unit 3: Secure Cloud Network Architecture, Resiliency and Vulnerability Management

I. Orientation: Securing Distributed Computing Estates

Modern security defends assets that no longer sit behind a single perimeter: workloads span public cloud, on-premises data centres, and embedded field devices. This unit treats three interlocking goals—a sound architecture, resilience against failure, and continuous vulnerability management—built on the CIA triad (Confidentiality, Integrity, Availability).

• Shared responsibility model: The cloud provider secures the infrastructure of the cloud (hardware, hypervisor, physical plant); the customer secures what runs in the cloud (data, configuration, access). IaaS pushes most duties to the customer, SaaS retains most with the provider.
• Defence in depth: Layered controls so that failure of one layer (e.g., a firewall misconfiguration) does not expose the asset.
• Attack surface: The sum of all entry points; cloud and embedded sprawl expand it, so control depends on knowing every asset.
• Resiliency: The ability to continue operating and recover through faults, measured by RTO (Recovery Time Objective) and RPO (Recovery Point Objective).
• Vulnerability lifecycle: Identify → analyse → remediate → verify, run continuously rather than once.

II. Secure Cloud and Embedded Architecture

A. Cloud Infrastructure

The building blocks and segmentation controls that isolate cloud workloads.

• Core components: Compute (VMs, containers), storage (object/block), and networking (VPCs, subnets) provisioned on demand.
• Virtual Private Cloud (VPC): A logically isolated network partition; subnets split it into public (internet-facing) and private (internal) tiers.
• Security groups vs. NACLs:
  • Security group: Stateful, instance-level allow-list; return traffic is permitted automatically.
  • Network ACL: Stateless, subnet-level, evaluates inbound and outbound rules separately.
• Deployment models: Public, private, hybrid (connecting on-prem to cloud via VPN/direct link), and community clouds.
• Infrastructure as Code (IaC): Templates (e.g., Terraform, CloudFormation) make configuration repeatable and auditable, reducing drift.
• Microsegmentation: Fine-grained east-west controls so a compromised workload cannot pivot laterally across the VPC.

B. Embedded Systems and Zero Trust Architecture

Constrained devices demand an identity-centric model because they often cannot host traditional agents.

• Embedded systems: Purpose-built computers (SCADA controllers, medical pumps, RTOS-based IoT) with limited CPU, memory, and often no patch path—long service lives magnify unaddressed flaws.
• Embedded weaknesses: Hard-coded credentials, unencrypted firmware, exposed debug (JTAG) ports, and infrequent updates.
• Zero Trust principle: "Never trust, always verify"—no implicit trust from network location; every request is authenticated and authorised.
  1. Traditional perimeter model: Trust inside the LAN, distrust outside; one breach grants broad lateral movement.
  2. Zero Trust model: Per-session verification regardless of location; blast radius is contained.
• Core tenets: Verify explicitly (identity, device posture), enforce least privilege, and assume breach.
• Policy enforcement: A Policy Decision Point evaluates context (user, device health, resource); a Policy Enforcement Point gates the connection.
• Application to embedded: Place constrained devices behind gateways that enforce ZT policy on their behalf, since the device itself cannot.

III. Resiliency and Physical Protection

A. Asset Management

You cannot secure or recover what you have not inventoried; asset management underpins all later sections.

• Inventory: A continuously maintained register of hardware, software, data stores, and cloud resources, including shadow and ephemeral assets.
• Asset lifecycle: Acquisition → deployment → maintenance → decommissioning, with secure disposal (data wiping, media destruction) at end of life.
• Classification: Tagging assets by sensitivity (public, internal, confidential) and criticality to prioritise controls.
• Ownership and CMDB: A Configuration Management Database records each asset's owner, dependencies, and baseline configuration.
• Enumeration vs. detection: Agent-based inventory reports from inside the host; network discovery scans find assets owners forgot to register.

B. Redundancy Strategies

Redundancy removes single points of failure so service survives component loss.

• High availability (HA): Duplicating components so failover is near-instant; targets small RTO.
• Geographic redundancy:
  • Availability Zones: Isolated data centres within one region—survive a facility failure.
  • Multi-region: Replicas in distant regions—survive a regional disaster.
• Data redundancy: RAID for disk fault tolerance; replication (synchronous for zero RPO, asynchronous for distance).
• Load balancing: Distributes traffic across healthy nodes and reroutes away from failed ones.
• Backup scheme: The 3-2-1 rule—3 copies, on 2 media types, with 1 offsite.

Example recovery target:
RPO = 15 min  →  back up at least every 15 minutes
RTO = 1 hr    →  restore service within 1 hour of failure

• Diversity vs. duplication: Duplicating identical systems repeats a shared flaw; diversity (different vendors/software) resists correlated failure.

C. Physical Security

Logical controls fail if an attacker can touch the hardware; physical layers protect facilities and devices.

• Deterrent and perimeter controls: Fencing, bollards, signage, and lighting discourage and delay intrusion.
• Access control: Badges, biometrics, and mantraps (airlock entry preventing tailgating) restrict entry to authorised staff.
• Detection: CCTV, motion sensors, and guards provide monitoring and forensic record.
• Environmental controls: HVAC, fire suppression (e.g., clean-agent, not water, near servers), and power conditioning (UPS, generators) preserve availability.
• Device hardening: Cable locks, port blockers, and tamper-evident seals protect embedded and endpoint hardware in the field.

IV. Vulnerability Classes

A. Device and OS Vulnerabilities

Flaws in endpoints and operating systems form the base layer attackers exploit.

• Unpatched software: Known CVEs left unaddressed; patch management closes the window between disclosure and exploit.
• Misconfiguration: Default credentials, open ports, and excessive privileges weaken an otherwise sound OS.
• End-of-life (EOL) systems: Unsupported OSes receive no patches—legacy and embedded devices are prime examples.
• Firmware and boot flaws: Attacks below the OS (bootkits); countered by Secure Boot and a hardware root of trust (TPM).
• Memory-level flaws: Buffer overflows and privilege escalation that let code run with elevated rights.

B. Application and Cloud Vulnerabilities

Flaws in software logic and cloud configuration, often the most exploited in internet-facing systems.

• Injection: Untrusted input treated as code; SQL injection and command injection are classic cases, mitigated by parameterised queries and input validation.
• Cross-Site Scripting (XSS): Injecting scripts that run in a victim's browser; mitigated by output encoding.
• Broken access control / IDOR: Users reaching resources they should not by manipulating identifiers.
• Insecure APIs: Weak authentication or over-exposed endpoints—the dominant cloud-native attack vector.
• Cloud misconfiguration:
  1. Public storage buckets: Object stores left world-readable, a leading cause of data breaches.
  2. Over-permissive IAM: Roles granting more than least privilege, enabling escalation.
• Supply chain and dependencies: Vulnerable third-party libraries pulled in transitively; tracked via a Software Bill of Materials (SBOM).

V. Vulnerability Management

A. Vulnerability Identification Methods

Finding weaknesses before adversaries do, using complementary techniques.

• Vulnerability scanning:
  1. Unauthenticated (external) scan: Views the system as an outsider; finds exposed surface but misses internal flaws.
  2. Credentialed (authenticated) scan: Logs in to inspect patch levels and configuration; fewer false positives, deeper view.
• Penetration testing: Humans actively exploit flaws to prove impact and chaining—goes beyond detection.
• Static vs. dynamic analysis:
  • SAST: Examines source code at rest for insecure patterns.
  • DAST: Tests the running application from outside.
• Threat intelligence feeds: OSINT and vendor advisories flag newly weaponised CVEs.
• Bug bounty and responsible disclosure: External researchers report flaws under agreed rules.
• Logging and SIEM correlation: Aggregated logs surface exploitation attempts and configuration drift.

B. Vulnerability Analysis and Remediation

Turning raw findings into prioritised, verified fixes, because remediating everything at once is infeasible.

• Validation: Confirm the finding is real, filtering out false positives before spending effort.
• CVSS scoring: The Common Vulnerability Scoring System rates severity 0–10 from base metrics (attack vector, complexity, impact); drives triage.

CVSS bands:
0.1–3.9  Low      7.0–8.9  High
4.0–6.9  Medium   9.0–10.0 Critical

• Risk-based prioritisation: Combine CVSS with asset criticality and real-world exploitability (e.g., CISA KEV catalogue) rather than score alone.
• Remediation options:
  1. Patch / reconfigure: Eliminate the flaw—the preferred fix.
  2. Mitigate / compensating control: Reduce exposure (WAF rule, segmentation) when a patch cannot ship immediately.
• Alternative responses: Accept (document residual risk below threshold), transfer (insurance), or avoid (decommission the asset).
• Patch testing: Validate fixes in staging to avoid breaking production.
• Verification and reporting: Rescan to confirm closure and track mean time to remediate (MTTR) as a programme metric.
• Continuous cycle: New assets and new CVEs appear daily, so identification and remediation run as an ongoing loop, not a project.