The cloud security emperor has no pants

As anyone who has worked on a cross-functional team with no clear owner knows, “shared” or “joint” responsibility often means that everyone assumes that someone else is taking care of the problem. Without clear effort to make sure that nothing falls between the two (or more) teams, something always gets missed.

The shared responsibility model and cloud service providers

The cloud services “shared responsibility” model goes something like this: the cloud provider protects everything below a certain level (that level generally being their software) and is responsible for securing it.  Consider that the foundation of your house.  You, the customer, are responsible for protecting everything above the foundation—securing the house, if you will.

It seems really clear and simple—and like all clear and simple analogies, it doesn’t hold up to inspection.  If you’ve ever looked at a house, of course, you realize that there isn’t a simple line you can draw separating the requirements between the foundation and what’s above it.  The interconnections between the separate systems are integral to the structural integrity of the house; so too are the interconnections between a cloud platform and the applications that live atop it.

Cloud misconfigurations and complex tools

The reality is that how a customer configures a cloud service is critical to the safety of the applications that live atop it.  Building in a public cloud?  Have you exposed a Lambda function to the public?  Perhaps you didn’t enable Lake Formation access control on your data lake.  Maybe you never enabled advanced data security on your AzureSqlDBServer.  Or there’s a GCP cloud function with public invocation privileges.

This problem extends beyond the infrastructure-as-a-service public cloud offerings.  If you’re using a content delivery network for DDoS defense, did you remember to make your origin hostname unpredictable?  When you integrated the business application mesh between your SaaS services, did you accidentally let any user invoke an API that’s only needed by, say, Finance?

The list of ways that a customer can end up shot in the foot is remarkably large.  The best cloud platforms invest a lot of energy in making those oversights rare and ensuring that those are not the default settings.  But no provider is perfect across all of their cloud services, and not all cloud platforms make their system safe for use.  And, worse, they really don’t have any incentive to tell their customers about the various unsafe configuration choices, especially if they’re particularly bad at it.

Ironically, the cloud platforms that provide the most security services for their customers often create the most complexity in using those services.  Each toolkit requires enough knowledge to use it correctly that there are now entire businesses that exist to sell you services just to correctly configure your cloud services.

Improving cloud security by staying covered

If only a buyer had a way to ask a vendor, “What are the riskiest ways we could use and configure these services?”  

Unfortunately, rather than focusing on their own use of cloud services, most customers ship over a giant spreadsheet of stock questions based on the NIST CSF or BITS SIG to make sure the vendor is configuring themselves correctly.  Instead, maybe it’s time customers use the third party risk management process to start asking insightful questions about their own security.

Or, in terms of the shared responsibility model, just because your cloud provider has a nice pair of pants, if you don’t know how to put on a belt and tuck in your shirt, at best you’ll be a little drafty.  At worst, you’ll find yourself exposed in unpleasant ways.