12.1: Threat Models In Cloud Computing

In traditional on-premises IT, one organization controls the entire technology stack, but cloud computing introduces a shared responsibility model between the cloud provider and the customer. The cloud provider manages the security of the cloud (physical datacenters, network infrastructure, hypervisors, etc.), while the customer is responsible for security in the cloud (their operating systems, applications, data, and user access). This division of responsibilities means that project managers must clearly understand which security tasks are handled by the provider and which must be handled by their own team. Figure 12.1 illustrates the AWS shared responsibility model, showing that AWS secures the underlying cloud infrastructure (e.g. hardware, regions, edge locations), whereas the customer must secure everything they deploy in the cloud (data, applications, identity management, encryption, etc.) [1].

Beyond shared responsibility, a robust threat model is needed to anticipate and mitigate risks in cloud environments. Common threat actors and vectors include external attackers, malicious insiders, and even other tenants in multi-tenant cloud platforms. External threats encompass familiar attacks such as distributed denial of service (DDoS) events, which attempt to overwhelm cloud applications with traffic, or exploits targeting vulnerabilities in internet-facing systems. Cloud providers offer DDoS mitigation services and web application firewalls to help counter these, but customers must architect their solutions to leverage those protections (e.g. using content delivery networks and autoscaling to absorb traffic spikes). Insider threats are also a concern – this could mean a rogue employee at the cloud customer or even at the cloud provider. For example, a disgruntled former administrator with leftover access could manipulate or steal data. Managing insider risk requires strict IAM controls (discussed in the next section) and monitoring of privileged activities. There is also the theoretical threat of a malicious cloud provider itself: since the provider has access to underlying hardware and manages virtualization, a dishonest provider could violate customer confidentiality or integrity. While major reputable providers have strong incentives and audits to prevent such behavior, customers handling very sensitive data sometimes mitigate this risk by using client-side encryption (so the provider never sees plaintext data) or by choosing providers with specific security certifications.

Cloud platforms introduce unique considerations like multi-tenancy risks. Cloud resources like virtual machines (VMs) often run on shared physical hosts with other customers’ VMs. Although hypervisors provide isolation, researchers have demonstrated side-channel attacks (e.g., CPU cache timing attacks) that could potentially leak information across co-resident VMs. An attacker might use techniques termed cloud cartography – mapping out the cloud’s infrastructure – to deliberately place their VM on the same host as a target (by trial-and-error or exploiting knowledge of the placement algorithms). Once co-resident, they could attempt cross-VM attacks like measuring cache usage or inferring keystrokes of the victim VM. These attack scenarios are complex and not commonly seen in the wild, but they underscore the need for cloud providers to continuously harden isolation mechanisms and for sensitive workloads to consider dedicated tenancy if warranted. As a project manager, you should be aware of such risks especially if managing projects in regulated sectors – for instance, some regulations might require physical separation of certain workloads.

Data exposure and misconfiguration are among the most prevalent cloud threats. A classic example is when a cloud storage bucket or database is left unintentionally open to the public internet. Attackers regularly scan for misconfigured storage and, if they find sensitive data (personal information, credentials, etc.), the consequences can include data breaches, regulatory fines, and reputational damage. Many high-profile cloud breaches have boiled down to human error in configuration. Thus, threat modeling for cloud projects must account for the risk of misconfiguration. Mitigations include using automated configuration analysis tools, enforcing baseline configurations via Infrastructure as Code templates, and applying the principle of least privilege to ensure even if a resource is exposed, attackers cannot move laterally easily.

Case Illustration: A large analytics firm suffered a breach when an AWS S3 bucket containing customer data was inadvertently set to public. Malicious actors discovered the bucket and downloaded sensitive personal information. The breach not only caused the firm to notify thousands of customers, but it also triggered an investigation under GDPR (since EU customer data was involved) and led to a fine for failing to protect personal data. In analyzing the incident, it was found that shared responsibility was misunderstood – the project team assumed the cloud provider’s defaults would keep data private, but in reality the customer was responsible for configuring access policies. This case highlights how an external attacker can exploit a simple cloud misconfiguration, and it underscores the importance of clear division of responsibility and thorough security reviews in any cloud project.

In summary, cloud threat models must consider external attacks (like DDoS, malware, and exploitation of application vulnerabilities), insider threats (misuse of credentials or systems by authorized users), and multi-tenant or cloud-specific vectors (side channels, co-location risks). A foundational practice is to follow the Zero Trust mindset: do not automatically trust any network or user, even if internal, and always verify and enforce least privilege. By anticipating how each type of threat could materialize in the cloud – whether through a malicious login, an open port, or a sophisticated cross-VM exploit – project managers can prioritize security measures and ensure compliance requirements (such as risk assessments) are met at each stage of cloud adoption.

---