7.3 Infrastructure & Platform Risks (Domain 3.3)
Key Takeaways
- Risk assessment for cloud infrastructure includes identification of assets/threats/vulnerabilities and analysis of likelihood and impact under shared responsibility.
- Cloud-specific vulnerabilities, threats, and attacks include misconfiguration, credential theft, hypervisor/container escape, insecure APIs, data exfiltration, and denial of service.
- Risk treatment strategies are avoid, mitigate, transfer/share, and accept — plus residual risk monitoring; not every risk is patched away.
- Platform risk spans CSP control planes, multi-tenancy isolation, supply chain, and customer configuration debt — inventory both provider and tenant surfaces.
- CCSP scenarios reward structured assessment language over product brand names.
Infrastructure and Platform Risks
Domain 3.3 asks you to analyze risks associated with cloud infrastructure and platforms. The outline breaks this into:
- Risk assessment (identification, analysis)
- Cloud vulnerabilities, threats, and attacks
- Risk treatment strategies
This is applied risk management on the components and data-center designs you just studied. Domain 6 expands enterprise risk and legal themes; here the focus is platform and infrastructure — hypervisors, networks, management planes, multi-tenancy, and facility dependencies.
Risk Vocabulary Refresh
| Term | Working definition |
|---|---|
| Asset | Something of value (data, service, reputation, hardware, API availability) |
| Threat | Potential cause of an unwanted incident |
| Vulnerability | Weakness that a threat can exploit |
| Risk | Effect of uncertainty on objectives — often Likelihood × Impact (qualitative or quantitative) |
| Control | Measure that modifies risk |
| Residual risk | Risk remaining after treatment |
| Risk appetite / tolerance | How much risk the organization is willing to take |
Cloud does not invent new risk math; it changes speed, shared tenancy, abstraction, and control ownership. A vulnerability in a customer security group can be exploited worldwide within minutes via the management plane — likelihood and impact models must reflect that.
Risk Assessment: Identification
Identification inventories what can go wrong and what matters.
Identify assets (infrastructure scope)
| Asset class | Examples |
|---|---|
| Data | Databases, object stores, backups, logs, secrets |
| Workloads | VMs, containers, functions, AI training jobs |
| Identities | Human admins, service principals, workload identities |
| Control plane | Cloud org structure, IaC pipelines, orchestration API |
| Connectivity | VPN, private links, DNS, certificates |
| Dependencies | CSP regions, IdP, CI/CD SaaS, DNS provider, package registries |
| Facility dependencies | Power, HVAC, carriers (for private/colo) |
Identify threats
Use structured sources: STRIDE-style categories, threat intel, historical incidents, insider scenarios, and environmental events. For infrastructure platforms, include both cyber and physical/environmental threats.
Identify vulnerabilities
Weaknesses may be technical (unpatched hypervisor agent, open management port), process (no dual control for DNS changes), people (phishing of cloud admins), or design (single region, shared keys).
Cloud-specific identification questions
- What does the CSP guarantee vs what do we configure?
- Where are multi-tenant isolation boundaries?
- What happens if the management plane identity is stolen?
- Which fourth parties (CSP subprocessors, marketplace images) expand the supply chain?
- What data residency constraints limit treatment options (e.g., cannot move region freely)?
Document assumptions. Many “unknowns” about provider internals are accepted via assurance reports — that acceptance is itself a risk decision.
Risk Assessment: Analysis
Analysis estimates how serious each risk is so treatment can be prioritized.
Qualitative analysis (common on exams)
| Likelihood | Impact | Priority sketch |
|---|---|---|
| High | High | Treat immediately |
| High | Medium | Prioritize mitigations |
| Medium | High | Strong controls / contingency |
| Low | High | Monitor; consider insurance/transfer; rare but severe |
| Low | Low | Accept or routine hygiene |
Scales vary (1–5, traffic lights). Consistency matters more than pseudo-precision.
Quantitative flavors (awareness)
Annualized Loss Expectancy (ALE) style thinking appears in broader risk domains: Single Loss Expectancy × Annualized Rate of Occurrence. Cloud metering can improve detection of anomalous usage (cost as a risk signal) even when pure ALE numbers are rough.
Analysis factors unique to cloud platforms
| Factor | Effect on analysis |
|---|---|
| Elasticity | Impact scales with auto-provisioned capacity and data volume |
| Abstraction | Harder to inspect physical layers; increase reliance on CSP attestations |
| Shared fate | Provider regional outage impacts many customers simultaneously |
| Configuration volatility | Drift raises likelihood of misconfiguration over time |
| API concentration | Single set of credentials may unlock many assets (impact amplifier) |
| Log completeness | If management actions are not logged immutably, impact of incidents rises (detection lag) |
Scenario analysis example
Risk: Public object storage misconfiguration exposes regulated data.
Threat actors: Internet scanners, opportunistic attackers.
Vulnerability: Bucket policy allows public GetObject; block-public-access not enforced at org level.
Likelihood: High (automated scanning).
Impact: High (breach notification, fines, trust).
Inherent risk: Critical.
Existing controls: Encryption at rest (does not stop authorized-anonymous reads of ciphertext when policy allows).
Conclusion: Encryption alone is insufficient treatment; need preventive policy guardrails and detective config monitoring.
This style of reasoning — not memorizing vendor product names — is what CCSP grades.
Cloud Vulnerabilities
A vulnerability is a weakness. Cloud estates combine classical IT weaknesses with cloud-native ones.
| Vulnerability class | Examples |
|---|---|
| Identity & access | Over-privileged roles, long-lived access keys, missing MFA, weak federation |
| Misconfiguration | Open security groups, public storage, permissive IAM wildcards, disabled logging |
| Insecure defaults | Services left on demo settings; default VPCs with broad routes |
| Unpatched components | Guest OS, container images, agents, customer-managed middleware |
| Isolation gaps | Privileged containers, shared hostPath, weak tenant network controls |
| Cryptographic weakness | Deprecated TLS, poor key storage, dual-purpose keys |
| API design flaws | Broken object-level authorization, SSRF to metadata services |
| Supply chain | Poisoned images, malicious dependencies, compromised build pipeline |
| Visibility gaps | No flow logs, no management-plane audit trail, shadow IT accounts |
| Physical/environmental | Single power path, undiverse fiber, weak visitor control (private/colo) |
| BMS / OT overlap | Facility systems reachable from IT networks |
Important distinction: Multi-tenancy is not itself a vulnerability — failure of isolation mechanisms is. Resource pooling is expected; residual side-channel risk may be accepted or mitigated with dedicated hosts for extreme cases.
Vulnerability management in cloud must cover infrastructure as code templates and org policies, not only CVE scans of VMs. A secure image deployed by a template that opens 0.0.0.0/0 to SSH reintroduces critical exposure every apply.
Cloud Threats and Attacks
Threats are the actors or forces that may exploit vulnerabilities. Attacks are concrete actions.
Threat categories for infrastructure/platforms
| Threat category | Cloud infrastructure examples |
|---|---|
| External adversaries | Credential stuffing against consoles, ransomware via exposed RDP, crypto-mining bots |
| Insiders (customer) | Malicious admin, careless privileged user, third-party contractor |
| Insiders (CSP) | Privileged provider personnel (mitigated by CSP controls, customer encryption, confidential computing) |
| Competing tenants | Escape attempts, noisy neighbor resource exhaustion |
| Supply chain | Compromised provider dependency or customer CI/CD |
| Environmental | Flood, fire, power grid failure, fiber cut |
| Legal / seizure | Lawful access requests in a jurisdiction (risk/compliance overlap) |
Representative attacks
| Attack | Description | Primary targets |
|---|---|---|
| Account takeover | Phish MFA-fatigue, steal API keys, session hijack | Management plane |
| Misconfiguration exploit | Discover public storage/DBs/admin ports | Storage, compute, network |
| Privilege escalation | Abuse IAM policy flaws, metadata SSRF to steal roles | Compute + IAM |
| Lateral movement | Pivot across flat VPC/peering | Network partitioning failures |
| Data exfiltration | Copy snapshots cross-account; DNS tunneling; egress to attacker storage | Storage, network egress |
| Destructive attack | Mass delete, encryption ransomware on volumes/backups | Storage, backups |
| DDoS | Saturate public endpoints or APIs | Network edge, app |
| Cryptojacking | Steal compute for mining | Compute, Kubernetes |
| Hypervisor/container escape | Break isolation boundary | Virtualization |
| Poisoned image/pipeline | Backdoor in base image or IaC module | Supply chain, orchestration |
| Control-plane API abuse | Scripted create/destroy at scale | Management plane |
| DNS hijacking | Alter records to intercept traffic | Communications |
Attack chain example (exam-style)
- Developer access key committed to public repo (vulnerability).
- Attacker finds key (threat actor capability).
- Attacker lists storage, snapshots DB volume, shares snapshot outbound (attack).
- Impact: confidentiality breach; possible integrity if they modify resources.
- Treatment that would have reduced risk: secret scanning, short-lived credentials, deny snapshot share org-wide, mandatory MFA, detection on anomalous
CreateSnapshot/ModifySnapshotAttribute.
Map each step to component (3.1) and design gap (3.2) when answering scenario items.
Risk Treatment Strategies
Once risks are analyzed, organizations treat them. CCSP-aligned treatment options match classic information security risk management:
| Strategy | Meaning | Cloud infrastructure examples |
|---|---|---|
| Avoid | Do not engage in the risky activity | Do not store regulated data in unsupported regions; do not enable public anonymous access features at all |
| Mitigate (modify/reduce) | Apply controls to reduce likelihood and/or impact | MFA, encryption, segmentation, WAF, immutable backups, patching, org policy guardrails |
| Transfer | Shift financial/contractual impact to another party | Cyber insurance; contractually defined CSP liabilities (limited); managed security services |
| Share | Distribute risk among parties | Shared responsibility models; consortium/community cloud governance; multi-party controls |
| Accept | Knowingly retain risk within appetite | Accept residual CSP insider risk after encryption + legal review; accept rare regional outage risk with documented BC plan |
Some frameworks list share under transfer; the CCSP outline family (see also Domain 6 risk treatment) expects you to recognize avoid, mitigate, transfer/share, and accept as the toolkit.
Choosing a strategy
| Situation | Lean toward |
|---|---|
| Activity not required for business | Avoid |
| High likelihood, controllable weakness | Mitigate |
| Rare high financial impact, control cost prohibitive alone | Transfer (insurance) + mitigate |
| Shared platform by design | Share responsibility + contracts + assure |
| Residual risk after reasonable controls, within appetite | Accept with monitoring |
Treatment is not “set and forget.” Residual risk must be monitored — new vulnerabilities, configuration drift, and threat landscape changes can push accepted risk outside appetite.
Treatment vs control confusion
- Treatment strategy = risk decision (avoid/mitigate/transfer/accept).
- Control = specific measure implementing mitigation (e.g., “enforce MFA on console users”).
Exam stems may ask which strategy was chosen (“the firm decided not to process card data in that SaaS”) = avoid, not “install WAF.”
Layered treatment example
Risk: Regional provider outage.
- Mitigate: multi-AZ for localized faults; multi-region active/passive for regional.
- Transfer: insurance for business interruption.
- Accept: residual simultaneous multi-region failure as extremely unlikely.
- Avoid: do not put the only copy of irreplaceable data in a single AZ with no backups.
Shared responsibility as treatment context
You cannot mitigate a risk the contract places solely on the CSP using customer console clicks alone — and you cannot transfer accountability for customer data classification to the CSP by wishing. Effective treatment assigns actions to the party that can implement them and verifies with SLA, SOC reports, configuration evidence, and exercises.
End-to-End Risk Workflow for Domain 3
- Scope infrastructure components (3.1) and facility/design choices (3.2).
- Identify assets, threats, vulnerabilities, existing controls.
- Analyze likelihood and impact; rank risks.
- Treat using avoid / mitigate / transfer-share / accept.
- Implement controls (Domain 3.4 themes: physical/environmental, system/storage/communication protection, IAM, audit).
- Plan BC/DR for risks you mitigate with resiliency rather than pure prevention (Domain 3.5).
- Monitor and review — continuous cloud posture management, pen tests where authorized, tabletop exercises.
Prioritization heuristic for CCSP practice
| Priority signal | Why |
|---|---|
| Management plane exposure | Highest leverage for attackers |
| Public data access misconfig | High likelihood + high impact |
| Missing immutable backups | Ransomware impact amplifier |
| Flat network + over-privileged identity | Lateral movement |
| Single AZ / single path facility | Correlated availability failure |
| Unvetted images/pipelines | Supply chain scale |
Metrics that support risk management
- Time to revoke compromised credentials
- Percentage of resources failing policy-as-code checks
- MFA coverage on privileged users
- Backup restore success rate
- Mean time to detect anomalous API patterns
- Patch lag on customer-managed OS/images
Metrics without decisions are vanity; pair them with treatment owners and deadlines.
Common Traps
- Treating encryption at rest as complete mitigation for public-read policies.
- Accepting risk informally (“we’ll fix later”) without recording residual risk and owner.
- Assuming CSP compliance certifications remove customer misconfiguration risk.
- Focusing only on CVE scores while ignoring IAM and network exposure.
- Calling multi-cloud a full avoid strategy for all provider risk (it can mitigate concentration but increases complexity risk).
- Ignoring environmental threats in “cyber-only” cloud assessments for hybrid estates.
Closing Synthesis for Domain 3.1–3.3
- 3.1 tells you what the infrastructure is.
- 3.2 tells you how to design facilities and logical isolation for secure, resilient operation.
- 3.3 tells you how to reason about what can fail and what to do about it.
Master the three together: a CCSP item may describe a container escape fear (virtualization component), ask whether dedicated hosts are justified (design/treatment), and expect you to label residual risk acceptance after mitigations — all in one stem.
Which activity is part of risk identification rather than risk analysis?
A company refuses to deploy a customer-facing workload in a region that cannot meet residency law. Which risk treatment strategy is this?
Which attack most directly targets the cloud management plane?
Encryption at rest is enabled on object storage, yet anonymous public read remains allowed by policy. Which statement best reflects sound risk analysis?