Capital One Lost 100 Million Records — The Cloud Wasn't the Problem

In 2019, a former AWS employee exploited a misconfigured web application firewall and exfiltrated over 100 million Capital One customer records. The cloud infrastructure worked exactly as designed. The humans configuring it didn't. That breach cost Capital One an $80 million OCC fine and a class-action settlement north of $190 million.

Security in cloud computing doesn't fail because AWS, Azure, or Google Cloud have weak defenses. It fails because organizations treat cloud migration like a lift-and-shift exercise and forget that the shared responsibility model means they own configuration, access control, and data protection. I've watched this pattern repeat for over a decade.

If you're searching for clarity on what actually causes cloud security failures — and how to stop them — you're in the right place. This isn't a vendor pitch. It's a field report.

The Shared Responsibility Model Most Teams Misunderstand

Every major cloud provider publishes a shared responsibility model. AWS, Azure, and GCP all say the same thing: they secure the infrastructure, and you secure everything you put on it. Your data, your identities, your configurations, your encryption keys.

In my experience, about half the organizations I've worked with couldn't accurately describe what they own in this model. Their security teams assumed the cloud provider handled identity management, logging, or even endpoint protection. That assumption is where the real risk lives.

According to Gartner's research, through 2025, 99% of cloud security failures were predicted to be the customer's fault. We're now in 2026, and every major cloud breach I've tracked has confirmed that prediction.

What You Own vs. What They Own

  • Cloud provider owns: Physical data centers, hypervisors, network infrastructure, global backbone.
  • You own: IAM policies, data encryption, network configurations, application-level security, user access management, logging and monitoring.

If your team hasn't mapped every asset to one side of this divide, you have a gap. And threat actors are scanning for exactly those gaps right now.

Misconfiguration: The #1 Cloud Killer

The Verizon 2024 Data Breach Investigations Report found that misconfiguration and related errors accounted for a significant portion of breaches involving cloud assets. Publicly exposed storage buckets, overly permissive IAM roles, and disabled logging — these aren't sophisticated attacks. They're unlocked doors.

I've personally audited cloud environments where S3 buckets containing customer PII were publicly readable for months. No exploit needed. No zero-day. Just a checkbox that defaulted to "public" and nobody caught it.

Here are the misconfigurations I see most often:

  • Overly permissive IAM roles: Granting admin-level access to service accounts that only need read permissions.
  • Unrestricted security groups: Allowing inbound traffic from 0.0.0.0/0 on management ports like SSH (22) and RDP (3389).
  • Disabled logging: Turning off CloudTrail, Azure Monitor, or GCP Audit Logs to save costs — then having zero forensic capability when something goes wrong.
  • Unencrypted storage: Storing sensitive data at rest without server-side encryption enabled.
  • Default credentials: Deploying databases or admin consoles with factory-default usernames and passwords.

Tools like CIS Benchmarks provide configuration baselines for every major cloud provider. If your team isn't running automated compliance checks against these benchmarks weekly, you're guessing at your security posture.

Credential Theft Is the Front Door to Your Cloud

Here's what actually happens in most cloud breaches: a threat actor doesn't hack the infrastructure. They steal someone's credentials. A phishing email, a credential stuffing attack against a reused password, or an API key accidentally committed to a public GitHub repo. That's the entry point.

The 2024 Verizon DBIR confirmed that stolen credentials remain the single most common initial access vector. In cloud environments, one compromised identity with excessive privileges can expose your entire tenant.

Multi-Factor Authentication Isn't Optional

If you're running cloud workloads without multi-factor authentication on every human identity — especially administrative accounts — you're one phishing email away from a full breach. I say this bluntly because I've seen it happen to organizations that considered themselves mature.

MFA won't stop every attack. Adversary-in-the-middle phishing kits can intercept tokens in real time. But MFA eliminates the vast majority of credential theft scenarios and buys your team time to detect and respond.

Training your workforce to recognize social engineering and phishing attempts is equally critical. Our phishing awareness training for organizations simulates real-world attacks so your employees learn to spot credential theft attempts before they surrender their logins.

What Is Security in Cloud Computing?

Security in cloud computing is the set of policies, technologies, controls, and practices that protect cloud-based systems, data, and infrastructure from unauthorized access, data breaches, and service disruptions. It covers identity and access management, data encryption, network security, configuration management, compliance monitoring, and incident response — all within the shared responsibility framework between your organization and the cloud service provider.

Zero Trust: The Architecture Cloud Security Demands

Traditional network perimeters don't exist in the cloud. Your applications run across regions, your employees connect from everywhere, and your data flows through APIs you might not even inventory. The old model of "trust everything inside the firewall" collapses instantly.

Zero trust architecture operates on a simple principle: never trust, always verify. Every request — whether it comes from inside your network or outside — must be authenticated, authorized, and encrypted before access is granted.

In practice, zero trust for cloud environments means:

  • Least-privilege access: Every identity gets the minimum permissions needed, reviewed regularly.
  • Microsegmentation: Workloads are isolated so a breach in one service doesn't cascade to others.
  • Continuous verification: Sessions are re-evaluated based on context — device posture, location, behavior patterns.
  • Encrypted everything: Data in transit and at rest, no exceptions.

NIST published SP 800-207 as the definitive zero trust reference architecture. If your security team hasn't read it, that's your homework for this week.

Ransomware Doesn't Skip the Cloud

There's a dangerous myth that ransomware is an on-premises problem. It's not. Threat actors have evolved to target cloud-hosted file shares, cloud-based backups, and SaaS platforms. If your backup strategy is "we replicate to the cloud," and those replicas are accessible with the same credentials as your production environment, ransomware will encrypt both.

I've investigated cases where organizations had excellent on-premises backup hygiene but stored their cloud backups in the same account with the same IAM roles. When the ransomware hit, it followed the permissions chain and encrypted everything.

Isolate your backups. Use separate accounts, separate credentials, and immutable storage options like AWS S3 Object Lock or Azure Immutable Blob Storage.

Your People Are the Control Plane

Every technical control I've mentioned — IAM policies, zero trust, MFA, encrypted storage — depends on people implementing and maintaining it correctly. Security awareness isn't a nice-to-have. It's the foundation that determines whether your technical controls actually hold.

Your cloud administrators need to understand the shared responsibility model cold. Your developers need to know that hardcoded API keys in source code are a breach waiting to happen. Your end users need to recognize phishing simulations before they encounter the real thing.

Our cybersecurity awareness training covers exactly these scenarios — from social engineering tactics to cloud-specific threats — with content built for how people actually learn, not how compliance checkboxes get filled.

The Five-Point Cloud Security Checklist You Can Use Today

If you take nothing else from this post, implement these five controls this quarter:

  • 1. Enable MFA on every account. Start with admin and root accounts. No exceptions.
  • 2. Run CIS Benchmark scans weekly. Automate them. Review every finding rated High or Critical.
  • 3. Enforce least-privilege IAM. Audit permissions quarterly. Remove any access that hasn't been used in 90 days.
  • 4. Enable and centralize logging. CloudTrail, Azure Activity Logs, GCP Audit Logs — all feeding a SIEM or centralized log store with retention policies.
  • 5. Train your people. Phishing simulations, security awareness modules, cloud-specific threat briefings. Do it quarterly at minimum.

The Cloud Is Secure — Your Configuration Might Not Be

Security in cloud computing is a solvable problem. The major providers have invested billions in infrastructure security. The failures happen in the space between their controls and yours — the configurations, the identities, the human decisions.

Close that gap with technical controls, zero trust principles, and a security-aware workforce. The breach that doesn't happen is the one nobody writes about. Make sure yours is one of those.