Foundations of a Multi-Cloud Security Strategy
I’ve spent a good year working on a security strategy to manage multi-cloud environments, in this article I want to share what I wish we did in advance to be better prepared.
(Are you an AWS shop that is suddenly starting to deal with a lot of Google Cloud Platform? Check out my introduction to GCP for security teams.)
Congrats, you are already multi-cloud
Going multi-cloud doesn’t make any sense from a security point of view.
Good security is achieved more easily on a standardized stack. Spanning across different cloud providers is a step in the opposite direction.
(Additionally, all the nuances between the shared responsibility models will worsen your blind spots)
But like it or not you are already multi-cloud, or soon to be if your company is growing.
There are two ways to the weeping and gnashing of teeth (aka multi-cloud) :
- Procurement of new Platform as a Service (PaaS): developers will start using specific PaaS that are not offered by your main cloud (e.g. “GCP has a lot of Machine Learning toys!”)
- Merger and Acquisitions (M&A): you will inherit existing infrastructures on other cloud providers from the companies you end up acquiring
While a new PaaS is something you can mostly address with some notice, a M&A is a sudden jump in the dark: security is notified just a little bit earlier than everyone else.
Looking back with my now better hindsight, this is what I would focus on.
1. Prioritize Incident Response and Log collection
The first priority is supporting the Incident Response (IR) process.
(If you don’t have one, have one)
It’s unlikely that the security team, who organically specialized in a single cloud provider, will have the know-how from the start to drive a hardening strategy on another provider. You are going to play a reactive game for a while.
As such you need a Security Information and Event Management (SIEM) system and a playbook to start ingesting relevant logs.
You want to have the data to investigate a breach and malicious lateral movements as fast as possible, and that usually comes from:
- Identity and Access Management (IAM) logs
- Configuration change logs
- Network logs (when applicable)
Invest in educating the security team and, in case of an M&A, partner with the acquired operation teams so that they can support you.
2. Build an inventory of your new cloud assets
Secondly you want to build an inventory of your new assets.
You can’t prioritize any hardening if you don’t know what you are running.
Additionally, having an inventory can help you track relevant stakeholders who operate the new systems and you need them for any security work in the new environment.
If developers are advocating for using a specific platform service you should push for having a process that will promote someone accountable for the use of that service, before people start using it.
The risk you want to avoid is to have experimental services becoming a foundational piece of the production environment without anyone in security noticing.
I’ve seen this happening a lot with serverless stuff.
This is a costly investment area because ultimately what you want is a holistic control plane and no cloud provider will offer that. So you either buy an expensive third party solution or you have to build your own.
3. Declarative Identity and Access Management
The number one headache of a multi cloud environment is Identity and Access Management (IAM).
Did you know?
IAM is the fastest way for your company to make the news
While the concepts are similar across providers, each one of them implement IAM in a different way.
The temptation is to try to uniform IAM across providers but I would advise to resist the urge and switch your attention to implementing declarative policies.
What does it mean?
It means that nobody can access the cloud console for IAM purposes: add a user, create a Service Account, assign Roles and permissions. They must commit a change to a terraform file, a yaml, a spreadsheet, a post-it, whatever.
Being declarative has a few solid advantage:
- A declarative set of policies is a form of inventory in itself, see point #2
- Declarative policies are a central place where the security team can start implementing constrains
- Declarative policies are a central place where Security can become a gatekeeper
- Declarative policies provide an easy way to track, revert and enforce changes.
The trade-off here is the introduction of more friction for users, and it is going to be a hard sell. Lobby harder.
Conclusion
In the Utopia of information security there is no such thing as multi-cloud, or — even better — not even computers.
But we live in this reality and we have no choice but to face it.
These are the three main things I think will make a security team better equipped for the challenge.