Threats, Vulnerabilities and Cloud Risk

Introduction

Cloud computing changes how organisations acquire, configure and operate information technology. Servers, storage, networks, databases and security functions can be provisioned through portals and application programming interfaces (APIs), often within minutes. This flexibility creates business value, but it also changes the security problem. An organisation may no longer control the physical data centre, may share infrastructure with other customers, may depend on provider-managed services, and may expose administrative functions through the internet.

Cloud security therefore requires more than purchasing protective software. It requires systematic identification of assets, threat actors, attack surfaces, vulnerabilities, business consequences and appropriate treatments. A useful security assessment asks five connected questions:

1. What must be protected?
2. Who or what could cause harm?
3. How could the asset be attacked or compromised?
4. How likely and consequential is the event?
5. Which treatment reduces risk to an acceptable level?

This chapter introduces these questions and applies them to common cloud environments. The emphasis is on practical foundations suitable for entry-level cloud professionals.

Learning objectives

By the end of this chapter, you should be able to:

• distinguish assets, threats, threat actors, vulnerabilities and risks;
• identify major cloud attack surfaces;
• explain how misconfiguration creates security exposure;
• recognise common attacks against cloud identities, networks, data and applications;
• apply a basic threat-modelling process;
• estimate likelihood, impact and risk using a simple qualitative or semi-quantitative method;
• select appropriate risk treatments; and
• explain the importance of shared responsibility, governance and evidence-based security decisions.

1. The language of cloud risk

Assets

An asset is something that has value to an organisation or its stakeholders. Assets include customer records, payment information, source code, credentials, encryption keys, virtual machines, containers, databases, APIs, logs, business processes and the availability of a service. An asset may be tangible or intangible. A cloud database is an asset, but so is the trust customers place in the organisation.

Asset owners are accountable for determining the importance, acceptable use and protection requirements of assets. Ownership does not necessarily mean technical administration. For example, a finance director may own payment data while a cloud engineer operates the database service.

Threats and threat actors

A threat is a potential cause of an unwanted security event. A threat actor is the person, group or process that may intentionally or unintentionally create that event. Common threat actors include:

• cybercriminal groups seeking money or data;
• nation-state or state-sponsored groups pursuing intelligence or disruption;
• malicious insiders abusing legitimate access;
• careless or inadequately trained employees;
• hacktivists motivated by political or social causes;
• competitors engaging in industrial espionage; and
• automated malware, bots and opportunistic scanners.

Threats are not always malicious. A power failure at a provider, an administrator accidentally deleting a storage volume, or a software defect can threaten confidentiality, integrity or availability.

Vulnerabilities

A vulnerability is a weakness that can be exploited or triggered. Examples include an exposed management port, an over-permissive identity policy, an unpatched virtual machine, weak authentication, an application injection flaw, an unencrypted backup or an absent recovery plan. A vulnerability alone does not establish that loss will occur. Risk depends on exposure, the relevant threat, existing controls and the value of the affected asset.

Attack, exploit and control

An attack is an attempt to compromise an asset. An exploit is the technique, code or method used to take advantage of a vulnerability. A control is a safeguard that prevents, detects, responds to or recovers from adverse events. Multi-factor authentication, network segmentation, encryption, secure configuration scanning and tested backups are examples of controls.

Risk

Risk describes the possibility that a threat will exploit a vulnerability and produce an unwanted consequence. In basic assessments, risk is often represented as a combination of likelihood and impact. This is a useful decision aid, not a claim that security can be measured with perfect precision.

A simple model is:

Likelihood expresses the chance or plausibility of an event within a defined period. Impact expresses the severity of its consequences. Both must use a stated scale. For example, an organisation may score each from 1 to 5. The multiplication is meaningful only when the scales and definitions are applied consistently; the result is a prioritisation score rather than a probability or monetary loss.

A more economically oriented model is:

The annual rate of occurrence is the expected number of events per year, and the single loss expectancy is the loss from one event, expressed in a specified currency. This model requires credible estimates and should include relevant direct and indirect costs. It is inappropriate to present a precise monetary figure when the underlying evidence is highly uncertain.

2. Cloud attack surfaces

An attack surface is the collection of points through which an attacker may attempt to enter, influence or extract information from a system. Cloud environments commonly have larger and more dynamic attack surfaces than traditional server rooms.

Identity and access

Identity is frequently the primary security boundary in cloud computing. Cloud consoles, APIs, service accounts, federation systems and administrator workstations can all provide access. A stolen administrator token may allow an attacker to read data, create resources, disable monitoring or establish persistence without exploiting an operating-system vulnerability.

Important exposure points include:

• long-lived access keys stored in code repositories;
• shared administrator accounts;
• excessive permissions;
• missing multi-factor authentication;
• poorly protected service accounts;
• weak federation or single sign-on configuration; and
• inadequate control over privileged access.

The principle of least privilege requires each identity to receive only the permissions necessary for its assigned task, for only as long as needed.

Management interfaces and APIs

Cloud resources are controlled through web consoles, command-line tools and APIs. These interfaces are valuable targets because they provide powerful functions remotely. API risks include poor authentication, inadequate authorisation checks, exposed secrets, insufficient rate limiting, insecure defaults and incomplete logging. An API may be technically reachable only by an internal service but still be vulnerable if that service is compromised.

Network and connectivity

Attack surfaces include internet-facing load balancers, virtual machines, containers, databases, firewalls, virtual private networks, peering connections, direct links and domain-name services. A security group rule permitting unrestricted inbound traffic to a management port is a typical exposure. Misconfigured routing may also allow a compromised workload to reach sensitive systems that should be isolated.

Applications and software supply chains

Cloud applications depend on operating systems, libraries, container images, infrastructure-as-code modules, build pipelines and third-party services. A vulnerable dependency or compromised build process can introduce malicious code into an otherwise well-configured cloud account. Software supply-chain security therefore includes source-code protection, dependency management, image scanning, signed artefacts and controlled deployment permissions.

Data stores and backups

Object storage, block volumes, databases, queues and backup repositories may contain valuable information. Common weaknesses include public access, weak authorisation, unencrypted data, excessive retention, insecure replication and untested restoration. Backups are security assets as well as recovery assets because attackers may attempt to delete or encrypt them.

Human and organisational interfaces

Phishing, social engineering, unsafe support procedures and inadequate separation of duties can defeat technical controls. Cloud security is consequently a socio-technical problem: secure technology must be supported by trained people, sound processes and accountable governance.

3. Misconfiguration as a central cloud risk

Cloud services are designed for rapid self-service. That feature can produce insecure configurations when users misunderstand provider settings, copy examples without review, or deploy resources without organisational guardrails. Misconfiguration is not limited to a single incorrect setting; it may arise from the interaction of several individually reasonable settings.

Examples include:

• storage accessible to the public internet;
• databases deployed without network isolation;
• encryption keys available to too many administrators;
• security logs disabled or retained for too short a period;
• unrestricted outbound traffic that enables command-and-control communication;
• snapshots or machine images shared with unintended accounts;
• default credentials left active; and
• infrastructure deployed outside approved regions or accounts.

Configuration drift occurs when a resource gradually differs from its approved state. Manual changes, emergency fixes and inconsistent templates are common causes. Preventive practices include infrastructure as code, peer review, policy-as-code, secure baseline templates, continuous configuration assessment and automated remediation with appropriate safeguards.

Automation must be governed carefully. An automated rule that deletes a resource because it appears non-compliant can itself cause an outage. Controls should distinguish detection, approval and enforcement according to the potential consequence.

4. Common cloud attacks

Credential theft and account takeover

Attackers obtain passwords, access keys, session tokens or recovery information through phishing, malware, password reuse, exposed repositories and compromised devices. After authentication, they may discover resources, escalate privileges, create new identities, copy data or deploy cryptocurrency-mining workloads. Multi-factor authentication, short-lived credentials, conditional access, device security and continuous monitoring reduce this risk.

Privilege escalation

Privilege escalation occurs when an identity or workload gains permissions beyond those intended. It may result from a policy that permits role assignment, an overly powerful service account, an application flaw or a compromised administrator workstation. Effective authorisation review examines not only direct permissions but also combinations of permissions that enable indirect escalation.

Data exposure and exfiltration

Data exposure may occur through public storage, incorrect database permissions, insecure APIs or leaked credentials. Exfiltration is the unauthorised transfer of data to an attacker-controlled location. Data classification, encryption, tokenisation, access logging, data-loss prevention and egress monitoring are relevant controls. Encryption does not compensate for a compromised identity that is authorised to decrypt the data.

Denial-of-service attacks

A denial-of-service attack attempts to reduce or eliminate availability. Distributed denial-of-service attacks use many sources to overwhelm network, application or service capacity. Cloud elasticity may absorb some traffic, but scaling can increase cost and may not protect application dependencies. Rate limiting, content delivery services, resilient architecture, provider assistance and tested response plans are important.

Web and API attacks

Injection, broken access control, insecure direct object references, cross-site scripting, request forgery and insecure deserialisation can affect cloud-hosted applications. A cloud provider may secure the underlying service, but the customer remains responsible for application logic and authorisation. Security testing should therefore include code review, dependency analysis, dynamic testing and abuse-case testing.

Supply-chain compromise

An attacker may compromise a software vendor, open-source package, container image, deployment tool or build runner. The malicious component may enter production through an apparently legitimate update. Controls include trusted repositories, dependency pinning, provenance records, isolated build environments, code signing and review of unusual deployment behaviour.

Cryptojacking and resource abuse

After compromising an account or workload, an attacker may run unauthorised computation for cryptocurrency mining or other purposes. Warning signs include unexpected resource growth, unusual regions, new instances, unfamiliar images and sudden billing changes. Budgets and alerts are useful detective controls, although cost alerts are not a substitute for access control.

Insider misuse

An employee, contractor or administrator may intentionally misuse access or may make a damaging mistake. Separation of duties, access reviews, monitoring, approval workflows and prompt removal of access reduce the opportunity and impact. Monitoring should be proportionate and transparent, respecting employment, privacy and data-protection requirements.

5. Threat modelling for a cloud workload

Threat modelling is a structured method for identifying how a system could be harmed and how its design can reduce that harm. It is most effective early in design and should be revisited after significant changes.

A practical certificate-level process is:

1. Define scope and assumptions. Identify the workload, trust boundaries, deployment regions, provider services and dependencies.
2. Inventory assets. Record data, identities, services, interfaces, keys, logs and recovery resources.
3. Draw the major data flows. Show users, applications, APIs, databases, administrators and external services.
4. Identify threats. Consider external attackers, insiders, accidental actions, provider failures and supply-chain events.
5. Identify vulnerabilities and existing controls. Record configuration, software, process and human weaknesses.
6. Estimate likelihood and impact. Use agreed definitions and evidence where available.
7. Select treatments. Avoid, reduce, transfer or accept the risk, with an accountable owner.
8. Verify and review. Test controls, record residual risk and reassess after change.

A useful conceptual model is STRIDE, which prompts consideration of spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. STRIDE is a brainstorming aid, not a complete risk-management method. It should be supplemented by privacy analysis, business-impact analysis and organisation-specific threat intelligence.

Threat modelling should identify trust boundaries. For example, a public user may be trusted to submit a request but not to choose another customer’s record identifier. A workload may be trusted to read one storage location but not to modify identity policies. Trust must be expressed as a verifiable rule rather than an assumption.

6. Basic risk assessment

A risk register records the reasoning behind treatment decisions. A compact structure is shown below.

Inherent risk is the risk before proposed additional controls. Residual risk is the risk remaining after controls are implemented and operating. A control should not be credited merely because it is documented; evidence should show that it is correctly configured and effective.

Worked example

An organisation scores likelihood and impact from 1 to 5. A public storage container contains non-public customer reports. The assessment team judges the likelihood of unauthorised disclosure as 4 and the impact as 5.

If the organisation defines scores 15–25 as high, this risk requires priority treatment. The team removes public access, applies explicit identity-based permissions, enables multi-factor authentication for administrators, activates access logging and tests alerts. After implementation, the team reassesses likelihood as 2 and impact as 5. Impact remains high because the data is still valuable, but the chance of exposure has been reduced.

The numerical result does not prove that the risk is acceptable. The organisation must compare it with its risk appetite, legal obligations, contractual requirements and the reliability of the controls. It should also consider whether the controls introduce availability or usability effects.

7. Risk treatment and governance

Risk treatment generally follows four choices:

• Avoid: discontinue the risky activity or redesign the service so the exposure no longer exists.
• Reduce: implement preventive, detective, corrective or recovery controls.
• Transfer or share: use insurance, contracts or a managed service arrangement, recognising that accountability is rarely completely transferred.
• Accept: consciously retain the risk when it is within appetite and the decision is documented by an authorised owner.

Security responsibilities are divided between the cloud provider and the customer. The provider usually protects physical facilities, underlying hardware and selected managed-service components. The customer commonly remains responsible for identities, data, configurations, applications and access decisions. The exact boundary varies by service model and contract. “The provider secures the cloud” does not mean that every customer workload is secure.

Governance requires policies, standards, roles, risk acceptance criteria, audit evidence and escalation paths. Relevant obligations may include privacy and data-protection laws, breach-notification duties, contractual commitments, records-management rules and requirements concerning data location. Legal interpretation belongs to qualified advisers, but cloud professionals must recognise when a technical decision has regulatory consequences.

Security logs may contain personal data, identifiers or employee activity. Their collection, retention, access and transfer should be justified, protected and aligned with applicable privacy requirements. Ethical security practice also requires proportional monitoring, respect for confidentiality and responsible disclosure of vulnerabilities.

8. Applied case: the exposed analytics environment

This is an illustrative case.

Background

A retail company moves its analytics platform to the cloud. Transaction data is copied nightly from production into object storage, where analysts and automated processing jobs use it to generate reports.

Problem

A security review detects that one storage location allows broad access. A contractor’s access key is stored in a deployment script, and audit logs are retained for only three days. The company initially believes the provider is responsible because the storage service is managed.

Analysis

The assets include transaction records, access keys, reports and the analytics service. Threat actors include external attackers, compromised contractors and careless insiders. The main attack paths are key theft, public or cross-account storage access and unauthorised copying by an analytics role. The vulnerabilities are excessive permissions, an exposed secret and inadequate monitoring. The impact includes privacy harm, regulatory exposure, loss of customer trust and investigation costs.

Approach and solution

The company first restricts access to approved identities and private network paths. It revokes and replaces the exposed key, then uses short-lived credentials through the deployment platform. Data is classified, encrypted and separated by environment. Analysts receive read-only access to defined datasets rather than the entire storage location. Logs are sent to a protected, central service with a retention period based on investigation and legal requirements. Alerts are created for public-access changes, unusual downloads and new privileged identities.

The company also introduces infrastructure-as-code review, periodic access recertification, secret scanning and a documented incident-response process. A restoration exercise confirms that the data can be recovered without restoring the insecure configuration.

Outcome

The exposure is removed, access becomes attributable to individual identities, and the organisation can investigate abnormal use more effectively. Residual risk remains because authorised users and trusted services can still misuse data. That risk is documented and reviewed by the data owner.

Learning points

The case demonstrates that a managed cloud service does not eliminate customer configuration responsibility. It also shows that identity, data, logging, deployment practices and governance must be treated as one system. A single exposed key can turn a minor configuration weakness into a major data incident.

9. Limitations and contemporary developments

Risk scores can create false confidence. Different assessors may assign different values, and multiplying ordinal categories does not create a scientifically precise probability. Assessments should therefore record assumptions, evidence and uncertainty. Where reliable financial or statistical data exists, quantitative analysis may supplement—not replace—expert judgement.

Cloud environments also change rapidly. Ephemeral containers, serverless functions, machine-learning services and automated pipelines may exist briefly or be created at large scale. Traditional periodic audits may miss short-lived exposures. Continuous control monitoring, asset discovery and machine-readable policy are increasingly important.

Artificial intelligence can assist with log analysis, configuration comparison, alert triage and threat-intelligence summarisation. However, AI-generated recommendations may be incomplete, overconfident or based on sensitive data. Human review remains necessary, especially for destructive remediation, access decisions and incident attribution. Organisations should protect prompts and training data, test for misleading outputs and retain accountability for decisions.

Best-practice checklist

• Maintain an accurate inventory of cloud accounts, services, identities and data.
• Classify data and assign accountable owners.
• Require multi-factor authentication for privileged access.
• Prefer short-lived credentials and managed secret storage.
• Apply least privilege and review permissions regularly.
• Separate development, test and production environments.
• Use secure templates, infrastructure as code and peer review.
• Continuously assess configuration and exposed services.
• Encrypt sensitive data appropriately and protect keys separately.
• Centralise logs, protect their integrity and test alerting.
• Monitor unusual identity, data-transfer and billing activity.
• Patch workloads and manage software dependencies.
• Protect backups and test restoration.
• Exercise incident response and document residual risk.
• Reassess threats after architectural, supplier or regulatory change.

Chapter Summary

Cloud risk arises when threats can exploit vulnerabilities affecting valuable assets. Cloud attack surfaces include identities, APIs, networks, applications, data stores, supply chains and human processes. Misconfiguration—especially excessive access, public exposure, weak logging and insecure secrets—is a major source of incidents.

Threat modelling provides a repeatable way to define scope, identify assets and trust boundaries, analyse threats and vulnerabilities, estimate likelihood and impact, select treatments and verify residual risk. The basic model Risk = Likelihood × Impact is useful for consistent prioritisation when scales and assumptions are clearly defined. Risk treatments may avoid, reduce, transfer or accept risk. Effective security depends on shared responsibility, governance, evidence, privacy-aware monitoring and continuous reassessment.

Key Terms

Asset: Something valuable that requires protection.

Attack surface: The points through which a system may be entered, influenced or exploited.

Cloud configuration: The settings controlling a cloud resource’s behaviour and access.

Control: A safeguard that prevents, detects, responds to or recovers from adverse events.

Exfiltration: Unauthorised transfer of data out of an environment.

Impact: The severity of consequences if a risk event occurs.

Inherent risk: Risk assessed before proposed additional controls.

Least privilege: Giving an identity only the access necessary for its task.

Misconfiguration: An insecure or unintended setting or combination of settings.

Residual risk: Risk remaining after controls are implemented.

Risk: The possibility that a threat exploits a vulnerability and causes harm.

Risk appetite: The amount and type of risk an organisation is willing to accept.

Risk treatment: An action to avoid, reduce, transfer or accept risk.

Threat: A potential cause of an unwanted security event.

Threat actor: A person, group or process capable of causing harm.

Threat modelling: Structured analysis of how a system may be attacked or fail.

Trust boundary: A point where assumptions about authority or security change.

Vulnerability: A weakness that may be exploited or triggered.

Review Questions

Short Answer Questions

1. Distinguish between a threat, a vulnerability and a risk.
2. Why is identity considered a major cloud security boundary?
3. Give three examples of cloud misconfiguration.
4. What is the purpose of a trust boundary in threat modelling?
5. Differentiate inherent risk from residual risk.

Long Answer Questions

1. Explain the major attack surfaces of a typical cloud-hosted application.
2. Describe a practical threat-modelling process for a cloud workload.
3. Explain how the shared-responsibility model affects cloud security decisions.
4. Compare the four principal risk-treatment choices and give an example of each.
5. Discuss why logging, monitoring and tested backups are important even when preventive controls are strong.

Analytical / Application Questions

1. A cloud database is reachable from the internet, uses a shared administrator account and has no multi-factor authentication. Identify the assets, threats, vulnerabilities and immediate treatments.
2. An organisation rates likelihood as 3 and impact as 4 on a 1–5 scale. Calculate the risk score, explain what the score means, and identify two limitations of this calculation.
3. Design a short threat model for an online payment API. Identify at least three trust boundaries, two possible threat actors, three attack paths and suitable controls.

Multiple Choice Questions with Answers

Question 1

Which statement best defines a vulnerability?

A. A valuable item that requires protection

B. A weakness that may be exploited or triggered

C. The consequence of a security incident

D. A person who investigates incidents

Correct Answer: B. A weakness that may be exploited or triggered

Question 2

Which cloud resource is most directly an identity attack surface?

A. A service account with excessive permissions

B. A physically locked data centre

C. A cooling system

D. A printed network diagram

Correct Answer: A. A service account with excessive permissions

Question 3

What is the main purpose of threat modelling?

A. To guarantee that no attack can occur

B. To replace all security testing

C. To systematically identify threats, weaknesses and treatments

D. To calculate cloud-provider billing

Correct Answer: C. To systematically identify threats, weaknesses and treatments

Question 4

A risk is scored with likelihood 4 and impact 5. Using Risk = Likelihood × Impact, what is the score?

A. 9

B. 15

C. 20

D. 25

Correct Answer: C. 20

Question 5

Which practice most directly supports least privilege?

A. Giving every administrator full access

B. Granting only the permissions needed for an assigned task

C. Sharing one account among a team

D. Disabling access reviews

Correct Answer: B. Granting only the permissions needed for an assigned task

Question 6

Which is an example of risk avoidance?

A. Adding monitoring to an existing service

B. Buying insurance for a possible loss

C. Accepting a documented residual risk

D. Discontinuing a high-risk activity

Correct Answer: D. Discontinuing a high-risk activity

Question 7

Why are short-lived credentials generally preferable to long-lived access keys?

A. They eliminate the need for authorisation

B. They reduce the time available for misuse if compromised

C. They make logging unnecessary

D. They guarantee encryption of all data

Correct Answer: B. They reduce the time available for misuse if compromised

Question 8

In the illustrative analytics case, what was a key customer responsibility?

A. Maintaining the provider’s physical building

B. Replacing the provider’s hardware

C. Configuring access, credentials and logging securely

D. Designing the provider’s cooling system

Correct Answer: C. Configuring access, credentials and logging securely

Question 9

What does residual risk describe?

A. Risk remaining after controls operate

B. Risk before any asset is identified

C. Only the risk transferred to an insurer

D. A threat actor’s motivation

Correct Answer: A. Risk remaining after controls operate

Question 10

Which statement about the risk multiplication model is most accurate?

A. It produces a precise probability in every case

B. It is useful for consistent prioritisation when scales and assumptions are defined

C. It proves that a score below 10 is legally acceptable

D. It removes the need for professional judgement

Correct Answer: B. It is useful for consistent prioritisation when scales and assumptions are defined