Foundations of Cloud Security and Risk

Introduction

Cloud computing has changed the location, ownership and operation of information systems. Computing resources that were once purchased, installed and managed inside an organisation are now commonly delivered as elastic services through a network. This change creates important advantages: rapid provisioning, global availability, flexible capacity and consumption-based pricing. It also changes security responsibilities and introduces dependencies on providers, application programming interfaces, identity systems, automation pipelines and interconnected services.

Cloud security is therefore not simply traditional security moved to a remote data centre. It is the protection of cloud-hosted data, applications, identities, workloads and management interfaces while recognising that infrastructure ownership and operational responsibility may be shared. Risk management provides the systematic process for identifying possible harmful events, assessing their likelihood and consequences, selecting controls and monitoring whether risk remains acceptable.

This chapter establishes the concepts required for later study of cloud governance, identity and access management, data protection, monitoring, incident response and compliance.

Learning Objectives

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

1. Explain the principal cloud service and deployment models.
2. Distinguish assets, threats, vulnerabilities, controls, risks and incidents.
3. Explain the relationship between threat, vulnerability, likelihood, impact and risk.
4. Identify cloud attack surfaces and trust boundaries.
5. Classify security controls by purpose, nature and timing.
6. Compare traditional information security with cloud security.
7. Apply a structured approach to analysing a cloud-security scenario.
8. Recognise governance, ethical and regulatory implications of cloud adoption.

1. Cloud Computing as a Security Context

A cloud environment normally provides on-demand access to shared computing resources that can be rapidly provisioned and released. Essential characteristics include broad network access, resource pooling, measured service and elasticity. These characteristics affect security in distinctive ways:

• Elasticity can create resources faster than governance processes can review them.
• Resource pooling means multiple customers may use logically isolated resources on shared physical infrastructure.
• Self-service enables speed but can also enable unauthorised or poorly configured deployments.
• Application programming interfaces (APIs) become powerful control points and attractive targets.
• Measured service produces extensive activity and billing data that can support detection and accountability.
• Geographical distribution may create legal and regulatory questions concerning data location and access.

A useful security objective is the protection of confidentiality, integrity and availability (the CIA triad). Confidentiality limits unauthorised disclosure; integrity protects accuracy and trustworthiness; availability supports authorised access when required. Modern programmes often add authenticity, accountability, privacy, resilience and safety.

Security objectives must be connected to business requirements. For example, a public marketing website may prioritise availability and integrity, whereas a health-record system may place exceptional emphasis on confidentiality, integrity, privacy and auditability.

2. Cloud Service Models

Service models describe which layers are operated by the provider and which remain the customer’s responsibility.

These are general patterns rather than universal contracts. A provider’s service description, customer agreement and security documentation determine the actual division of duties. A customer can remain responsible for a poorly protected identity or an exposed data store even when the provider operates the underlying infrastructure.

The Shared-Responsibility Principle

The provider is generally responsible for security of the cloud, including physical facilities and core infrastructure. The customer is responsible for security in the cloud, including appropriate data handling, identity configuration and workload security. Responsibilities vary by service model.

Figure: The customer’s security responsibilities generally decrease at the infrastructure layer as the provider manages more of the service stack; customer governance responsibilities remain important in every model.

3. Cloud Deployment Models

A deployment model describes who can use the environment and how infrastructure is organised.

• Public cloud: Resources are offered to multiple customers by a provider. Strong logical isolation, identity management and contractual assurance are essential.
• Private cloud: The environment is dedicated to one organisation. It may be operated internally or by a third party. Private does not automatically mean secure; poor configuration remains possible.
• Community cloud: Infrastructure is shared by organisations with common requirements, such as regulatory or mission objectives.
• Hybrid cloud: Two or more distinct environments are connected for portability, integration or workload placement. The connection creates additional identity, network and data-transfer risks.
• Multi-cloud: An organisation uses services from several providers. This can improve flexibility and resilience but increases policy, skills, monitoring and integration complexity.

Deployment and service models are independent dimensions. An organisation may use SaaS in a public cloud, IaaS in a private cloud and PaaS across a hybrid architecture.

4. Essential Security Terminology

An asset is something valuable that requires protection, such as data, a service, identity, device, key, reputation or business process. A threat is a potential cause of harm. Threats may be deliberate, accidental, environmental or systemic. Examples include credential theft, malicious insiders, software defects, outages and supply-chain compromise.

A vulnerability is a weakness that could be exploited or otherwise contribute to harm. Examples include excessive permissions, unpatched software, exposed storage, weak secrets management and inadequate logging. A vulnerability is not itself an incident.

An exploit is a method or technique used to take advantage of a vulnerability. An attack is an attempt to compromise security. A security event is an observable occurrence relevant to security; a security incident is an event or series of events that actually or potentially compromises confidentiality, integrity or availability and requires response.

A control is a measure that modifies risk. Controls may prevent, detect, correct, deter, compensate or recover. A policy expresses required behaviour; a standard defines mandatory specifications; a procedure describes operational steps; a guideline provides recommended practice.

Authentication establishes who or what an entity is. Authorisation determines what that entity may do. Accounting or auditability records relevant actions. Confusing authentication with authorisation is a common cause of cloud exposure: proving identity does not establish that every requested action is permitted.

Least privilege grants only the permissions necessary for an approved task. Zero trust is an architectural approach in which access is continuously evaluated rather than automatically trusted because of network location. Encryption transforms readable information into protected ciphertext using a cryptographic process; key management determines much of its practical security.

5. Threat, Vulnerability and Risk

Risk is commonly understood as the effect of uncertainty on objectives. In practical security analysis, risk is often represented qualitatively or approximately as a combination of likelihood and impact:

Likelihood describes the chance or plausibility of an unwanted event within a defined period, while impact describes the consequence if it occurs. The expression is a decision aid, not a universal physical law. Its use assumes that the organisation has defined a scenario, a time horizon and a meaningful scale for likelihood and impact. Numerical multiplication is only defensible when the scales and interpretation have been designed for that purpose; otherwise, ordinal categories such as low, medium and high should not be treated as precise quantities.

A more complete scenario statement is: “A threat actor exploits a publicly exposed administrative interface using stolen credentials, causing unauthorised access to customer records.” This formulation identifies the threat, vulnerability, asset and consequence.

Controls reduce risk in several ways. Preventive controls reduce the likelihood of occurrence; detective controls improve discovery; corrective controls limit damage or restore normal operation. Residual risk is the risk remaining after controls are implemented. Inherent risk is assessed before considering existing controls. Risk appetite expresses the level and type of risk an organisation is willing to accept; risk tolerance sets acceptable variation around objectives.

Worked Application: Qualitative Risk Assessment

Suppose a cloud storage service contains confidential contracts. The assessment team rates the likelihood of accidental public exposure as high because several teams can change access policies. Impact is rated high because disclosure could breach contractual and privacy obligations. The inherent risk is therefore high.

The organisation introduces preventive controls (policy-as-code blocking public storage), detective controls (continuous configuration monitoring) and corrective controls (rapid revocation and restoration procedures). The likelihood may fall to medium and the impact remains high because exposure would still be serious if it occurred. Residual risk is consequently medium-to-high, not zero. Management must decide whether further controls, insurance, contractual changes or risk acceptance are appropriate.

This example illustrates that controls do not necessarily eliminate a hazard. They alter likelihood, impact, detectability, recovery time or confidence in the assessment.

6. Attack Surfaces and Trust Boundaries

An attack surface is the collection of points through which an attacker may attempt access, influence or disruption. In cloud environments it includes:

• Internet-facing applications, load balancers and APIs.
• Identity providers, privileged accounts, access keys and federation links.
• Management consoles, command-line tools and infrastructure-as-code pipelines.
• Virtual machines, containers, images, functions and orchestration platforms.
• Storage buckets, databases, queues and backup repositories.
• Endpoints used by administrators and developers.
• Third-party software, managed services and supply-chain dependencies.
• Network paths between on-premises systems, clouds and partner environments.
• Logs, metadata and monitoring systems.

A trust boundary is a point where the assumptions, authority or security controls governing one component differ from those governing another. Examples include the boundary between a customer tenant and provider infrastructure, between a corporate identity provider and a SaaS application, between a production account and a development account, and between an application and a third-party API.

Crossing a trust boundary should require explicit authentication, authorisation, validation and monitoring. Network reachability alone should not be interpreted as trust. Segmentation, separate accounts, workload identities, strong API validation and central logging help reduce the consequences of boundary compromise.

7. Control Types and Control Design

Controls can be classified using several complementary dimensions.

No single classification is sufficient. Multi-factor authentication is a technical and preventive control, while an access-review policy is administrative and preventive. A tested backup is a technical recovery capability, but its effectiveness also depends on administrative ownership and periodic exercises.

Good control design follows a risk-based process: define the protected asset and threat scenario, identify obligations, select proportionate controls, assign ownership, establish evidence and test effectiveness. Controls should be usable. Excessive approval friction can encourage workarounds, while weak controls can create a false sense of assurance.

Control effectiveness differs from control existence. A policy document may exist without staff awareness, technical enforcement or evidence of operation. Assurance therefore requires configuration review, access recertification, vulnerability testing, log analysis, exercises and independent assessment where appropriate.

8. Traditional and Cloud Security Compared

Traditional security often assumes relatively stable physical networks, known data-centre boundaries, long-lived servers and central infrastructure teams. Cloud security must address distributed control planes, ephemeral resources, software-defined networks, continuous deployment, provider dependencies and identities that operate across organisational boundaries.

Traditional controls remain relevant. Firewalls, secure coding, backups, encryption, personnel screening and incident response continue to matter. The difference is that cloud environments demand greater automation, stronger identity governance, rapid configuration assessment and explicit management of provider and supply-chain risk.

9. Governance, Ethics and Regulation

Cloud security is a governance issue as well as a technical issue. Boards and managers must define risk appetite, approve architectures, allocate accountability and verify that providers meet business and legal requirements. Contracts should address data ownership, location, subcontractors, breach notification, audit rights, service levels, retention, deletion and secure exit.

Regulatory requirements vary by jurisdiction and sector. Common concerns include privacy, records retention, financial controls, critical infrastructure, health information and cross-border transfers. Compliance is not equivalent to security: a certification may provide evidence about a control environment, but it does not guarantee correct customer configuration or eliminate all risk.

Ethical practice requires proportional collection, lawful and transparent use of data, protection against discriminatory outcomes, respect for confidentiality and responsible disclosure of vulnerabilities. Artificial intelligence can assist with alert triage, configuration analysis and anomaly detection, but it can also expose sensitive data, produce false positives, amplify bias or obscure accountability. Human oversight, data minimisation, testing and clear decision authority remain necessary.

10. Applied Case: Northstar Retail’s Cloud Migration

Background

Northstar Retail, an illustrative organisation, migrates its online ordering platform to public-cloud IaaS and PaaS services. Customer information is stored in a managed database, while developers use infrastructure-as-code and a central identity provider.

Problem

A security review discovers that a developer’s access key is stored in a public code repository. A storage service is configured for public access, production and development accounts share administrative roles, and logs are retained for only three days. The provider’s underlying infrastructure is well protected, but Northstar’s configuration creates substantial customer risk.

Analysis

The exposed key is a credential vulnerability and a potential attack path across a trust boundary. The public storage configuration threatens confidentiality. Shared administrative roles increase blast radius and reduce accountability. Short log retention limits detection and investigation. The principal issue is not that “the cloud is insecure”; it is that customer responsibilities were not designed, assigned or continuously verified.

Approach and Solution

Northstar immediately revokes and rotates the key, investigates repository and access logs, and determines whether data was accessed. It then separates accounts, applies least privilege and requires multi-factor authentication for privileged access. Storage policies block public exposure unless an approved exception exists. Secrets move to a managed secrets service. Infrastructure-as-code undergoes peer review and automated policy checks before deployment. Central logs are protected from alteration and retained according to legal and investigative requirements. The incident-response plan is tested with the provider.

Outcome

The organisation reduces the probability of recurring exposure, improves detection and establishes clearer accountability. Residual risk remains because compromised credentials, provider outages and application defects cannot be eliminated entirely. Management records accepted risks and schedules recurring access reviews and configuration assessments.

Learning Points

1. Shared responsibility must be translated into named ownership and evidence.
2. Identity and configuration errors can be more immediate than physical infrastructure threats.
3. Automation is valuable only when its policies are correct and its outputs are reviewed.
4. Incident response begins before an incident through logging, key rotation and tested procedures.
5. Risk decisions should consider business impact, legal duties and customer trust.

11. Best-Practice Foundation

A sound cloud-security foundation includes:

• Maintain an inventory of accounts, services, data, identities and dependencies.
• Classify data and map it to legal, contractual and business requirements.
• Use central identity governance, multi-factor authentication and least privilege.
• Separate development, testing and production environments.
• Protect secrets and keys through managed lifecycle processes.
• Apply secure configuration baselines and policy-as-code.
• Secure software supply chains, images, dependencies and deployment pipelines.
• Encrypt sensitive data in transit and at rest, while governing key access.
• Centralise, protect and review logs; synchronise time where possible.
• Test backups, recovery, incident response and provider failure assumptions.
• Monitor provider changes, subcontractors, service health and contractual obligations.
• Review access and configurations continuously rather than only at audit time.

Chapter Summary

Cloud security protects data, workloads, identities, applications and services in an environment characterised by elasticity, shared resources, APIs and provider dependence. IaaS, PaaS, SaaS and serverless models allocate operational responsibilities differently, while public, private, community, hybrid and multi-cloud models describe deployment arrangements. The shared-responsibility principle requires customers to understand and operate their part of the security boundary.

Assets, threats, vulnerabilities, exploits, incidents, controls and risks are distinct concepts. Risk is usefully analysed through defined scenarios involving likelihood and impact, but qualitative judgements must not be treated as precise measurements without valid scales and assumptions. Attack surfaces include interfaces, identities, workloads, data stores, pipelines and third parties. Trust boundaries identify places where authority or security assumptions change.

Controls may be administrative, technical or physical and may prevent, detect, correct, deter, compensate or recover. Cloud security retains traditional security principles but places greater emphasis on identity, automation, continuous monitoring, configuration management, provider assurance and resilience. Effective practice combines technology, governance, ethical conduct, contractual clarity and tested response capabilities.

Key Terms

Asset: Something valuable that requires protection.

Attack surface: The set of points through which compromise or disruption may be attempted.

Authentication: The process of establishing an identity.

Authorisation: The process of determining permitted actions.

Cloud computing: On-demand network access to shared, elastic computing resources.

Control: A measure that modifies security risk.

Exploit: A technique that takes advantage of a vulnerability.

Incident: An event or events that actually or potentially compromise security.

Integrity: Protection against unauthorised alteration or destruction.

Least privilege: Granting only the permissions necessary for an approved task.

Likelihood: The assessed chance or plausibility of an event.

Impact: The consequence of an event for objectives or assets.

Residual risk: Risk remaining after controls are applied.

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

Shared responsibility: Division of cloud security duties between provider and customer.

Threat: A potential cause of harm.

Trust boundary: A point where authority, assumptions or controls change.

Vulnerability: A weakness that may contribute to harm.

Zero trust: An approach that requires explicit and continually evaluated access decisions.

Review Questions

Short Answer Questions

1. What is meant by the shared-responsibility model in cloud security?
2. Distinguish authentication from authorisation.
3. Define a vulnerability and give one cloud example.
4. What is a trust boundary?
5. Name three cloud attack-surface components.

Long Answer Questions

1. Compare IaaS, PaaS and SaaS in terms of provider and customer responsibilities.
2. Explain how elasticity, self-service and APIs affect cloud-security risk.
3. Discuss the differences between traditional perimeter security and cloud identity-centric security.
4. Explain the purpose and limitations of preventive, detective and corrective controls.
5. Describe how governance and contractual management complement technical cloud controls.

Analytical / Application Questions

1. A company discovers that a production database is reachable from the internet and protected by a shared administrator account. Identify the assets, threats, vulnerabilities, trust boundaries and initial controls involved.
2. An organisation adopts several cloud providers to improve resilience. Analyse at least four new risks introduced by multi-cloud adoption and propose corresponding controls.
3. Using a qualitative likelihood-impact approach, assess the risk of a stolen developer credential being used to alter production infrastructure. State your assumptions and recommend preventive, detective and corrective controls.

Multiple Choice Questions with Answers

Question 1

Which cloud service model generally leaves the customer responsible for the guest operating system?

A. Infrastructure as a Service (IaaS)

B. Software as a Service (SaaS)

C. Managed email only

D. Physical colocation managed entirely by the provider

Correct Answer: A. Infrastructure as a Service (IaaS)

Question 2

Which statement best describes a vulnerability?

A. A potential cause of harm

B. A weakness that may contribute to harm

C. A completed recovery action

D. A business objective

Correct Answer: B. A weakness that may contribute to harm

Question 3

What is the primary purpose of authentication?

A. To determine permitted actions

B. To establish an identity

C. To encrypt all stored data

D. To restore service availability

Correct Answer: B. To establish an identity

Question 4

Which control is primarily detective?

A. Multi-factor authentication

B. Network segmentation

C. Continuous alerting on unusual administrator activity

D. A secure deletion procedure

Correct Answer: C. Continuous alerting on unusual administrator activity

Question 5

Which item is most clearly part of a cloud attack surface?

A. An isolated paper filing cabinet with no digital connection

B. A public management API

C. A building’s unrelated lighting system

D. A documented business objective

Correct Answer: B. A public management API

Question 6

What does residual risk mean?

A. Risk before any controls are considered

B. Risk transferred to a different department only

C. Risk remaining after controls are applied

D. Risk that can never be documented

Correct Answer: C. Risk remaining after controls are applied

Question 7

Why does a public-cloud deployment not automatically make an organisation’s data secure?

A. Public clouds have no security controls

B. The customer remains responsible for configuration, identities and data protection

C. Encryption cannot be used in public clouds

D. Public clouds cannot provide audit logs

Correct Answer: B. The customer remains responsible for configuration, identities and data protection

Question 8

Which practice best reflects least privilege?

A. Giving every developer permanent administrator access

B. Allowing access only to the resources and actions required for a task

C. Sharing one account among a project team

D. Disabling audit logs to simplify administration

Correct Answer: B. Allowing access only to the resources and actions required for a task

Question 9

Which characteristic most distinguishes cloud security from a purely traditional perimeter approach?

A. Cloud environments require no physical security

B. Cloud environments place increased emphasis on identity, APIs and continuous configuration management

C. Traditional controls such as backups become irrelevant

D. Cloud customers never depend on third parties

Correct Answer: B. Cloud environments place increased emphasis on identity, APIs and continuous configuration management

Question 10

In the expression Risk ≈ Likelihood × Impact, what does impact represent?

A. The assessed consequence if the unwanted event occurs

B. The number of user accounts in the system

C. The speed of an API request

D. The age of the cloud service

Correct Answer: A. The assessed consequence if the unwanted event occurs