CCSP: Cloud Infrastructure Risk Assessment, Threats and Risk Treatment

A cloud infrastructure risk assessment identifies the risks to the assets that run on a cloud platform and analyzes each one for likelihood and impact, so the business can decide how to treat them. CCSP sub-domain 3.3 treats it as the first half of a cycle: identify, analyze, then choose a treatment and monitor the result.

Identification means writing each risk in parts that can be analyzed. A useful register entry names the asset at stake, the threat that could act on it, the vulnerability the threat would exploit, and the impact if it happened. A threat on its own ("a malicious insider at the provider") is not yet a risk: without the asset and the weakness, nobody can judge how likely it is or how much it would hurt.

The common labelling mistake is swapping threat and vulnerability. The threat is who or what acts; the vulnerability is the condition that lets it succeed; the disclosure or outage that follows is the impact. Identification also depends on knowing the assets: an inventory that misses running instances or snapshots produces a register that misses their risks, so reconciling the inventory against the provider's own records of instances, disks and snapshots comes before rating anything.

Qualitative analysis rates likelihood and impact on ordinal scales (for example high, medium, low, or 1 to 5) using expert judgment; quantitative analysis expresses risk in money using loss values and frequencies taken from data. The choice depends on the data available and the decision the analysis has to support.

Most programmes combine them: rate the whole list qualitatively, then quantify the few risks at the top where an investment decision depends on the number. Activities that find weaknesses or gather evidence feed the analysis without being it: analysis means rating each identified risk's likelihood and business impact for this organization, and only the organization's own assessment does that.

Quantitative analysis turns a risk into an expected yearly loss with a short chain of formulas, then values a control by how much of that loss it removes, less what the control costs each year.

Worked example (illustrative numbers). A hosted reporting service is valued at $500,000. A storage-corruption event would destroy 30% of that value, so SLE = $150,000. Analysts expect it once every five years, so ARO = 0.2 and ALE = $30,000. A replication control costing $8,000 a year would lower the ARO to 0.05, giving a new ALE of $7,500. Its value is $30,000 − $7,500 − $8,000 = $14,500 a year. A control that lowers the exposure factor instead (say, faster restores that limit damage) changes the SLE rather than the ARO; recalculate whichever input the control actually moves, then compare the net values of competing controls.

The usual errors are using a frequency without converting it to a yearly rate, stopping at the reduction in ALE without subtracting the control's cost, and taking the asset value as the loss when only part of it is exposed.

Inherent risk is the level of risk before any control is taken into account; residual risk is what remains after the controls in place are counted; risk appetite is the amount of risk the organization has decided it is willing to carry. Residual risk is the figure compared with appetite to decide whether more treatment is needed.

• Any control counts. A rating that already credits a provider's built-in protection (DDoS filtering, managed patching) is a residual rating, even though the customer did not build the control.
• Residual above appetite needs more treatment or a documented acceptance by the risk owner. Residual within appetite is recorded and monitored.
• Residual ratings are not fixed. They rest on specific controls. When a change weakens or removes one (opening an isolated database to a partner network, retiring a filter), the residual risk must be re-rated for the period the change is in effect, not left at the old value until the annual review.
• Secondary risk is a new risk a treatment introduces, such as a second provider adding its own supply-chain exposure.

The service model decides who operates each layer, and therefore who can apply the treatment: in IaaS the customer treats risks from the guest operating system upward, in PaaS the provider takes over the operating system and platform runtime, and in SaaS the customer directly controls little beyond its data, its users and the application settings it is given. The customer remains accountable for the consequences at every level.

Two consequences follow. First, when a layer moves to the provider, the register entry for its risk does not disappear: it stays, with the provider as the treating party and the customer's analysis based on provider evidence. What changes is who treats it and what evidence the rating rests on; the risk itself, and the customer's accountability for its consequences, remain. Second, where the customer cannot test the provider's layer (most contracts forbid scanning the provider's hosts), likelihood is judged from independent, in-scope, current assurance: independent beats self-published, in-scope (covering the service actually used) beats general, and a recent period beats an old one. A SOC 2 Type II report is the typical example. Evaluating those reports and certifications as such belongs to sub-domain 1.5; here they are inputs to the risk analysis.

The virtualization layer creates three threats that have no exact on-premises equivalent: escape from a guest to the hypervisor, information leakage between tenants that share hardware, and unmanaged machines and images that nobody patches.

Virtual machine escape

A VM escape is an attack in which code in one guest exploits a flaw to run on the hypervisor and from there reaches other guests on the same host. Because the attack goes beneath the guests, controls that act above the hypervisor do not change the likelihood of an attack beneath it. What does is a small, hardened, promptly patched hypervisor. A bare-metal (type 1) hypervisor runs directly on the hardware; a hosted (type 2) hypervisor runs on a general-purpose operating system, whose extra code adds flaws that can expose every guest, so it presents the larger attack surface. The host OS is not an additional barrier: compromising it compromises everything above it.

Cross-tenant side channels

Side-channel attacks (cache timing and similar microarchitectural leaks) let one VM infer data, such as key material, from another VM on the same physical CPU. They need physical co-residency and operate beneath the logical controls that separate tenants, so the treatment has to remove the shared hardware itself. Likelihood depends on how hard it is for an attacker to land on the same host; treatment removes the neighbour by running sensitive workloads on single-tenant (dedicated) hosts, and on those hosts keeping the organization's own internet-facing workloads separate from the sensitive ones, since a compromised web server on the same hardware is a neighbour too.

VM sprawl and dormant images

VM sprawl is the uncontrolled growth of virtual machines, images and snapshots without recorded owners. Stopped VMs and old images miss patches, and anything with credentials baked in keeps them valid long after they should have been rotated. A VM restored from an old image is as vulnerable as the day the image was built. Treatment is ownership and lifecycle: inventory reconciled against the provider's records, tagging and expiry, regular image rebuilds from patched baselines, and credentials injected at launch from a secrets service rather than stored in the image.

The management plane, the provider's console and administrative APIs, is the highest-impact target because whoever controls it can create, change, copy or delete every resource in the account, including the logs and backups that would detect and recover from the attack. A management-plane administrator credential therefore earns the highest impact rating in a credential assessment, above any single VM, database or storage token.

Treatment aims at removing standing administrative power rather than guarding long-lived secrets better:

• Federate human sign-in through the organization's identity provider with MFA (phishing-resistant where possible).
• Grant administrative rights just in time for a bounded task instead of permanently. This also limits what an attacker can do with a stolen live session that has already passed MFA, which stronger sign-in alone does not.
• Give pipelines short-lived, narrowly scoped roles instead of long-lived administrator keys. Making a long-lived key harder to steal still leaves the standing power in place for whoever does obtain it.
• Keep management-plane audit logs where administrators cannot alter them, so that any takeover can be detected and investigated. Detective controls complement the preventive ones above rather than replacing them.
• Keep a break-glass path for when federation fails: a minimal, fixed set of local emergency accounts that are not anyone's everyday account (vendors such as Microsoft recommend at least two, held by different custodians, so losing one credential cannot lock the tenant out), the strongest authentication such as a hardware key, credentials sealed under dual control so no single person can use them unnoticed, and an alert on every use.

Identity and access design in general belongs to Domain 4 and 3.4; here the point is rating and reducing this one, very large, risk.

Misconfiguration is among the most common causes of cloud breaches: a resource set more open than intended, often during a change nobody reviewed. Server-side request forgery against the instance metadata service turns an application flaw into stolen cloud credentials, and economic denial of sustainability turns elasticity itself into a cost weapon.

Misconfiguration and inadequate change control

The Cloud Security Alliance's Top Threats to Cloud Computing (the 2022 “Pandemic Eleven” edition) lists misconfiguration and inadequate change control as its own category, alongside categories such as insufficient identity, credential, access and key management and insecure interfaces and APIs. A setting opened "just for testing" and never reverted belongs here regardless of intent. Because cloud configuration changes constantly and across many accounts, the check has to run as often as the configuration changes. The effective treatment is continuous posture evaluation against policy plus guardrails that reject non-compliant deployments. Template scanning in a pipeline only guards changes that go through the pipeline; resources changed in the console or by hand (out-of-band) need restricted write access outside the pipeline and drift detection.

SSRF against the instance metadata service

Cloud VMs can query a link-local metadata endpoint (commonly 169.254.169.254) for configuration and the temporary credentials of the role attached to them. If an application fetches URLs supplied by users, an attacker can point it at that address and receive those credentials in the response: server-side request forgery. Treatments differ by which part of the risk they change:

Providers harden the metadata service in different ways. In AWS (IMDSv2) a caller must first obtain a session token through a separate PUT request, and the hop limit (the IP time-to-live on the token response) keeps that token from travelling beyond the instance, so a forwarding host or container cannot receive it. Azure and Google Cloud require a specific request header (Metadata: true, Metadata-Flavor: Google) that a typical forged fetch does not send, and reject forwarded requests.

Note which question is being asked: reducing the chance of theft when the code cannot change points to the metadata service setting; reducing the damage if theft happens points to the role's permissions.

Economic denial of sustainability

Economic denial of sustainability (EDoS) is an attack in which traffic floods an elastic service that scales out to absorb it: customers see no outage, but the consumption bill rises until the service becomes unaffordable. It differs from a classic resource-exhaustion denial of service, where the service fails, and from a noisy neighbour, where another tenant's legitimate load degrades performance.

Its impact is measured in money, so the key input to an impact rating is the maximum spend the scaling configuration allows before any limit applies: the scaling ceiling bounds the loss. Treatment must keep elasticity for real demand while bounding cost: filter and rate-limit at the edge so attack traffic never reaches the scaling tier, set maximum scaling limits sized to plausible real peaks, and alert on spend. A treatment that removes elasticity swaps the cost risk for an availability risk, so the goal is a ceiling on spend rather than an end to scaling.

Once a risk is analyzed, the owner chooses one of four treatment strategies: avoid it, mitigate it, transfer or share it, or accept it. Often a combination applies, such as mitigating to bring a risk within appetite and accepting the remainder.

Transfer moves cost, not accountability. Insurance and service credits compensate the organization, but customers, regulators and courts still hold the organization responsible for protecting its data, even when the provider caused the failure. A risk register entry is therefore not closed because insurance or an SLA exists, and its impact rating is not lowered by them either: reputational and regulatory consequences remain. Redundancy across providers is mitigation, not transfer, because it changes the likelihood of the impact rather than who pays for it.

When the customer cannot remediate a vulnerability itself, because the provider owns the layer, the vendor no longer supports the system, or a fix is months away, it records the risk, applies compensating controls that meet the intent of the missing control, and keeps the entry open until the fix is verified.

Provider-owned vulnerabilities

A hypervisor flaw on a public IaaS platform is the provider's to patch, but the customer still owns the risk to its workloads. The first steps are to record the risk, confirm the provider's remediation timeline and status, and add compensating controls for the interim (heightened monitoring, isolating the most sensitive workloads, reviewing dedicated-host options). The entry stays open until the provider's fix is verified, and the compensating controls must act on the exposure the flaw creates, not on unrelated layers.

Compensating controls

• Can't patch: an unsupported operating system is isolated in its own segment with deny-by-default rules and added monitoring, and the exception is recorded until the upgrade. A compensating control lowers likelihood only if it sits on the path an attacker would use to reach the flaw; controls that protect stored data or speed recovery act on impact instead.
• Provider can't enforce a control: if a SaaS application cannot restrict administrator sign-in by network, enforce the same condition at a point the customer does control, such as its identity provider's sign-in policy, and document the exception.

Risk acceptance and ownership

Acceptance is valid only when it is a documented decision by the risk owner (the person accountable for the affected business service), made with the analysis in front of them, within the organization's appetite, and with a review date. It is not:

• a decision made by someone else, such as an engineer or project lead, even if the rating is within appetite;
• a default: a risk nobody has treated and nobody has signed for is untreated, whatever the budget situation;
• permanent: when the review date passes, or the likelihood or impact changes (a public exploit is released, the asset becomes internet-facing), the risk goes back to its owner for a new decision.