The Capital One breach: the cloud is not to blame, configuration is

At the end of July 2019, a major data breach at Capital One became public. The attacker used a misconfigured web application firewall in the bank's cloud infrastructure to obtain temporary credentials through an SSRF vulnerability. From there came access to the data of over 100 million customers in North America. Fines and settlements eventually reached hundreds of millions of dollars.

The first reaction in professional circles was predictable: "the cloud is not safe", "data cannot be trusted to public providers". I think this interpretation is wrong and harmful - it draws attention away from the real question.

What actually happened

The technical chain looked roughly like this: a misconfigured firewall allowed a request to reach an internal cloud metadata service. That service returned temporary tokens with excessive permissions. Through those tokens the attacker accessed data in storage.

None of these steps represents a specific "cloud vulnerability" in the sense of a provider's software defect. It is a sequence of configuration and access management errors:

• the firewall was misconfigured,
• the role that issued the tokens had excessive permissions,
• access rights had not been reviewed against the principle of least privilege.

The same set of errors in on-premise infrastructure would have produced the same result.

Why this matters beyond the US

The Capital One incident happened at an American bank with serious security requirements and a substantial information security budget. If this happens there, the question about configuration quality at companies with far more modest resources becomes very concrete.

In 2019, many companies are actively moving infrastructure and data to the cloud. The pace of migration often outstrips understanding of the shared responsibility model. The provider is responsible for the security of the physical infrastructure. The customer is responsible for service configuration, access management, and role permissions.

This is a fundamental distinction that is regularly missed when decisions are made.

Three layers worth examining

The first is network configuration. Who reviews firewall rules and network access policies? Is there a clear picture of which requests should be allowed and which should not? Is this done systematically or only at initial setup?

The second is roles and permissions. In the cloud model, permissions are assigned via roles attached to services and users. Excessive permissions are a classic problem: during initial setup they are configured "with headroom" and then never revisited. This is called privilege creep, and it is one of the most common reasons that a compromise of one infrastructure element expands into a large breach.

The third is anomaly monitoring. The attacker's activity in the Capital One incident looked like unusual requests to the metadata service. Anomalies like this are detectable in principle - if monitoring is configured and someone reads what it produces.

Questions worth asking

If you are moving data to the cloud, or already operating there, a few practical questions:

1. Who on your team is responsible for auditing cloud service configurations?
2. Have roles and permissions been reviewed for excess at least once since initial setup?
3. Is there monitoring for unusual access patterns to critical data?
4. Who will know, and how, if something similar happens to you?

Moving to the cloud does not make infrastructure automatically secure. It shifts the nature of security work - from physical protection to configuration and access management. That requires different competencies, and they need to be built deliberately.