This week connects to earlier foundations you can reuse in cloud contexts:

Opening Framing

The cloud has transformed how organizations build and deploy technology, but it hasn't eliminated security—it's changed who's responsible for what. When your servers lived in your data center, you controlled everything from the physical locks to the firewall rules. In the cloud, security becomes a partnership between you and your cloud provider, with the division of responsibilities varying dramatically based on what services you use.

Understanding cloud security starts with understanding cloud computing itself: the service models (IaaS, PaaS, SaaS), deployment models (public, private, hybrid), and most critically, the shared responsibility model that defines who secures what. Get this foundation wrong, and you'll either duplicate efforts the cloud provider already handles or—far worse—leave critical gaps assuming someone else has them covered.

This week establishes the foundation for everything that follows: cloud computing concepts, the major cloud providers, shared responsibility models, cloud-native security advantages, and the threat landscape unique to cloud environments.

Key insight: Cloud security isn't harder or easier than traditional security—it's different. Success requires understanding those differences deeply.

1) Cloud Computing Fundamentals

Cloud computing delivers computing resources over the internet, enabling on-demand access without direct management of physical infrastructure:

NIST Definition of Cloud Computing:

"Cloud computing is a model for enabling ubiquitous,
convenient, on-demand network access to a shared pool
of configurable computing resources that can be rapidly
provisioned and released with minimal management effort
or service provider interaction."

Five Essential Characteristics:
┌─────────────────────────────────────────────────────────────┐
│ 1. ON-DEMAND SELF-SERVICE                                   │
│    Provision resources automatically without human          │
│    interaction with provider                                │
│                                                             │
│ 2. BROAD NETWORK ACCESS                                     │
│    Available over network, accessed through standard        │
│    mechanisms (browsers, APIs, mobile)                      │
│                                                             │
│ 3. RESOURCE POOLING                                         │
│    Provider resources pooled to serve multiple consumers    │
│    using multi-tenant model                                 │
│                                                             │
│ 4. RAPID ELASTICITY                                         │
│    Capabilities can be elastically provisioned and          │
│    released, scaling with demand                            │
│                                                             │
│ 5. MEASURED SERVICE                                         │
│    Resource usage monitored, controlled, reported—          │
│    pay for what you use                                     │
└─────────────────────────────────────────────────────────────┘

Service Models:

Cloud Service Models:

┌─────────────────────────────────────────────────────────────┐
│                    SOFTWARE AS A SERVICE (SaaS)             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │  Applications    │ Gmail, Salesforce, Microsoft 365   │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │  You manage: Data, user access, configuration         │  │
│  │  Provider manages: Everything else                    │  │
│  └───────────────────────────────────────────────────────┘  │
├─────────────────────────────────────────────────────────────┤
│                   PLATFORM AS A SERVICE (PaaS)              │
│  ┌───────────────────────────────────────────────────────┐  │
│  │  Platforms       │ Heroku, App Engine, Azure App Svc  │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │  You manage: Applications, data                       │  │
│  │  Provider manages: Runtime, middleware, OS, infra     │  │
│  └───────────────────────────────────────────────────────┘  │
├─────────────────────────────────────────────────────────────┤
│               INFRASTRUCTURE AS A SERVICE (IaaS)            │
│  ┌───────────────────────────────────────────────────────┐  │
│  │  Infrastructure  │ EC2, Azure VMs, Google Compute     │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │  You manage: Applications, data, runtime, middleware, │  │
│  │               OS, security configuration              │  │
│  │  Provider manages: Virtualization, servers, storage,  │  │
│  │                    networking, physical security      │  │
│  └───────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

Security Responsibility Increases:
SaaS (least) ──────────────────────► IaaS (most)

Deployment Models:

Cloud Deployment Models:

PUBLIC CLOUD:
┌─────────────────────────────────────────────────────────────┐
│ Infrastructure owned and operated by cloud provider         │
│ Shared among multiple organizations (multi-tenant)          │
│                                                             │
│ Examples: AWS, Azure, GCP                                   │
│                                                             │
│ Security Considerations:                                    │
│ + Provider handles physical security                        │
│ + Compliance certifications available                       │
│ - Shared infrastructure (noisy neighbor risks)              │
│ - Data location may be uncertain                            │
│ - Dependent on provider security                            │
└─────────────────────────────────────────────────────────────┘

PRIVATE CLOUD:
┌─────────────────────────────────────────────────────────────┐
│ Infrastructure dedicated to single organization             │
│ May be on-premises or hosted                                │
│                                                             │
│ Examples: VMware vSphere, OpenStack, Azure Stack            │
│                                                             │
│ Security Considerations:                                    │
│ + Full control over infrastructure                          │
│ + Data sovereignty guaranteed                               │
│ + Custom security controls                                  │
│ - Higher cost and complexity                                │
│ - You're responsible for everything                         │
└─────────────────────────────────────────────────────────────┘

HYBRID CLOUD:
┌─────────────────────────────────────────────────────────────┐
│ Combination of public and private clouds                    │
│ Data and applications can move between environments         │
│                                                             │
│ Examples: On-prem + AWS, Azure Arc, Google Anthos           │
│                                                             │
│ Security Considerations:                                    │
│ + Flexibility for sensitive workloads                       │
│ + Burst to public cloud for capacity                        │
│ - Complexity in security policies                           │
│ - Data transfer security critical                           │
│ - Identity federation challenges                            │
└─────────────────────────────────────────────────────────────┘

MULTI-CLOUD:
┌─────────────────────────────────────────────────────────────┐
│ Using multiple public cloud providers                       │
│ May be intentional or organic growth                        │
│                                                             │
│ Examples: AWS + Azure, GCP + AWS                            │
│                                                             │
│ Security Considerations:                                    │
│ + Avoid vendor lock-in                                      │
│ + Best-of-breed services                                    │
│ - Multiple security models to manage                        │
│ - Inconsistent controls across providers                    │
│ - Complexity in visibility and governance                   │
└─────────────────────────────────────────────────────────────┘

Key insight: The service and deployment model you choose fundamentally shapes your security responsibilities and options.

2) Major Cloud Providers

The three major cloud providers dominate the market, each with distinct security capabilities and approaches:

Major Cloud Providers Overview:

AMAZON WEB SERVICES (AWS):
┌─────────────────────────────────────────────────────────────┐
│ Market Position: Largest market share (~32%)                │
│ Launched: 2006                                              │
│                                                             │
│ Key Security Services:                                      │
│ - IAM (Identity and Access Management)                      │
│ - VPC (Virtual Private Cloud)                               │
│ - GuardDuty (Threat detection)                              │
│ - Security Hub (Central security view)                      │
│ - CloudTrail (API logging)                                  │
│ - KMS (Key Management Service)                              │
│ - WAF (Web Application Firewall)                            │
│ - Macie (Data discovery and protection)                     │
│                                                             │
│ Strengths:                                                  │
│ + Most mature, broadest service catalog                     │
│ + Extensive compliance certifications                       │
│ + Large partner ecosystem                                   │
│                                                             │
│ Considerations:                                             │
│ - Complex pricing                                           │
│ - IAM can be challenging to master                          │
└─────────────────────────────────────────────────────────────┘

MICROSOFT AZURE:
┌─────────────────────────────────────────────────────────────┐
│ Market Position: Second largest (~22%)                      │
│ Launched: 2010                                              │
│                                                             │
│ Key Security Services:                                      │
│ - Azure AD (Identity platform)                              │
│ - Virtual Network (Networking)                              │
│ - Microsoft Defender for Cloud                              │
│ - Azure Sentinel (SIEM)                                     │
│ - Key Vault (Secrets management)                            │
│ - Azure Firewall                                            │
│ - Azure Policy (Governance)                                 │
│ - Microsoft Purview (Data governance)                       │
│                                                             │
│ Strengths:                                                  │
│ + Deep Microsoft 365/Enterprise integration                 │
│ + Strong hybrid cloud capabilities                          │
│ + Azure AD for identity                                     │
│                                                             │
│ Considerations:                                             │
│ - Rapid service changes                                     │
│ - Naming/branding frequently changes                        │
└─────────────────────────────────────────────────────────────┘

GOOGLE CLOUD PLATFORM (GCP):
┌─────────────────────────────────────────────────────────────┐
│ Market Position: Third largest (~10%)                       │
│ Launched: 2008                                              │
│                                                             │
│ Key Security Services:                                      │
│ - Cloud IAM                                                 │
│ - VPC (Virtual Private Cloud)                               │
│ - Security Command Center                                   │
│ - Chronicle (Security analytics)                            │
│ - Cloud KMS                                                 │
│ - Cloud Armor (WAF/DDoS)                                    │
│ - BeyondCorp Enterprise (Zero trust)                        │
│ - Binary Authorization                                      │
│                                                             │
│ Strengths:                                                  │
│ + Strong in containers/Kubernetes (GKE)                     │
│ + Advanced analytics and ML capabilities                    │
│ + BeyondCorp zero-trust model                               │
│                                                             │
│ Considerations:                                             │
│ - Smaller enterprise market share                           │
│ - Fewer compliance certifications historically              │
└─────────────────────────────────────────────────────────────┘

Service Comparison:

Security Service Comparison:

┌──────────────────┬─────────────┬─────────────┬─────────────┐
│ Capability       │ AWS         │ Azure       │ GCP         │
├──────────────────┼─────────────┼─────────────┼─────────────┤
│ Identity         │ IAM         │ Azure AD    │ Cloud IAM   │
│ Network Security │ VPC, SG     │ VNet, NSG   │ VPC, FW     │
│ Key Management   │ KMS         │ Key Vault   │ Cloud KMS   │
│ Threat Detection │ GuardDuty   │ Defender    │ SCC         │
│ SIEM             │ Security Hub│ Sentinel    │ Chronicle   │
│ API Logging      │ CloudTrail  │ Activity Log│ Audit Logs  │
│ WAF              │ AWS WAF     │ Azure WAF   │ Cloud Armor │
│ DDoS Protection  │ Shield      │ DDoS Protect│ Cloud Armor │
│ Secrets          │ Secrets Mgr │ Key Vault   │ Secret Mgr  │
│ Container Sec    │ ECR Scan    │ ACR Scan    │ Artifact Reg│
│ Compliance       │ Artifact    │ Compliance  │ Assured     │
│                  │             │ Manager     │ Workloads   │
└──────────────────┴─────────────┴─────────────┴─────────────┘

Choosing a Provider:
- Existing technology stack (Microsoft shop → Azure)
- Specific service requirements
- Geographic availability
- Compliance requirements
- Team expertise
- Pricing considerations

Key insight: Each provider has strengths. Many organizations use multiple clouds, requiring security teams to understand all of them.

3) The Shared Responsibility Model

The shared responsibility model is the foundational concept of cloud security—understanding who secures what:

Shared Responsibility Model:

THE FUNDAMENTAL PRINCIPLE:
┌─────────────────────────────────────────────────────────────┐
│ Cloud Provider: Security OF the cloud                       │
│ Customer: Security IN the cloud                             │
└─────────────────────────────────────────────────────────────┘

RESPONSIBILITY BY SERVICE MODEL:

                        IaaS        PaaS        SaaS
┌───────────────────────────────────────────────────────────┐
│ Data                  YOU         YOU         YOU        │
│ Applications          YOU         YOU         Provider   │
│ Runtime               YOU         Provider    Provider   │
│ Middleware            YOU         Provider    Provider   │
│ Operating System      YOU         Provider    Provider   │
│ Virtualization        Provider    Provider    Provider   │
│ Servers               Provider    Provider    Provider   │
│ Storage               Provider    Provider    Provider   │
│ Networking            Provider    Provider    Provider   │
│ Physical Security     Provider    Provider    Provider   │
└───────────────────────────────────────────────────────────┘

Legend: YOU = Customer responsibility
        Provider = Cloud provider responsibility

AWS Shared Responsibility:

AWS Shared Responsibility Model:

CUSTOMER RESPONSIBILITY (Security IN the Cloud):
┌─────────────────────────────────────────────────────────────┐
│ Customer Data                                               │
│ ├── Encryption (client-side, server-side)                   │
│ ├── Data integrity                                          │
│ └── Data classification                                     │
│                                                             │
│ Platform, Applications, Identity & Access Management        │
│ ├── IAM policies and roles                                  │
│ ├── MFA configuration                                       │
│ ├── Password policies                                       │
│ └── Application security                                    │
│                                                             │
│ Operating System, Network & Firewall Configuration          │
│ ├── OS patching (on EC2)                                    │
│ ├── Security groups                                         │
│ ├── Network ACLs                                            │
│ └── VPC configuration                                       │
│                                                             │
│ Client-side & Server-side Encryption                        │
│ └── Network traffic protection                              │
└─────────────────────────────────────────────────────────────┘

AWS RESPONSIBILITY (Security OF the Cloud):
┌─────────────────────────────────────────────────────────────┐
│ Compute, Storage, Database, Networking                      │
│ ├── Hardware maintenance                                    │
│ ├── Software (hypervisor, managed services)                 │
│ └── Infrastructure patching                                 │
│                                                             │
│ Hardware/AWS Global Infrastructure                          │
│ ├── Regions, Availability Zones, Edge Locations             │
│ ├── Physical security of data centers                       │
│ └── Environmental controls                                  │
│                                                             │
│ Managed Services                                            │
│ ├── RDS: OS and database patching                           │
│ ├── Lambda: Runtime security                                │
│ └── S3: Storage infrastructure                              │
└─────────────────────────────────────────────────────────────┘

Responsibility Shifts by Service:

How Responsibility Shifts:

EC2 (IaaS) - Most Customer Responsibility:
┌─────────────────────────────────────────────────────────────┐
│ YOU Manage:                                                 │
│ ✓ OS installation and patching                              │
│ ✓ Application installation and security                     │
│ ✓ Security groups (instance firewall)                       │
│ ✓ IAM for instance access                                   │
│ ✓ Data encryption                                           │
│ ✓ Logging and monitoring                                    │
│ ✓ Antivirus/endpoint protection                             │
│                                                             │
│ AWS Manages:                                                │
│ ✓ Physical servers                                          │
│ ✓ Hypervisor                                                │
│ ✓ Network infrastructure                                    │
└─────────────────────────────────────────────────────────────┘

RDS (Managed Database - PaaS):
┌─────────────────────────────────────────────────────────────┐
│ YOU Manage:                                                 │
│ ✓ Database users and permissions                            │
│ ✓ Security groups                                           │
│ ✓ Encryption configuration                                  │
│ ✓ Database-level access controls                            │
│ ✓ Data in the database                                      │
│                                                             │
│ AWS Manages:                                                │
│ ✓ OS patching                                               │
│ ✓ Database software patching                                │
│ ✓ Backups (automated)                                       │
│ ✓ High availability infrastructure                          │
└─────────────────────────────────────────────────────────────┘

Lambda (Serverless - FaaS):
┌─────────────────────────────────────────────────────────────┐
│ YOU Manage:                                                 │
│ ✓ Function code security                                    │
│ ✓ IAM execution role permissions                            │
│ ✓ Environment variable secrets                              │
│ ✓ VPC configuration (if used)                               │
│ ✓ Input validation                                          │
│                                                             │
│ AWS Manages:                                                │
│ ✓ Runtime environment                                       │
│ ✓ Execution environment isolation                           │
│ ✓ OS and runtime patching                                   │
│ ✓ Scaling infrastructure                                    │
│ ✓ Physical security                                         │
└─────────────────────────────────────────────────────────────┘

S3 (Storage):
┌─────────────────────────────────────────────────────────────┐
│ YOU Manage:                                                 │
│ ✓ Bucket policies and ACLs                                  │
│ ✓ Public access settings                                    │
│ ✓ Encryption configuration                                  │
│ ✓ Object-level permissions                                  │
│ ✓ Access logging enablement                                 │
│ ✓ Lifecycle policies                                        │
│                                                             │
│ AWS Manages:                                                │
│ ✓ Storage infrastructure                                    │
│ ✓ Durability and availability                               │
│ ✓ Data center security                                      │
└─────────────────────────────────────────────────────────────┘

Key insight: The most common cloud security failures occur in areas customers are responsible for but assume the provider handles.

4) Cloud-Native Security Advantages

Cloud environments offer unique security capabilities not available in traditional data centers:

Cloud Security Advantages:

API-DRIVEN EVERYTHING:
┌─────────────────────────────────────────────────────────────┐
│ Benefit: Every action through APIs = complete audit trail   │
│                                                             │
│ Traditional: Someone walks into data center, unknown        │
│ Cloud: Every API call logged with who, what, when, where    │
│                                                             │
│ Security Value:                                             │
│ - Complete visibility into all changes                      │
│ - Automated compliance checking                             │
│ - Infrastructure as code possible                           │
│ - Programmatic security controls                            │
│                                                             │
│ Example (AWS CloudTrail):                                   │
│ {                                                           │
│   "eventTime": "2024-03-15T10:30:00Z",                      │
│   "userIdentity": {...},                                    │
│   "eventSource": "s3.amazonaws.com",                        │
│   "eventName": "PutBucketPolicy",                           │
│   "sourceIPAddress": "192.168.1.100",                       │
│   "requestParameters": {...}                                │
│ }                                                           │
└─────────────────────────────────────────────────────────────┘

IMMUTABLE INFRASTRUCTURE:
┌─────────────────────────────────────────────────────────────┐
│ Concept: Replace instead of repair                          │
│                                                             │
│ Traditional: Patch running servers, configuration drift     │
│ Cloud: Deploy new instances from known-good images          │
│                                                             │
│ Security Value:                                             │
│ - No configuration drift                                    │
│ - Known-good state always                                   │
│ - Compromised systems replaced, not cleaned                 │
│ - Reduces attacker persistence                              │
│                                                             │
│ Pattern:                                                    │
│ 1. Build hardened golden AMI/image                          │
│ 2. Deploy instances from image                              │
│ 3. Never modify running instances                           │
│ 4. Updates = new image + replace instances                  │
└─────────────────────────────────────────────────────────────┘

MICRO-SEGMENTATION:
┌─────────────────────────────────────────────────────────────┐
│ Concept: Granular network controls at workload level        │
│                                                             │
│ Traditional: Perimeter firewall, flat internal network      │
│ Cloud: Security groups per instance, VPC isolation          │
│                                                             │
│ Security Value:                                             │
│ - Limit blast radius of compromise                          │
│ - Enforce least privilege networking                        │
│ - Zero trust architecture enabled                           │
│                                                             │
│ Example:                                                    │
│ Web Tier SG → Only port 443 from load balancer              │
│ App Tier SG → Only port 8080 from web tier                  │
│ DB Tier SG → Only port 5432 from app tier                   │
└─────────────────────────────────────────────────────────────┘

ELASTICITY FOR SECURITY:
┌─────────────────────────────────────────────────────────────┐
│ Concept: Scale security with workload                       │
│                                                             │
│ Traditional: Fixed security infrastructure capacity         │
│ Cloud: Scale WAF, DDoS protection, logging dynamically      │
│                                                             │
│ Security Value:                                             │
│ - Handle attack traffic without degradation                 │
│ - No capacity planning for security services                │
│ - Cost scales with actual usage                             │
│                                                             │
│ Example: AWS Shield Advanced                                │
│ - Absorbs DDoS attacks at AWS edge                          │
│ - Scales automatically with attack size                     │
│ - No customer infrastructure to protect                     │
└─────────────────────────────────────────────────────────────┘

NATIVE ENCRYPTION:
┌─────────────────────────────────────────────────────────────┐
│ Concept: Encryption built into services                     │
│                                                             │
│ Traditional: Buy/deploy/manage encryption separately        │
│ Cloud: Enable encryption with a checkbox/API call           │
│                                                             │
│ Security Value:                                             │
│ - Encryption at rest default or easy                        │
│ - Managed key rotation                                      │
│ - HSM-backed keys available                                 │
│ - Encryption in transit standard                            │
│                                                             │
│ Example: S3 Default Encryption                              │
│ aws s3api put-bucket-encryption \                           │
│   --bucket my-bucket \                                      │
│   --server-side-encryption-configuration ...                │
└─────────────────────────────────────────────────────────────┘

Security Services Integration:

Cloud-Native Security Stack (AWS Example):

┌─────────────────────────────────────────────────────────────┐
│                    SECURITY HUB                             │
│            (Centralized security findings)                  │
└─────────────────────────────────────────────────────────────┘
        ▲           ▲           ▲           ▲
        │           │           │           │
┌───────┴───┐ ┌─────┴─────┐ ┌───┴───┐ ┌─────┴─────┐
│ GuardDuty │ │  Config   │ │ Macie │ │ Inspector │
│ (Threats) │ │(Compliance)│ │(Data) │ │  (Vulns)  │
└───────────┘ └───────────┘ └───────┘ └───────────┘
        ▲           ▲           ▲           ▲
        │           │           │           │
┌───────┴───────────┴───────────┴───────────┴───────┐
│                   CloudTrail                       │
│              (API Activity Logging)                │
└───────────────────────────────────────────────────┘
        ▲
        │
┌───────┴───────────────────────────────────────────┐
│               Your AWS Resources                   │
│    (EC2, S3, RDS, Lambda, VPC, IAM, etc.)         │
└───────────────────────────────────────────────────┘

Benefits of Native Integration:
- Single pane of glass for security
- Automated findings aggregation
- Cross-service correlation
- Compliance automation
- No third-party integration required

Key insight: Cloud-native security services can provide better visibility and control than traditional tools—if you use them.

5) Cloud Threat Landscape

Cloud environments face both traditional threats and cloud-specific attack patterns:

Cloud-Specific Threats:

MISCONFIGURATION:
┌─────────────────────────────────────────────────────────────┐
│ #1 cause of cloud security incidents                        │
│                                                             │
│ Common Misconfigurations:                                   │
│ - Public S3 buckets                                         │
│ - Overly permissive security groups (0.0.0.0/0)             │
│ - Excessive IAM permissions                                 │
│ - Unencrypted storage                                       │
│ - Public snapshots/AMIs                                     │
│ - Missing logging                                           │
│ - Default credentials                                       │
│                                                             │
│ Why It Happens:                                             │
│ - Ease of use prioritized over security                     │
│ - Lack of cloud security expertise                          │
│ - No policy enforcement                                     │
│ - Shadow IT / ungoverned accounts                           │
│                                                             │
│ Example: Capital One Breach (2019)                          │
│ - Misconfigured WAF allowed SSRF                            │
│ - Overprivileged IAM role exploited                         │
│ - 100M+ customer records exposed                            │
└─────────────────────────────────────────────────────────────┘

IDENTITY AND ACCESS ATTACKS:
┌─────────────────────────────────────────────────────────────┐
│ Targeting the "keys to the kingdom"                         │
│                                                             │
│ Attack Vectors:                                             │
│ - Credential theft (access keys, passwords)                 │
│ - Privilege escalation via IAM                              │
│ - Service account abuse                                     │
│ - Cross-account access exploitation                         │
│ - OAuth/federation attacks                                  │
│                                                             │
│ Why Critical:                                               │
│ - Compromised identity = full environment access            │
│ - No network perimeter to protect                           │
│ - API access from anywhere                                  │
│                                                             │
│ Example: SolarWinds Attack (2020)                           │
│ - Compromised credentials used for cloud access             │
│ - Created OAuth apps for persistent access                  │
│ - Accessed email and files via Graph API                    │
└─────────────────────────────────────────────────────────────┘

DATA EXPOSURE:
┌─────────────────────────────────────────────────────────────┐
│ Cloud storage makes data exposure easy                      │
│                                                             │
│ Exposure Vectors:                                           │
│ - Public storage buckets                                    │
│ - Overshared links                                          │
│ - Snapshot/backup exposure                                  │
│ - Logging sensitive data                                    │
│ - Cross-region replication issues                           │
│                                                             │
│ Scale of Problem:                                           │
│ - Billions of files exposed in public buckets               │
│ - Automated scanners constantly probing                     │
│ - Data exposed within minutes of misconfiguration           │
│                                                             │
│ Example: Multiple S3 Bucket Exposures                       │
│ - Verizon: 14M customer records                             │
│ - US Army/NSA: Intelligence data                            │
│ - Twitch: Full source code                                  │
└─────────────────────────────────────────────────────────────┘

INSECURE APIS:
┌─────────────────────────────────────────────────────────────┐
│ APIs are the interface to everything in cloud               │
│                                                             │
│ Vulnerabilities:                                            │
│ - Missing authentication                                    │
│ - Broken authorization                                      │
│ - Injection attacks                                         │
│ - Rate limiting failures                                    │
│ - Excessive data exposure                                   │
│                                                             │
│ Cloud-Specific API Risks:                                   │
│ - Metadata service abuse (169.254.169.254)                  │
│ - SSRF to internal services                                 │
│ - Cloud API enumeration                                     │
│ - Unauthorized service access                               │
└─────────────────────────────────────────────────────────────┘

SUPPLY CHAIN RISKS:
┌─────────────────────────────────────────────────────────────┐
│ Cloud amplifies software supply chain risks                 │
│                                                             │
│ Attack Surfaces:                                            │
│ - Container images from public registries                   │
│ - Third-party libraries and dependencies                    │
│ - Marketplace AMIs/images                                   │
│ - CI/CD pipeline compromise                                 │
│ - Infrastructure as code poisoning                          │
│                                                             │
│ Example: Codecov Breach (2021)                              │
│ - Compromised CI/CD script                                  │
│ - Harvested credentials from customer builds                │
│ - Affected thousands of organizations                       │
└─────────────────────────────────────────────────────────────┘

Top Cloud Security Failures:

CSA Top Threats to Cloud Computing (2022):

1. Insufficient Identity, Credentials, Access Management
   - Weak passwords, no MFA
   - Overprivileged accounts
   - Shared credentials
   - Orphaned accounts

2. Insecure Interfaces and APIs
   - Unauthenticated APIs
   - Missing input validation
   - Verbose error messages

3. Misconfiguration and Inadequate Change Control
   - Default configurations
   - Unnecessary services enabled
   - Ungoverned changes

4. Lack of Cloud Security Architecture and Strategy
   - No cloud security framework
   - Lift-and-shift without security redesign
   - Missing security requirements

5. Insecure Software Development
   - Secrets in code
   - Vulnerable dependencies
   - Missing security testing

6. Unsecured Third-Party Resources
   - Unvetted marketplace images
   - Malicious containers
   - Compromised dependencies

7. System Vulnerabilities
   - Unpatched systems
   - Zero-day exploits
   - Legacy systems in cloud

8. Accidental Cloud Data Disclosure
   - Public storage
   - Shared links
   - Logging sensitive data

9. Serverless and Container Workload Misconfiguration
   - Overprivileged functions
   - Insecure container configs
   - Missing runtime protection

10. Organized Crime / Hackers / APT
    - Cryptomining
    - Ransomware
    - Data theft
    - Espionage

Key insight: Most cloud breaches result from misconfiguration and identity issues—both are preventable with proper controls.

Real-World Context

Case Study: Capital One Data Breach (2019)

The Capital One breach exemplifies cloud-specific attack patterns. An attacker exploited a misconfigured web application firewall (WAF) to perform Server-Side Request Forgery (SSRF), accessing the EC2 metadata service to obtain IAM role credentials. These credentials had excessive permissions, allowing access to S3 buckets containing 100+ million customer records. The breach highlighted multiple cloud security failures: WAF misconfiguration, overprivileged IAM roles, and insufficient detection of anomalous behavior. AWS's shared responsibility model meant Capital One was responsible for all these configurations—AWS's infrastructure was not compromised.

Case Study: Microsoft Power Apps Data Exposure (2021)

Security researchers discovered 38 million records exposed across 47 organizations due to Microsoft Power Apps portal misconfiguration. The default setting allowed public access to data unless explicitly disabled. Exposed data included COVID-19 vaccination records, social security numbers, and employee information. This incident demonstrates how SaaS security remains a customer responsibility: even though Microsoft provided the platform, customers were responsible for configuring access controls correctly. Microsoft subsequently changed the default to private access.

Cloud Security Mindset Shifts:

Traditional vs. Cloud Security Thinking:

PERIMETER THINKING:
Traditional: "Protect the network perimeter"
Cloud: "There is no perimeter—every resource needs its own controls"

TRUST MODEL:
Traditional: "Trust internal network"
Cloud: "Zero trust—verify every request regardless of source"

CHANGE MANAGEMENT:
Traditional: "CAB approval, scheduled maintenance windows"
Cloud: "Continuous deployment with automated security checks"

SECURITY TOOLS:
Traditional: "Deploy appliances in data center"
Cloud: "Consume security as services, API-integrated"

VISIBILITY:
Traditional: "Network TAPs and flow logs"
Cloud: "API logs, cloud-native monitoring, identity-based tracking"

INCIDENT RESPONSE:
Traditional: "Contain, eradicate, recover on same systems"
Cloud: "Isolate and replace—terminate compromised resources"

Cloud security requires unlearning some traditional security assumptions while applying fundamental security principles in new ways.

Guided Lab: Cloud Account Setup & Security Baseline

In this lab, you'll set up cloud accounts and establish security baselines for AWS, Azure, or GCP.

Lab Environment:

• AWS Free Tier account (or Azure/GCP equivalent)
• Web browser
• AWS CLI (optional)

Exercise Steps:

1. Create cloud account with strong root credentials
2. Enable MFA on root account
3. Create IAM admin user (don't use root)
4. Enable CloudTrail logging (all regions)
5. Configure account-level security settings
6. Review default VPC security groups
7. Enable AWS Config or equivalent
8. Document security baseline configuration

Reflection Questions:

• What security settings were enabled by default vs. required manual setup?
• How does the shared responsibility model apply to your account setup?
• What would an attacker need to compromise your account?

Week Outcome Check

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

• Define cloud computing and its essential characteristics
• Distinguish between IaaS, PaaS, and SaaS service models
• Compare public, private, hybrid, and multi-cloud deployments
• Identify security services across AWS, Azure, and GCP
• Apply the shared responsibility model to determine security obligations
• Explain cloud-native security advantages
• Describe cloud-specific threats and attack patterns
• Configure basic cloud account security

📚 Building on Prior Knowledge

This week connects to earlier foundations you can reuse in cloud contexts:

• CSY104 (Networking Fundamentals): VPCs, routing, and exposure map to network security basics.
• CSY201 (OS Hardening): Secure images and baseline configurations apply to cloud workloads.
• CSY202 (Applied Crypto): Encryption and key management carry into cloud KMS services.
• CSY203 (Secure Design): Shared responsibility informs secure-by-default architecture.

🎯 Hands-On Labs (Free & Essential)

Gain practical cloud security experience with free, beginner-friendly labs before moving to reading resources.

💡 Lab Strategy: Create free-tier accounts for AWS and Azure—you'll need them throughout this course. Never enter payment methods on unverified sites.

Resources

Lab

Complete the following lab exercises to practice cloud security fundamentals.