A smidge over a year ago I wrote the Grand Unified Theory of Cloud Governance. It’s a concept I’ve been playing with for about 5 or 6 years to try and encapsulate the root cause of the difficulties companies have adapting to cloud. Sure, the title is a bit egotistical, but I used to be a Gartner analyst so, shrug?
Like any (hopefully) good theory I keep evolving it over time as I work with more companies and talk to more people. I’ve been using it a ton over the past couple years in my speaking and training, especially as I’ve been pulled into more governance scenarios. Time and time again the major problems I run into aren’t so much technical, but organizational. Yes, there are many MANY technical complexities to cloud security, and they can and do result in breaches, but in my experience the governance issues far outweigh the technical ones.
Good governance can’t patch a zero day, but bad governance means the attacker never needs one.
The core of the theory hasn’t really changed, I just keep working on better ways to explain it. I also decided to trim it down slightly. Here’s how I currently plop it onto my slides:
- Cloud decentralizes operations and infrastructure
- But cloud unifies all administrative interfaces
- And puts all admin portals and resources on the Internet, protected with a username and password
Going back to the previous version the changes are small but also big:
- Cloud has no chokepoints, and thus no gatekeepers.
- All administrative and management functions are unified into a single user interface that is on the Internet.
- Protected with a username, password, and, maybe, MFA.
- Technology evolves faster than governance.
I still use the “no chokepoints and gatekeepers” in my talk track but I found that it’s a longer way of saying “decentralized”. The fundamental issue is the independent control of the full stack outside of centralized infrastructure. That a dev or app team can build and manage all of their own infrastructure in their own environment with just a credit card. Now there are still some dependencies and controls, especially in the data plane or when you need to tie back into networks, but that doesn’t change the primary point.
Trying to completely recentralize is rarely going to work.
Next, I didn’t really change the unification of administrative interfaces. To expand, we decentralized all the infrastructure and control at the deployment level, but everyone, in the world, uses the same web console and API endpoints.
Attackers have one gateway to infinite targets.
Then I took the sub-bullet from version one and made it bullet 3. These admin portals are all on the Internet, and by default use little more than a username and a password. All resources are also one setting away from being on the Internet, just ask all those S3 buckets and ElasticSearch clusters.
It really is that simple. Teams manage their own stuff independently. They all, around the world, use the same web portals and API endpoints. And any idiot with the right credentials can poke and prod at the back end of your “datacenter”.
Now the crazy part; this was all laid out in 2011 in NIST 800-145, the 2 page NIST Definition of Cloud Computing. That defined the five essential characteristics of cloud computing as:
- On-demand Self Service
- Broad Network Access
- Resource Pooling
- Rapid Elasticity
- Measured Service
Take the first three points and we have:
- Teams manage their own stuff
- It’s all on the Internet
- And all based on collective resource pools
Alright, so what does this all mean what do we do?
Accept it.
That’s the first step. Understand the problem and use it as a lens to devise our solutions. As I wrote recently in my Strong Authorization post:
Because they aren’t used to everything (potentially) being on the Internet. The entire management plane is on the Internet, so if an attacker gets credentials, you can’t stop them with a firewall or by shutting down access to a server.
Start there. Accept the base reality. What can we do to reduce that risk? To reduce those attacks? I think the most impactful choice is to focus on IAM, and the intersection of governance and IAM. Who do you have manage permissions? Access? What security controls can prevent, detect, and correct IAM related attacks? What are your processes around IAM? Do your incident responders know the deep ins and outs of the IAM for your given cloud provider(s)? Do you use JIT/Strong Authorization? How do you manage IAM for contractors and external services?
Start with your IAM governance and processes. Then choose and use technologies to support them. This is the single most impactful way to improve your cloud security. I really hope I’m not the first person to tell you that.