Shared responsibility still fails at the same seam
In plain words: The cloud company looks after the building; you look after what you put in it, and most break-ins happen at the door you were meant to lock. Cloud and platforms, explained simply
In short
- Every cloud provider publishes a shared responsibility model: it secures the cloud, the customer secures what they put in it.
- The big incidents keep landing in the same place: the customer's half, at the edge of the provider's. Accounts without multi-factor authentication, keys left in code, storage open to the internet.
- The answer is not more tools after the fact. It is safer defaults, set once by the platform team, so the seam is closed before anyone builds on it.
The model, and where it breaks
AWS describes it as security "of" the cloud and security "in" the cloud. The provider runs the data centres, hardware and core services. The customer chooses who can sign in, how services are configured, what is exposed and how data is protected. Every major provider publishes a version of the same split.
The split is clear on paper. In practice the seam sits exactly where a feature is available but off by default, or on by default but easy to weaken. The provider offers multi-factor authentication; the customer has to require it. The provider offers private networking; the customer has to use it.
The same seam, again
In 2024 a criminal group Mandiant tracks as UNC5537 stole data from many customers of Snowflake, the cloud data platform. Mandiant found no breach of Snowflake's own systems. The attackers signed in to customer accounts with credentials stolen by infostealer malware, some of them dating back to 2020. Mandiant named three reasons the attacks worked: the accounts did not have multi-factor authentication, the credentials had not been rotated, and there were no network allow lists limiting where sign-ins could come from.
Every one of those three was a setting on the customer's side of the line. None of them was new. That is the point of this note: the seam where shared responsibility fails has not moved in a decade. Identity, configuration and access to data are where it breaks.
Close the seam with defaults
NSA and CISA's top ten cloud mitigation strategies, published in March 2024, start where you would expect: uphold the shared responsibility model, use secure identity and access management, and secure cloud key management. Most of the list is about settings the customer controls.
My own view is that those settings should be decided once, centrally, and inherited by everything built on the platform. That is a job for platform engineering more than for a security tool:
- Guardrails at the organisation level. Policies that make it impossible to create public storage, or accounts without strong authentication, rather than alerts after it happens.
- Templates that are already secure. The quickest way to build something is the safe way, because the starting template has logging, encryption and private networking switched on.
- No long-lived keys. Workload identities and short-lived tokens instead of passwords and keys that can be stolen and reused for years.
- One view of the seam. A regular check of the settings that matter most, across every account and every provider, owned by a named team.
What to do on Monday
- For each cloud and software-as-a-service platform you use, check that every account with sign-in rights requires multi-factor authentication. Include the service accounts.
- Find long-lived access keys and credentials in code repositories, and plan their replacement.
- Turn the three most important settings into organisation-wide policies that cannot be overridden by one team.
- Read your provider's shared responsibility page with your platform team and mark which lines you have actually covered.
Sources
- AWS, Shared Responsibility Model.
- Mandiant (Google Cloud), UNC5537 targets Snowflake customer instances for data theft and extortion (June 2024).
- NSA and CISA, Top Ten Cloud Security Mitigation Strategies (March 2024).
Personal work and my own view, not my employer's. Sources are public.