Cloud has transformed how we build, ship, and secure technology. But one truth hasn’t changed: security is shared. Providers secure the infrastructure; customers must configure and operate it securely. When that partnership falters—through misconfigurations, weak identity controls, or unclear accountability—breaches follow. The National Security Agency (NSA) summarizes this clearly in its March 2024 guidance: “CSPs (Cloud Service Providers) provide automated, API‑driven platforms that ‘do what they’re told’ by customers.”
What “Shared Responsibility” Really Means
CSPs secure physical data centers, hypervisors, and core networking. You harden OS images, patch workloads, configure network security policies, and protect data.
• PaaS (Platform as a Service)
CSPs operate the application. You configure tenant settings, control identities, enforce MFA, and safeguard the data you upload. Responsibilities vary widely across SaaS features—read the docs and your SLA.
• SaaS (Software as a Service)
CSPs secure physical data centers, hypervisors, and core networking. You harden OS images, patch workloads, configure network security policies, and protect data.
• IaaS (Infrastructure as a Service)
Where Shared Responsibility Failed: 3 Real-World Examples
An attacker exploited a server-side request forgery (SSRF) in a misconfigured web application firewall to access the EC2 metadata service and obtain temporary credentials, which then enabled S3 data exfiltration. Overly broad IAM permissions and gaps in anomaly detection amplified the impact.
Shared‑responsibility lapse: Application and IAM hardening (customer side) and continuous monitoring of unusual S3 access (customer side).
- Block instance metadata from untrusted paths; enforce IMDSv2 and egress filtering.
- Least‑privilege IAM roles; deny‑by‑default S3 bucket policies; GuardDuty alerts for anomalous access.
- WAF rules specifically preventing SSRF; runtime egress controls at the workload tier.
1) Capital One (2019): Misconfigured WAF + Over‑permissive IAM
Controls to implement
UpGuard found 38 million records exposed because multiple Power Apps Portals were configured to allow anonymous access to OData list feeds without table permissions. Affected organizations ranged from state agencies to major brands.
Shared‑responsibility lapse: SaaS configuration hygiene—tenant admins didn’t restrict data feeds; platform defaults were permissive and poorly understood.
2) Microsoft Power Apps Portals (2021): Anonymous OData Feeds
- Treat low‑code SaaS like any other production app: security reviews, Table Permissions on Dataverse, and routine configuration audits.
- Apply phishing‑resistant MFA and role‑based access for portal administrators; centralize change control.
- Continuous discovery of public endpoints and anonymous data exposure.
Controls to implement
An unprotected Kubernetes admin console exposed credentials to Tesla’s AWS environment, enabling attackers to run cryptomining workloads and access non‑public data (telemetry). The miners hid activity behind Cloudflare and non‑standard ports to evade detection.
Shared‑responsibility lapse: Workload/cluster admin surfaces left open; insufficient detection of abnormal compute usage; secrets accessible from pods.
3) Tesla (2018): Unsecured Kubernetes Console → Crypto‑Mining + Data Exposure
- Lock down Kubernetes: RBAC, network policies, private admin endpoints, and audit logging; enforce MFA on admin access.
- Isolate compute and set budget/usage alerts; container runtime controls and image signing.
- Mount secrets via short‑lived tokens; disable long‑lived static credentials.
Controls to implement
NSA’s guidance includes concrete best practices: incident playbooks, secure IAM, key management, DevSecOps, logging for threat hunting, and more. It’s the right foundation for your program.
Download our free guide to get the full content....
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse convallis tellus ut venenatis interdum. Integer ut elit sollicitudin, aliquam orci ac, malesuada.