"Products provide some protection, but the only way to effectively do business in an insecure world is to put processes in place that recognize the inherent insecurity in the products. The trick is to reduce your risk of exposure regardless of the products or patches.”
– Bruce Schneier
Bruce Schneier penned these insightful words in April of 2000. Scroll forward 19 years and we now find ourselves in a world where disruption and innovation are a daily occurrence due to the low barriers to entry created by public cloud. How do security leaders design a strategy that effectively addresses the processes and tools required to manage the new risks and threats cloud presents?
First, let’s start with a definition of what we mean by multi-cloud. When we say “multi-cloud” we simply mean the parallel usage of two or more cloud service provider (CSP) platforms. And “cloud” generally describes a computing platform that falls into three categories: IaaS, PaaS & SaaS. While each of these represent their own unique security challenges, we’ll stay laser focused on IaaS & PaaS where there are currently three ruling titans: Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform.
Challenges of a Multi-Cloud Environment
In our conversations with clients there is almost always one universal thread no matter where they are in their cloud journey: how do we enable the business to operate with freedom in the cloud but also put the proper guardrails in place to prevent them from taking unnecessary risks?
We believe a fundamental understanding of the shared responsibility model is key as this is the main differentiator when compared to legacy on-prem environments. Once this model is understood and clearly documented and agreed to in an organizational RACI, we recommend customers conduct a risk assessment informed by a thorough understanding of security in the cloud.
Critical to the cloud risk assessment is understanding your current security processes and how the tools you’ve already invested in help manage risks today. Unfortunately, we see a lot of clients skip this step and move directly to design and build phases, which is a fatal mistake. Why? Because it inevitably leads to security teams rebuilding their on-prem security model in the cloud and completely misses the opportunity to transform their security program and "shift left” their security, aka DevSecOps.
When companies are planning an all-in approach to cloud, they typically focus on one of the three major players: Google, AWS or Azure. Each of these providers offer rock solid services with every major security and compliance certification to boot.
Invariably several months into the cloud migration process a business unit will pop up (or security teams will discover) a new cloud requirement: “Provider X just launched a new feature which directly addresses our business requirement--can we get access this week?” The IT and security teams then scramble and try to figure out how anything they’ve purpose built for their primary cloud can be utilized with the new provider.
For security teams who are relying on legacy tools or only native security features of their primary cloud platform, this is a major challenge. How does AWS GuardDuty or AWS Config help you to secure Google or Azure clouds? Simple answer? They don’t. So how should a security team proactively address the multi-cloud security challenge while not getting caught up in the morass of ever-changing individual cloud provider offerings?
Standards are the Precursor to Automation
Staying secure in a multi-cloud environment can be challenging given the radically divergent APIs between cloud providers. The best place to start is with a trusted security standard. Rather than trying to design a standard from scratch, we highly recommend starting with the Center for Internet Security’s Benchmarks. The AWS benchmark has been around for several years and both benchmarks for Azure and Google Cloud were released in 2018. While standards may not be the most exciting part of security they do have the added benefit of being the precursor to automation. Put simply, you cannot automate what you have not standardized upon. Once you’ve agreed upon a standard you can then begin to measure yourself against it over time and work to automate as your cloud security program matures.
Moving from Theory to Execution
Security leaders can design a strategy that effectively addresses new risks and threats presented by public cloud. This can only be done with a deep understanding of the shared responsibility model and a sharp focus on dissecting the process by which development and business teams are utilizing public cloud. In my next post we’ll dig deeper into how this can be done as well as how simplicity is key to your multi-cloud security strategy.