The following is an excerpt from The Official (ISC)2 Guide to the CCSP CBK, Second Edition, by Adam Gordon, CISSP-ISSAP, ISSMP, SSCP. This section from Domain 1 describes nine cloud security threats waiting to pounce on unsuspecting enterprises. Whether you’re managing a public, private or hybrid cloud, it’s essential for information security professionals to understand where vulnerabilities lie and how to mitigate them.

Threats form a real and ever-evolving challenge for organizations to counteract and defend against. Whether they are specifically cloud security threats or general disruptions to business and technology, threats can cause significant issues, outages, poor performance, and catastrophic impacts should they materialize.

Many of the top risks identified in the research paper The Notorious Nine: Cloud Computing Top Threats, published by the Cloud Security Alliance’s Top Threats Working Group, remain a challenge for non-cloud-based environments and organizations alike. What this illustrates is the consistent challenges faced by entities today, altered and amplified by different technology deployments, such as cloud computing.

Data Breaches
Not new to the security practitioner and company leaders, this age-old challenge continues to dominate headlines and new stories around the world. Whether it is a lost laptop that is unencrypted or side channel timing attacks on VMs, what cloud computing has done is widen the scope and coverage for data breaches.

Given the nature of cloud deployments and multitenancy, VMs, shared databases, application design, integration, APIs, cryptography deployments, key management, and multiple locations of data all combine to provide a highly amplified and dispersed attack surface, leading to greater opportunity for cloud security threats and data breaches.

Cloud security professionals can expect to be facing far more data breaches and loss of organizational and personal information as the adoption of the cloud and further use of mobile devices continue to increase. This is in large measure due to the rise of smart devices, tablets, increased workforce mobility, bring your own device (BYOD), and other factors, such as the historical challenge of lost devices, compromised systems, and traditional forms of attacks, coupled with the previously listed factors related to the cloud.

Depending on the data and information classification types, any data breaches or suspected breaches of systems security controls may require mandatory breach reporting to relevant agencies, entities, or bodies. This can include healthcare information (HIPAA), personally identifiable information (Directive 95/46/EC of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data), and credit card information (PCI DSS).

Significant fines may be imposed on organizations that cannot illustrate sufficient duty of care or security controls being implemented to prevent such data breaches. These vary greatly depending on the industry, sector, geographic location, and nature of the information.

Data Loss
Not to be confused with a data breach, data loss refers to the loss of information, deletion, overwriting, corruption, or integrity related to the information stored, processed, or transmitted within cloud environments.

Data loss within cloud environments can present a significant threat and challenge to organizations. The reasons for its relevance to cloud security threats can be illustrated by the following questions:

Does the provider or customer have responsibility for data backup?
If backup media containing the data is obtained, does this include all data or only a portion of the information?
Where data has become corrupt or overwritten, can an import or restore be performed?
Where accidental data deletion has occurred from the customer side, will the provider facilitate the restoration of systems and information in multitenancy environments or on shared platforms?
Note that when the customer uploads encrypted information to the cloud environment, the encryption keys become a critical component to ensure data is not lost and remains available. The loss of the relevant encryption keys constitutes data loss because the information will no longer be available for use in the absence of the keys.

Security can from time to time come back to haunt you if it is not owned, operated, and maintained effectively and efficiently.

Account or service traffic hacking
This is not a cloud security threat specifically but one that has been a constant thorn and challenge for relevant security professionals to combat through the years. Account and service traffic hijacking has long been targeted by attackers, using methods such as phishing, more recently smishing (SMS phishing), spear phishing (targeted phishing attacks), and exploitation of software and other application-related vulnerabilities.

The key component of these attack methods, when successful, allows for the attackers to monitor and eavesdrop on communications, sniff and track traffic, capture relevant credentials, and access and alter account and user profile characteristics (changing passwords and more).

Of late, attackers are utilizing compromised systems, accounts, and domains as a smokescreen to launch attacks against other organizations and entities, making the source of the attack appear to be from suppliers, third parties, competitors, or other legitimate organizations that have no knowledge or awareness of having been compromised.

Insecure Interfaces and APIs
For users to access cloud computing assets and resources, they utilize the APIs made available by the CSP. Key functions of the APIs, including the provisioning, management, and monitoring, are performed utilizing the provider interfaces. For the security controls and availability of resources to function in the way that they were designed, use of the provider APIs is required to prevent against deliberate and accidental attempts to circumvent policies and controls.

Sounds simple enough, right? In an ideal world, that may be true, but for the modern and evolving landscape riddled with cloud security threats, that challenge is amplified with relevant third parties, organizations, and customers (depending on deployment) building additional interfaces and “bolt on” components to the API, which significantly increase the complexity, resulting in a multilayered API. This can result in credentials being passed to third parties or consumed insecurely across the API and relevant stack components.

Note that most providers make concerted efforts to ensure the security of their interfaces and APIs to minimize cloud security threats; however, any variations or additional components added on from the consumer or other providers can reduce the overall security posture and stance.

Denial of Service
By their nature, denial-of-service (DoS) attacks prevent users from accessing services and resources from a specified system or location. This can be done using any number of attack vectors available but typically look to target buffers, memory, network bandwidth, or processor power.

With cloud services relying ultimately on availability to service and enable connectivity to resources from customers, DoS attacks can become significant cloud security threats. When DoS attacks are targeted at cloud environments, they can create significant challenges for the provider and customer alike.

Distributed denial-of-service (DDoS) attacks are launched from multiple locations against a single target Work with the cloud security architect to ensure that system design and implementation do not create an single point of failure that can expose an entire system to failure if a DoS or DDoS attack is successfully launched against a system.

Note that although it’s widely touted by the media and feared by organizations worldwide, many believe that DoS attacks require large volumes of traffic to be successful. This is not always the case; asymmetric application-level payload attacks have measured success with as little at 100-150 Kbps packets.

Malicious insiders
When looking to secure the key assets of any organization, three primary components are essential—people, processes, and technology. People tend to present the single largest challenge to security due to the possibility of a disgruntled, rogue, or simply careless employee or contractor exposing sensitive data either by accident or on purpose.

According to CERT, malicious insider threats to an organization can come from “a current or former employee, contractor, or other business partner who has or had authorized access to an organization’s network, system, or data and intentionally exceeded or misused that access in a manner that negatively affected the confidentiality, integrity, or availability of the organization’s information or information systems.

Abuse of cloud services
Think of the ability to have previously unobtainable and unaffordable computing resources available for a couple of dollars an hour. Well, that is exactly what cloud computing provides—an opportunity for businesses to have almost unlimited scalability and flexibility. The challenge for many organizations is that this scalability and flexibility are provided across the same platforms or resources that attackers can access and use to execute dictionary attacks, execute DoS attacks, crack encryption passwords, host illegal software and materials for widespread distribution, or implement many other types of cloud security threats. Note that the power of the cloud is not always used in the manner for which it is offered to users.

Insufficient Due Diligence
Cloud computing has created a revolution among many users and companies with regard to how they utilize technology-based solutions and architectures. As with many such technology changes and revolutions, some have acted before giving the appropriate thought and due care to what a secure architecture would look like and what would be required to implement one.

Cloud computing has, for many organizations, become that rash decision—intentionally or unintentionally. The change in roles, focus, governance, auditing, reporting, strategy, and other operational elements requires a considerable investment on the part of the business in a thorough risk-review process, as well as amendments to business processes.

Given the immaturity of the cloud computing market, many entities and providers are still altering and refining the way they operate. There will be acquisitions, changes, amendments, and revisions in the way in which entities offer services, which can influence both customers and partners.

Finally, when the dust settles in the race for cloud space, pricing may vary significantly, rates and offerings may be reduced or inflated, and cloud security threats could force customers to review and revise their selection of a CSP. Should your provider go bankrupt are you in a position to change CSPs in a timely and seamless manner?

It is incumbent upon the cloud security professional to ensure that both due care and due diligence are being exercised in the drive to the cloud.

Due diligence is the act of investigating and understanding the risks a company faces.

Due care is the development and implementation of policies and procedures to aid in protecting the company, its assets, and its people from threats.

Note that cloud companies may merge, be acquired, go bust, change services, and ultimately change their pricing model. Those that fail to carry out the appropriate due diligence activities may in fact be left with nowhere to go or turn to unless they introduce compensating controls to offset such risks (potentially resulting in less financial benefit).

Shared Technology Vulnerabilities
For CSPs to effectively and efficiently deliver their services in a scalable way, they share infrastructure, platforms, and applications among tenants and potentially with other providers. This can include the underlying components of the infrastructure, resulting in shared threats and vulnerabilities.

Why Docker Container Portability Matters

One of the most compelling reasons teams adopt Docker is the ability to build an application once and run it consistently across laptops, on-premises servers, and public cloud environments. A container that passes QA on a developer’s workstation behaves identically in staging and production because the entire runtime environment — libraries, configuration, and application code — is bundled into the container image.

This stands in sharp contrast to traditional deployment models, where differences in operating system versions, installed packages, or environment variables frequently caused the dreaded “works on my machine” problem.

The Foundation: Docker Images and Layers

A Docker image is not a single monolithic file. Instead, it is composed of a stack of read-only layers, each representing a discrete set of filesystem changes. When you write a Dockerfile, each instruction (FROM, RUN, COPY, ADD, etc.) typically produces a new layer on top of the previous one.

# Example Dockerfile illustrating layer creation
FROM ubuntu:22.04          # Layer 1 – base OS
RUN apt-get update && \
    apt-get install -y python3  # Layer 2 – installed packages
COPY app/ /app             # Layer 3 – application code
CMD ["python3", "/app/main.py"]

Each layer is content-addressed using a cryptographic hash. Docker (and the OCI image specification it influenced) can therefore:

• Cache layers locally — if a layer already exists on the host, it is not downloaded again.
• Share layers between images — two images that share the same base layer store that layer only once on disk.
• Verify integrity — any tampering with a layer changes its hash, making it immediately detectable.

Copy-on-Write: The Key to Efficient Portability

When Docker starts a container from an image, it does not copy all the image data into a new location. Instead, it adds a thin, writable container layer on top of the read-only image layers. This is the copy-on-write (CoW) strategy.

Here is how CoW works in practice:

1. Read operations are served directly from whichever image layer contains the file — no copying occurs.
2. Write operations trigger a copy of the targeted file from the image layer up into the writable container layer. Subsequent writes to the same file stay in the container layer.
3. Deletes are recorded as a “whiteout” marker in the container layer; the underlying image layer is left untouched.

The practical result is that spinning up dozens of containers from the same image consumes very little additional disk space — each container only stores its own delta, not a full copy of the image.

Storage Drivers That Implement CoW

Docker delegates the actual CoW filesystem work to a pluggable storage driver. Common options include:

overlay2 is the recommended and most widely used driver. It uses the Linux kernel’s OverlayFS to merge multiple directory trees into a single unified view, providing excellent performance and broad compatibility.

How Portability Is Achieved End-to-End

Combining layered images with CoW storage enables the full portability workflow:

1. Build — docker build assembles layers from a Dockerfile and tags the resulting image.
2. Push — docker push uploads only the layers that the target registry does not already have.
3. Pull — on any Docker host, docker pull downloads only the missing layers.
4. Run — docker run instantiates a container in seconds by adding a writable CoW layer; no full image copy is needed.

Because the image layers are immutable and content-addressed, the container running in a CI pipeline is byte-for-byte identical to the one that will run in production — regardless of the underlying host OS distribution, cloud provider, or hardware architecture (assuming the same CPU architecture).

Additional Factors That Reinforce Portability

Layered storage is the core mechanism, but several other Docker features reinforce portability:

• Self-contained environment — the image bundles all dependencies, eliminating reliance on host-installed libraries.
• Environment variables and secrets injection — runtime configuration is passed at docker run time, keeping images environment-agnostic.
• Docker Compose and orchestration manifests — multi-container applications are described declaratively, making entire stacks reproducible across environments.
• OCI standards — Docker images conform to the Open Container Initiative (OCI) image specification, meaning they can be run by any OCI-compliant runtime (containerd, Podman, etc.), not just the Docker Engine.

Limitations to Keep in Mind

Docker container portability is powerful but not absolute. Key constraints include:

• CPU architecture — an image built for amd64 will not run natively on arm64 without multi-platform build support (docker buildx).
• Kernel dependencies — containers share the host kernel. Workloads that require a specific kernel version or kernel module may not be fully portable.
• Persistent data — data written inside the CoW container layer is ephemeral. Production applications must use Docker volumes or bind mounts for data that must survive container restarts.
• Windows vs. Linux containers — Windows and Linux containers require matching host operating systems; they are not interchangeable.

Summary

Docker’s portability stems from a well-designed combination of immutable, content-addressed image layers and a copy-on-write strategy implemented by the host’s storage driver. Together, these mechanisms allow teams to build an application image once and deploy it reliably across development, staging, and production environments — on-premises or in any public cloud — with minimal overhead and maximum consistency.