Cloud Security: Where Responsibility Breaks Down

Cloud incidents often start where one party assumed another had the control. The shared responsibility model is meant to prevent that. In practice, it is where the assumption gets made.

The NSA puts it directly. Its first cloud mitigation strategy is to uphold the shared responsibility model, and it warns that security gaps arise when customers assume the provider is securing something that is the customer’s job. It also notes that the model varies from service to service, and may vary by provider.

That last point is the one most programs miss. A slide that shows a neat line between provider and customer tells you nothing about who owns a specific control on a specific service.

Three cases that show where it breaks

In the Snowflake case, Mandiant found no breach of the platform itself. In the Drift case, access came through a third-party application’s tokens. Neither shows that providers are never at fault. Both show that the controls worth fixing first sat on the customer side of the line, or at the seam with a connected vendor.

Six places the line gets lost

This list is our assessment, drawn from the cases above and from the NSA’s guidance. It is not a count of incidents.

1. The service-model line. Teams apply an infrastructure-as-a-service mindset to a managed platform, or assume a SaaS vendor handles what is really a tenant setting.

2. Defaults. The provider offers a control. Nobody owns turning it on. MFA and network allow lists were the missing controls in the Snowflake cases.

3. Identity. Who administers the tenant or root account, who approves access, who rotates credentials, and who removes them when people or contractors leave. In the Snowflake cases, Mandiant traced some infections to contractor systems also used for personal activity.

4. Integrations. Connected apps, API keys and tokens create access nobody listed as an identity. The Drift case ran through one.

5. Logs. A provider may generate the log. The customer still has to enable it, route it, keep it and read it. The NSA’s top ten includes managing cloud logs for effective threat hunting.

6. Unowned accounts. Subscriptions and tenants created by teams outside central IT often have no named security owner.

What to change

• Write the responsibility sheet per service, not per provider. For each cloud service in use, list the controls that matter, who owns each one (provider, customer security, customer engineering), and what evidence proves it. The NSA advises close attention to provider documentation, and direct engagement with the provider where the service model is unclear.

• Make the customer side enforced, not advised. Set MFA, network restrictions and credential rotation by policy at the account or tenant level. The three Snowflake factors Mandiant named are all of this kind.

• Name an owner and an end date for every account, tenant, subscription and connected app. An asset nobody owns is an asset nobody secures.

• Treat integrations as identities. Inventory the tokens, their scopes and their expiry. Know how fast you could revoke every token tied to a vendor.

• Decide who reads the logs. Enabling a log is not the same as monitoring it. Assign the detection work in writing.

• Separate two kinds of evidence. A provider’s assurance reports speak to the provider’s side. Your own configuration data speaks to yours. Neither covers the other.

What this evidence does not show

Public cases over-represent incidents that were investigated and disclosed. The three above are not a sample of all cloud failures, and no source cited here gives a rate for how often the customer side is the weak point. Provider models also change as services change, so a responsibility sheet needs a review date.

A short test

Pick the three cloud services that hold your most sensitive data. For each, list five controls: administrator MFA, network restriction, credential rotation, logging and integration approval. Mark who owns each and what evidence you hold. Every blank cell is a place where responsibility is assumed, not assigned.

Sources

1. NSA. Top Ten Cloud Security Mitigation Strategies (March 2024)

2. Google Cloud / Mandiant. UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion (10 June 2024)

3. Google Threat Intelligence Group. Data Theft From Salesforce Instances via Salesloft Drift (UNC6395)

4. Cloud Security Alliance. Top Threats to Cloud Computing Deep Dive 2025 (29 April 2025)