Multi-cloud seems to be the latest trend taking the security industry – and organizations alike – by storm, and while many within industry praise multi-cloud environments as one of the best ways to strengthen cybersecurity, one CTO and former cloud security analyst at Gartner begs to differ.
This is the analysis of Steve Riley, Field CTO at Netskope and former Gartner analyst, who considers that multi-cloud is the factor that may well boost resiliency, but it does not improve security.
According to Riley for many reasons including:
- Becoming an expert in multi-cloud is near impossible with so many complex environments, creating greater opportunities for mistakes which can manifest as security vulnerabilities;
- The vast majority of cloud security failures are configuration mistakes of some kind (as a consequence developing the discipline of correct configuration is the best thing a company can do to ensure that it uses the cloud safely and securely);
- Every company is multi-cloud when you factor in SaaS, with companies subscribing to anywhere between 100 to 1000 SaaS applications. Yet most SaaS applications offering little built-in security.
Building on this, Riley explains: “It’s already difficult to become an expert in any one cloud (here I’m thinking AWS, Azure, GCP). Trying to become an expert in two or three is almost impossible. Lack of expertise means more mistakes, most of which manifest themselves as security vulnerabilities that are advantageous to attackers in one way or another.”
The large array of different systems is one of the problems, Riley explains: “Even though cloud computing isn’t all that new anymore, learning how to use it effectively can be overwhelming. It’s unfortunately very easy to make mistakes. During my time at Gartner, while interacting with thousands of clients, it became clear that the vast majority of cloud security failures are configuration mistakes of some kind or another, so developing the discipline of correct configuration is the best thing a company can do to ensure that it uses the cloud safely and securely.”
Illustrating this, Riley says: “Infrastructure as a service (IaaS) public cloud resources are generally closed by default. The only entity with initial access to the object is the person who created it. However, let’s say a storage bucket is created and an application needs to read from it.”
Therefore, Riley adds: “A developer might not take the time to write a bucket access policy (which can be complicated). For expediency, the developer could quickly change the default access control list to grant the entire world read access — for just a few minutes, of course. What could possibly happen? Well, what happens next is pretty predictable — 30 minutes have passed, and the developer’s attention has drifted elsewhere. Now, that bucket of sensitive information is just sitting there, tempting anyone who might happen to stumble across it. This is a shockingly common problem: reports of “leaky buckets” routinely make the headlines. Eventually, someone or something will find one. Attackers can download tools from the internet that automate discovery of leaky buckets.”
Riley outlines the complications further: “IaaS access controls in general — not just those on storage buckets — are notoriously difficult to comprehend. Plus, the access control models across AWS and Azure and GCP vary significantly. They might use the same vocabulary, but the words aren’t interchangeable. A role in AWS IAM (identity and access management) functions in a completely different way than a role in GCP IAM. Applying the AWS mindset to GCP results in weak security that can be exploited via privilege escalation, lateral movement, and object/project compromise.”
Here the issue of complexity resurfaces: “Even if a company can maintain a single-IaaS discipline, the reality is that every company is multi-cloud when you include SaaS. Companies subscribe to anywhere between 100 to 1000 SaaS applications. Most, but not all, SaaS applications offer little built-in security. A few SaaS applications have evolved good security controls over time, but they may be wildly different in quantity and degree (e.g., Office 365 has far more built-in controls than Dropbox).”
Riley adds: “Unlike IaaS, where objects that are created are closed by default, the opposite is true with SaaS. For example, the default configuration of an Office 365 tenant is such that if users have access to a file, they can share that file with anyone in the world. Whoever finds the link can forward it to anyone else in the world. Microsoft decided to facilitate sharing — it wants it to be as easy as possible for individuals to collaborate. It’s a business decision, but it has ramifications, so it’s very important to think clearly and deliberately about how to configure SaaS security controls. Misconfiguration can be ruinous.”
Riley’s recommendation is: “It’s sensible to rely on third-party, provider-neutral security posture management tools to ensure consistent and repeatable security policies across all your clouds. Posture management tools sit alongside your cloud deployments, and because they rely on cloud APIs to investigate your configuration, you don’t need to schedule any production downtime or lengthy integration phases to begin deriving value from them.”
He also advises: “As cloud adoption continues to accelerate, companies need to maintain an adequate security posture. By deploying an effective security posture management strategy, companies can continue to find and eliminate cloud security failures rooted in configuration errors.”
