The Cloud Shared Irresponsibilities Model
The next phase of cloud security won’t be about shiny new products or services, although we’ll have those. It won’t be about stopping the next world-ending cloud 0-day, but we’ll continue trying to prevent them. It won’t be about AI, but we’ll still have to do something with AI to appease our machine overlords. It will be about making cloud deployments more inherently secure through better, smarter defaults, and better, smarter, and yes, cheaper, built-in capabilities. Here’s why: When I first started researching and working with public cloud about 15 years ago, I realized that cloud providers have massive economic incentives to be better at security than your organization. A major breach of a cloud provider that affects all (or most) tenants would be an existential event which would destroy trust in that provider and crater their business. We’ve arguably had moderate multi-tenant events, and are witnessing events in real time — wondering whether my theory will stand, and a major CSP will suffer from a direct breach (as a result of Microsoft’s recent incidents and the CISA CSRB report). This was the origin of the shared responsibilities model. There’s a waterline in the technology: below it the cloud provider is responsible for ensuring the services you consume are inherently secure. Above it you are responsible for how you secure and configure what you use. Security is transitive. When I build on a service, I am only as secure as the underlying service. It turns out this plays both ways. It’s a two-way door. Security impacts are also transitive. If a customer on a cloud platform suffers a major security breach, every headline includes the name of the cloud provider. Sure, you can blame the customer for misconfiguring your service, but that doesn’t mean everyone won’t still think you’re responsible. Thus I present the Cloud Shared Irresponsibilities Model. Cloud providers will be considered partially responsible for any customer breach involving their services, even if the breach was due to customer misconfiguration. This really hit home this week with the Ticketmaster and Santander debacle. An intel firm called Hudson Rock claimed that Snowflake was the source of the breach, and that other companies were affected. Snowflake followed up (backed by Mandiant and Crowdstrike) that the attacks targeted the breached companies and took advantage of clients with single factor authentication. While investigations are ongoing, this is negative for both the breached companies and Snowflake. (And I really wouldn’t want to be Hudson Rock right now, unless I had damn good evidence). Snowflake didn’t do anything wrong. But it kinda doesn’t matter at this point — heck, even if in a fictitious world it turns out the Ticketmaster data wasn’t even in Snowflake, no one will read the follow-up headlines. Or let’s go way back to the Capital One breach. To this day some people still think it was an insider attack by an AWS employee, or a former employee using special knowledge. Nope, it was a former employee using well-known techniques, which I even had been talking about in a training class for the prior year (we had a lab for the credential abuse part!). Here’s the messy part. AWS was partially responsible for the breach. They didn’t do certain things that could have significantly reduced the risk that Capital One would make those mistakes, or eliminated them completely. How do I know? In the years, since we’ve gotten IMDSv2 (and can now enforce it as a default), Block Public Access for S3 (and better tools to determine whether a bucket is potentially public), new regions are opt-in only, and various other enhancements. Microsoft tried to play the customer blame game, but they were hammered in that CSRB report for charging more for the security tools needed to reduce the risk of the attacks. The Shared Responsibilities Model forced providers to create secure base services, but pushed blame for misconfigurations onto customers. The Shared Irresponsibilities Model pushes negative impact back on the cloud provider for these mistakes. It’s about restoring balance to the Force. If I’m right, what will we see? Cloud providers will improve their defaults. For example, there are providers today which do not allow you to have certain accounts without MFA enabled by default (e.g., AWS is adding this requirement for root user accounts). Some security capabilities that customers pay for today will either become ‘free’ or much cheaper (e.g., Microsoft is reducing/eliminating costs for some logs, and/or extending the free retention period). More successful cloud providers will make security simpler and easier. Okay, that last one might be a stretch. It’s there to amuse my fellow cloud security professionals. I’m sure Chris is snorting some sort of not-beer out his nose right now. I really don’t think the cloud providers (other than Microsoft — seriously, read that CSRB report) have done anything wrong. It’s very hard to anticipate failure states, and to insert security which will add friction and slow down the primary buyers and users of cloud services. But now that government regulators have shifted their collective gaze, that media companies prefer headlines with ‘Amazon’, ‘Google’, and ‘Microsoft’ in them, and cloud platforms are becoming the default for new projects, it’s hard not to see this shift towards more secure cloud substrates accelerating. And I’ll finish with a simple KPI we can use to measure maturity across all platforms: The time or data volume before a cloud provider requires MFA on all administrative accounts. Share:
