"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 penned these insightful words in April of 2000. Scroll forward 18 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 in the context of this article.
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. For a deeper discussion on SaaS, be sure to read this article.
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 move security left, 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 security 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 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?
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 the benchmark for Azure was released in the last few months (we eagerly wait for the GCP benchmark--rumor has it that it will be released before the end of 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...but not without first making things as simple as possible.
“Everything should be made as simple as possible, but not simpler.” - Albert Einstein (purportedly)
Simplicity is key when it comes to solving most challenges and we couldn’t agree more with Mr. Einstein. However, when it comes to simplifying your (multi-) cloud security strategy there are three things to keep in mind:
Each of the cloud vendors do a tremendous job at providing native security technology within their platforms. However, when it comes to anything outside their ecosystem, they have little incentive to provide the visibility you need in a multi-cloud strategy. Look for security tools that are provider agnostic and support, at a minimum, Google, AWS and Azure clouds.
What’s the one thing all of the cloud providers want most? To keep you squarely on their platform. However when it comes to cloud security, teams must take the long view that while today AWS might be your de facto cloud platform, research shows that GCP and Azure are in your future (and are likely already in your environment, but that’s a topic for another post). This is why we recommend engaging with security providers who’s best financial interests are not with a single cloud but rather in the most diverse set of providers.
Your SOC is already dealing with alert fatigue--don’t add to their stress. When conducting your risk assessment ensure that requirements for security controls are included. Your SOC team should have a single tool for starting investigations of any cloud-based incident. If your team is relying mainly upon the native cloud provider tools or is attempting to build their own with open source or SIEM tools they will likely spend more time customizing these tools for the near weekly changes cloud providers make rather than focusing on reducing risk and enabling the business to quickly consume new cloud features.
When looking to simplify your (multi) cloud security strategy it is critical that security executives and their teams keep visibility, reducing cloud vendor lock-in, and streamlining alerts and tools in clear focus. This is where cloud agnostic security tools such as the RedLock Cloud 360 Platform can help. RedLock provides a single location where security teams can gain visibility across Google, Azure and AWS while freeing these teams from the care and feeding of homegrown, open source or native cloud provider tools.
Get a demo to see how RedLock can help you with: